Simple Agreement For Future Labour Tokens.


The purpose of the SAFLT agreement is to provide developers and project leaders with a legal tool to create deferred payment contracts for blockchain related developments. Let's say that Alice wants to develop a token-based venue. Where each token shall represent one seat in the venue, and where the building on the venue will be financed by pre-sale of these seats. The technology will allow seatholders to grant permissions for a limited time to others by leasing their seat. This will be made using a time-lock capability where the person who wishes to lease the seat for a specific venue (a Britney Spears concert) will lock X ETHs until it returns the token that represents the seat to the holder.

Now, this is a crowd-funded project. It also might not be deemed as a security token. But Alice needs people to help her develop the pre-sale (or ICO) stage. For this, she needs one initial software developer to write the whitepaper, a marketing guy to help her with the funding, and a web designer to set up a page for the Speculative Cryptocurrency Allotment Method she wants to run. This costs money, but Alice? Alice only has an idea.

So how could Alice get the project running? She can use her own capital. But if she doesn’t have any she will need to create future commitments. This means that she will need to find a developer and tell him “Hi, I’m doing this project and I want you in. If we raise money, you will get paid”. That guy is Bob.

Bob knows he is taking a risk. That’s why Bob’s goal is rewarded: Alice will give him tokens which might increase in value (meaning, he will have a stake in the project) or pay him conditionally.

Unlike regular projects, that assume that everyone has the funds, this project assumes that people trust each other and give them credit.

This agreement will set up the framework for general services that their compensation is future related.

First, we’ll define the task. This will be done in Annex A. We will define specific deliverables and results, and the acceptance tests. That’s your job. We can define the legal framework, but not the actual project.

Annex B will be your compensation scheme: how will the contractor be rewarded.

Annex C will define the token which is meant to be issued. This is for the (unlikely) case that the project lead issues two tokens, one is worthless and the other is not, and provides the contractor with the worthless token.

Annex D will be the cap table. In the case where the payment is equity based, we need to let the Bobs of this world who else is a stakeholder in the project and how much exactly is their stake.

Now, while this is a legal agreement, we only provide it as a template. This means that you can accept it as a general term, or you can modify it. You should consult a legal expert to do this, because this does have risks.,


See the docs
Prepared by Jonathan Klinger for Peer Query. Icon by MC Murry Julie.