Let's Make the EOS Constitution an Actual Contract
One of the things many of us love most about EOS is the promise of on-chain governance. Every smart contract on the EOS blockchain is connected to a Ricardian Contract according to the EOS Smart Contract wiki:
Each Smart Contract must be accompanied by a Ricardian Contract that defines the legally binding terms and conditions of the contract.
According to wikipedia:
A contract is a promise or set of promises that are legally enforceable and, if violated, allow the injured party access to legal remedies. Contract law recognises and governs the rights and duties arising from agreements. In the Anglo-American common law, formation of a contract generally requires an offer, acceptance, consideration, and a mutual intent to be bound. Each party must have capacity to enter the contract. Although most oral contracts are binding, some types of contracts may require formalities, such as being in writing or by deed.
Right now, people are interacting with the EOS blockchain without agreeing to the EOS Constitution.
If you're using the EOS blockchain, you should be familiar with the EOS Constitution:
Have you read this constitution and have you initated some process on-chain to agree to it? Unfortunately, there is no such process at the moment. In some ways, this is worse than a Terms and Conditions link next to a checkbox where people check the box without reading the terms. In this case, many people are interacting with the EOS blockchain without even knowing the constitution exists.
Let's pause a moment to point out eosDAC plans to solve this problem for our members. We will have a specific membership smart contract action which eosDAC token holders will need to execute if they want to be considered members of the DAC and be protected by the eosDAC constitution. This smart contract will reference the eosDAC constitution which you can read here. If you'd like to continue to support our efforts to enable DACs and provide value to EOS, please give
eosdacserver your vote.
Constitutions are important because they define and clarify the expectations of everyone involved. If we say something is "bad" or someone was defrauded or something was stolen then we need to be clear on what the rules are and what we're going to do when those rules are broken. Block Producers, like eosDAC, are required to follow the Ricardian Contract of the regproducer action. Although the dispute resolution and arbitration aspects of EOS are still being worked out, if a dispute arises and is ruled in such a way requiring a Block Producer to freeze funds or reverse a transaction or something of that nature, it may put that Block Producer at risk unless everyone involved actually agreed to follow the constitution via a voluntary contract.
We have a real-world example of this right now. Some EOS token holders for various reasons do not have access to their accounts. An initiative was started in the EOS911 Telegram to help these users protect their property, if possible. You can learn more about that here. Unfortunately, ECAF (EOS Community Arbitration Forum) has yet to make an official ruling on if BPs should freeze the accounts which may have been compromised or fraudulently obtained. ECAF may be hesitating to take action due to EOS users not actually signing a contract to follow the constitution. This puts BPs in a difficult situation where we've been shown valid evidence of fraudulent activity and cryptographic signatures from the original account holders, but are expected by many to do nothing about it without an official ruling from an arbitrator. If we delay, the funds will most likely be lost. As BPs we're stuck and ECAF seems stuck as well. Not only that, we're not yet clear on how decentralized the arbitration process will be and if consensus between 21 BPs might actually be more effective at representing the will of the token holders at this stage.
So this is a problem. How are we going to fix it?
Since the EOS blockchain is already up and running, we have to find a way to back into this. One possible option is to have each BP sign a message on the blockchain which explicitly states they will follow the EOS Constitution as of the current block and all previous blocks already signed. From there, we might get consensus from the community to modify the regproducer and claimrewards actions to include an agreement referencing the current Constitution as of that block time. We might also modify the Ricardian Contracts of these actions to reference the constitution. Article VII of the constitution implies all Ricardian Contracts should reference how disputes will be handled which is something else we'll need to improve for the system contracts we already have.
With support from the community, we might slowly expand the number of contracts which directly reference the EOS Constitution to ensure everyone involved signed an actual contractual agreement with legal protections, not just a code of conduct bad actors can freely ignore. All application developers using the EOS software could then display these contracts as part of their application. Application developers which have an on-chain agreement to abide by the constitution could then be recongized by things like the Metacert Protocol.
These are just ideas for discussion. At this point, I'm not giving a direct call to action other than to get the BPs and stake holders to discuss these challenges openly. Getting users to agree to the EOS Constitution may not solve much if we can't yet agree on what the EOS Core Arbitration Forum is or how it is governed (we currently have an EOS "Community" Arbitration Forum but the constitution mentions "Core" which is undefined).
We are in uncharted territory here trying to protect life, liberty, and property using a blockchain in ways no other system has been able to do so far. It's not perfect and probably never will be, but we can take the first steps towards something better to ensure EOS remains a leader in on-chain governance and smart contract technology.
There are many varying views on these issues, even among our own eosDAC launch team. I'm publishing this on my personal blog because it's not yet something we have consensus on as a DAC. This is just to get the conversation moving forward, and I'd love to hear your thoughts below.
(Originally posted on STEEM here)