How Should You Trust Someone In A Trustless Environment? The SAFLT agreement address this very challenge.
First, let me introduce myself; I am Jonathan Klinger. I work as a lawyer with some of the companies and people who build decentralized applications and blockchains. I've worked with blockchain technology since 2012 and I've been working with the Israeli Bitcoin Association since its establishment. I'm also heavily invested into privacy. I've been leading the Israeli Digital Rights Movement's activity with privacy and anonymity and I lead the team of lawyers who appealed to the supreme court against the biometric database (after investing ten years in parliamentary hearings). One of the things I've learned as a tech lawyer is that technology is only a solution as far as we can trust it not to be abused. That's, for example, one of the reasons I got involved with Bitrated. Bitrated is an environment to increase trust in cryptocurrency transactions by creating a mulitsignature arbitration mechanism, and we'll get to that later. One of the things I learned was that if we don't trust strangers over the net we can't get anything done, and if we don't have some kind of mechanism to evaluate someone's reputation, then, we don't know who to trust and who not to trust.
That's why when George approached me with a new project by Peer Query; I was excited. I mean, I really like Steem as a blogging platform; and I totally get why people are into it; but adding an additional layer of trust and economic incentives to contribute is great. What George wanted is a legal tool to help people collaborate. The problem is, well, that even if you want to develop a tool for collaboration and you want to reward people later, the technological tool doesn't exist. Why? Well, here comes the SAFLT; Simple Agreement for Future Labour Tokens. If Alice wants to set up a new ICO and generate a token, she needs a programmer. This means that she can't tell Bob: "Look, I'll give you 100 tokens as equity in the project" if there are no tokens. That's where the SAFLT comes into place.
The SAFLT is a tool meant to provide people some assurance (as assurance could be made) that if all the conditions are met, they will receive some sort of compensation. It cannot give one hundred percent certainty, and it can't turn a failure into a successful project, but it can give you some certainty that if everything happens, you'll be able to litigate and get your token's worth.
The general idea is that you have four annexes, each with the specific description: the job to be done, the payment terms, the definition of what is the token and the cap table (if there is equity compensation). If all criteria are met, then you get your payment.
To ensure that the signature is authentic, each party will be required to use their wallet address to sign the document.
And lastly, if there is any dispute, each party will have to put in the disputed amount into a multisig account for arbitration via bitrated. This means that if Alice thinks Bob should get 1BTC, and Bob thinks he should get 2BTC, then each shall have to put 1BTC in a multisig account for arbitration.
Now, what will happen if Alice (or Bob) won't perform? Nothing that might be enforceable. We have different states, and different venues. But: In the next project that Alice would like to set up, her reputation will be public, and the fact that she did not pay Bob will be public. This way, she will be incentivized to pay Bob.
Now make some great projects.
Links: Visit the website: https://saflt.com
Visit Github for the docs: https://github.com/SAFLT/saflt
See project on Peer Query: https://www.peerquery.com/project/AzinLMFMy