The “Intent of Code” is Law

The EOS community has embarked on a grand experiment to see if it can combine the best aspects of crypto-contracts, human contracts, and human dispute resolution. This makes EOS the first smart Ricardian contract blockchain.

The decentralized birth of a new blockchain and governance system can be messy because everyone is trying to figure out the rules. Some people want to replicate existing legal structures, others want to regulate all manner of behavior, and others want to retain Code-is-Law.

From watching the community launch an EOS.IO based blockchain, I have learned a lot already. I have seen that if you give people arbitrary power to resolve arbitrary disputes then everything becomes a dispute and the decisions made are arbitrary. The more power the arbiter has, the more vicious and petty the disputes become and the less predictable the outcome.

The Promise of Code-is-Law

The single most compelling feature of Code-is-Law is the removal of any room for dispute. All contractual terms are laid out by the code, which will be executed faithfully assuming there is no censorship. This gives all parties strong guarantees and predictability, except where there are bugs (differences between the expectation of parties using the code and what actually runs).

EOS set out recognizing that bugs happen and that the community needs a process to quickly establish the intent of the smart contracts and to resolve things accordingly. This is nothing more than the formalization and acceleration of the same kind of process Ethereum used to resolve the DAO hack or that Bitcoin used to resolve the 0.7/0.8 fork.

The Chaos of Free Form Contracts

Free form contracts, aka what we have used for thousands of years, are subject to all manner of subjective and unpredictable enforcement. Everything from establishing the validity of signatures, to the definitions of words, to the very validity of the terms, is subject to debate. This makes them very expensive to enforce and gives the governance system unlimited power.

Ricardian Contracts

A Ricardian Contract specifies both free-form terms as well as code terms. The EOS community is currently debating if and how to enforce the free-from terms. These terms include things like required disclosure of block producer ownership and certification of facts under penalty of perjury. Others want new terms to regulate everything similar to how government regualtors do.

Need for Objective Boundaries

Users of the EOS blockchain need some guarantees from the community in order to feel safe and secure. If everything on the blockchain is subject to mob-rule, then no one is safe. If the community does not have strong, objective, organizing principles, then everything is subject to interpretation and becomes unpredictable and arbitrary. The ensuing debates and conflict can tear a community apart.

Block One calls for an end to all arbitration orders other than to render non-binding opinions on the intent of the code. I believe the elected block producers should be the jury, which must render a 2/3+1 decision to freeze a broken contract and/or to replace a broken contract with one that operates according to the original intent (as determined by arbitration).

This means that the elected block producers have the same power as demonstrated by Ethereum in the DAO contract bug, it is just formalized and in the hands of the token voters instead of being informal and in the hands of hash power voters.

Enforcing Ricardian (Subjective) Terms

The purpose of the Ricardian contracts is to document the intent of the parties and provide evidence of intent in the event of a bug. If a Ricardian contract includes terms that cannot possibly be evaluated and enforced by the code then it is outside the jurisdiction of the block producers and community arbitration to evaluate and enforce.

A properly written Ricardian contract is entirely enforced by code; therefore, all disputes should be resolved by fixing the code. If a Ricardian contract wants to enforce other laws (e.g. perjury), then it must do so by defining the process in code for submitting grievances, appointing judges, collecting bond payments, and rendering decisions, and enforcing them. All of this must happen at the application layer, not at the base protocol layer. The entire enforcement process should be objective, with all actors exercising complete autonomy within the limits of the intent of the code.

Lost & Stolen Keys

The purpose of private keys is to generate objective proof-of-ownership. If we cannot rely on signatures alone then we must rely upon identity and subjective interpretations of intent. This will open up an unsustainable level of disputes and new kinds of fraud and/or injustice.

The solution to this problem should be technical in nature: implement multisig with biometric protection of hardware wallets with time delays. Each member of the community is responsible for their own security and permissions configuration. Enabling a fall-back to arbitration to dispute the validity of a signature after it has been irreversibly accepted by the blockchain opens up more issues than it solves. EOSIO was designed with support for Apple Secure Enclave, Touch ID, Face ID, and time delays. Once deployed in wallets, stealing private keys should be virtually unheard of and time delays should handle the rest.

EOSIO was written from the ground up to provide the infrastructure required to truly protect and recover accounts on an opt-in basis. These features include support for the R1 elliptic curve as used by Apple, Android, and many smart card devices. With time delays users can enjoy the ease-of-use of signing with a single-device while having a secure backup of multi-device signatures. The ability to objectively read account inactivity time in smart contracts gives developers the ability to define their own recovery processes without giving a 3rd party potential day to day control.

ECAF Opinions

The very first disputes brought before ECAF are in relation to a scam registration website that provided users with fake public/private key pairs. Due to technical limitations, even users who used hardware wallets on Ethereum fell prey to the scam. While the community has objective proof of the original owners of the Ethereum addresses, these individuals fell prey to the scam site because they didn’t use the official eos.io website nor follow the official instructions.

As much I would like to see the previous key holders receive their tokens back, I feel that the precedent established by such intervention would do more damage to the entire EOS ecosystem than the money they receive. At this point I would recommend that the EOS block producers campaign on making a charitable donation to the cause of helping these people out. It would be far cheaper for the EOS community to resolve these issues by way of community donations than by setting precident of producer intervention.

How to Enforce Arbitration orders in event of Key Theft

In a world where protocol-level dispute resolution is limited to fixing bugs in code, how does one protect against fraud and theft of keys? The answer is to opt-in to a banking Ricardian contract which controls the tokens on behalf of their owners. Transfers within the smart contract are subject to dispute resolution where the contract-appointed arbitrators have the power to reverse transactions and freeze tokens. Withdraws from the banking smart contract are subject to a 3 day delay after which they cannot be reversed.

Those who want the elected block producers and/or ECAF to protect their interests can opt-in to a new smart contract where ECAF/producers are the arbitration system. Exchanges that want to interact with these customers on a faster-than-3-day delay basis can also open a deposit account within the banking smart contract. The scope of arbitrator power would be limited to that contract alone.

Some people are worried about their entire account being stolen, not just their tokens. This situation can be resolved by placing the entire account under the ownership of a smart contract. As a user of the account you would control the active keys, but you would not directly control the owner permission.

EOSIO is designed with all the tools and capabilities to build the robust high-level governance for those who would prefer to trust an organization like ECAF to arbitrate disputes over stolen keys. There may be hundreds of such organizations each of which operates on different principles and all of which can build on the same EOSIO based blockchain.

Proposed EOS Constitution Referendum

1. The Intent of Code is Law where intent is documented by code, Ricardian Contract, user interfaces, and actual use.
2. If there is a dispute on intent of code, then intent shall be determined by a super majority vote of elected producers or an arbiter mutually agreed to by the parties to the dispute and enacted by producers. A super majority may, at their discretion, freeze a contract during an active dispute until such time as code to fix the contract is available. The parties to the dispute must produce proposed replacement code. The producers may charge a fee and/or place other requirements on the parties to the dispute. A super majority is defined as 2/3+1. Ricardian contractual terms that cannot be enforced by properly functioning code are beyond the scope of the producers authority to evaluate and enforce.
3. At no time shall elected block producers freeze or modify contracts that are operating as intended.
4. Contract developers are not liable for damages caused by bugs in the code. All Parties are responsible for auditing the code and the Ricardian contract before use.
5. All service providers who produce tools to facilitate the construction and signing of transactions on behalf of others shall present the full Ricardian Contract terms of this Constitution and other referenced contracts.
6. No Party shall have a fiduciary responsibility to support the value of the EOS token. The Parties do not authorize anyone to hold assets, borrow, speak, nor contract on behalf of EOS token holders or the blockchain collectively. This blockchain shall have no owners, managers or fiduciaries.
7. A Ricardian Contract is deemed accepted when a transaction is incorporated into the blockchain.
8. Parties voluntarily consent for all other Parties to permanently and irrevocably retain a copy, analyze, and distribute all broadcast transactions and derivative information.
9. This Constitution may be executed in any number of counterparts, each of which when executed and delivered, shall constitute a duplicate original, but all counterparts together shall constitute a single agreement. Use of the blockchain shall constitute consent.
10. This Constitution may be amended by a vote of the EOS token holders that attracts no less than 15% staked vote participation among tokens and no fewer than 10% more Yes votes than No votes, sustained for 30 continuous days within a 120 day period.