How to understand dispute resolution in EOS

There has been a lot of misunderstandings how EOS dispute resolution system works. I’ll try to separate different levels of onchain contracts and their dispute resolution process to help people understand it better.

Base/protocol layer vs. app layer

First, we need to understand what’s the difference between base layer and app layer. Simply put, “base layer” means the constitution which binds every user and “app layer” means app contracts which bind only the users of apps.

The constitution of EOS is a multiparty contract which is binding for everyone who uses the blockchain. It should be understood as a peace treaty. It defines rights and responsibilities for the members of the community to ensure productive cooperation. Without it, the community will be subjected to “the law of the jungle”.

If somebody breaks a rule of the constitution, it will be handled as a dispute. Someone else has to file a case to ECAF, which is an institution for dispute resolution for cases arising from the constitution.

Onchain applications will have their own dispute resolution systems. They can use ECAF’s services if ECAF will offer those. They can use community-based voluntary forums, or they can hire dispute resolution professionals. Every application will choose their own rules, dispute resolution mechanisms, and ways of enforcement.

Separating different parts of the dispute resolution system

To better understand how the system works, we need to break the contracts and their dispute resolution into different parts. Each of these can create problems, so we need to look at them separately to find the root cause.

The most important thing at this point is to properly analyze the base layer. But the same framework can be also used to look at application contracts to make sure they cover all necessary aspects. That’s why they are also included.

1. Signing of the contract

The constitution: In EOS, all transactions indirectly reference to the constitution which is on the blockchain.

There has been some arguing if this is enough. I think it is, but to stop the arguing, I suggest that after the first referendum, all accounts should be required to sign the new constitution. Then there won’t be any question whether or not it’s in effect. After that, all new users are required to sign the constitution as their first transaction to the network. They shouldn’t be able to do anything else before they have signed the constitution.

Application contracts: Time will tell how most apps will end up showing the actual contract to their users. In EOS, the best way is probably to show the Ricardian contract when the user uses the app the first time. Users accept the contract by using the application. Some apps might demand their users to explicitly sign the contract so that there are no misconceptions about it.

2. Rules of the contract

The constitution: It should be as short as possible. It consists of rules that will apply to everyone. Only the rules which are necessary in order to create a well-functioning blockchain ecosystem should be included. The more rules, the more there is complexity which can cause problems. But we still need some rules in order to create an environment which incentivizes mutually beneficial cooperation between members of the community.

Application contracts: Rules depend on what the application is trying to do. The Ricardian contract is the best way to write down the rules, but it could be something else, too, as long as it’s clear for the users.

3. Judicial process: how to decide if the contract was broken?

The constitution: EOS uses arbitration because it’s compatible with current legal systems. ECAF acts as the arbitration forum to handle disputes. It uses The Rules of Dispute Resolution to define the judicial process.

Application contracts: Can be anything, from volunteers to hired dispute resolution company. Different apps have different kinds of disputes, so there is no “one size fits all”.

4. Punishment and restitution

The constitution: In EOS, this is included in the judicial process. ECAF decides and includes it in the ruling.

If needed, the judicial process can be separated from the restitution. There can be two different institutions for these if the community wants more decentralization. At this point, it probably doesn’t create any benefits for EOS, but it’s good to keep in mind as an option.

The community might want to create guidelines for ECAF to consider for cases arising from certain articles. For example, once we have IBC (inter-blockchain communication), the community might want to emphasize that ECAF should not ever freeze or transfer funds so that it breaks IBC with some another chain. That would cause so much harm to the ecosystem that it’s better to let the thief keep the money.

It might be also a good idea to come up with an acceptable punishment for vote buying. Now ECAF can decide anything it sees the best, but it’s probably better if the community would tell ECAF what kind of punishment or restitution is considered fair.

I propose that the EOS community creates a separate document for punishment and restitution guidelines for ECAF. It should be different from the constitution, so it can be changed more easily. For example, amending the guideline document should have no requirements for voter activity (even if only 2% of tokens vote, the document will be changed) and a simple majority is enough (more than half of the votes go for yes).

Application contracts: They have very much free hands to do whatever they see best. My guess is that exclusion will be widely used: if somebody breaks the rules, he will be forbidden to use the application. In certain cases, bonds are useful because it’s easy for the dispute resolution process to control them. An arbitrator can have the access to the bond and the authority to transfer tokens from the bond to the winner of the dispute.

5. Enforcement

The constitution: EOS has separated the judicial process from the enforcement. ECAF gives the ruling over a dispute and blockproducers enforce it if necessary. It’s also possible that BPs don’t need to do anything because the lost party of a dispute complies voluntarily with the ruling.

It’s possible to ask local courts to enforce it because EOS uses arbitration as the dispute resolution mechanism. How it would work in practice is yet to be tested because local courts haven’t seen blockchain-based jurisdictions so far. But in theory, it should be possible.

Application contracts: Again, they can use whatever they see best. Bonds, local courts, transferring app tokens (if the smartcontract developers have control over the tokens).

One important question is still unanswered: What if apps need BPs to enforce their dispute resolution rulings? How we can achieve that? Should it even be possible? If the constitution is not breached, ECAF can’t help, so it might require some changes to the constitution. EOS New York has made a proposal (regarbitrator/regforum) which is a step forward, but it still lacks the enforcement process.

How to think with this framework

Anybody involved in EOS governance has probably heard claims like: “Onchain dispute resolution can’t scale.”

In order to understand scalability issues, we need to pinpoint where the bottleneck actually is. Here I offer five stages where it can happen. If we see where it happens, we might be able to do something about it. It wouldn’t be wise to get rid of the whole system if only one part of it is not working properly and it can be fixed.

Some examples what can be improved or fixed to help with scalability:
– The rules: Fewer articles in the constitution means fewer potential sources of disputes. For example, I support the removal of Article I in our current constitution which forbids the initiation of violence. It’s noble, but onchain dispute resolution should be constrained only for onchain disputes. Violence is an offchain act, so we shouldn’t use onchain arbitration to resolve cases for violence.
– The judicial process: Bigger fees (less small value cases), more arbitrators, automation.
– Punishment and restitution: Harder punishments (less incentives to break the rules).
– Enforcement: The losing side of a dispute should pay for BPs if their help is needed to enforce the ruling. If it’s cheaper to voluntarily comply with it, BPs won’t be needed so often.
– User software: Better wallets, notifications.
– Blockchain features: Option for longer token lockup times (it’s easier to notice and stop a thief when tokens are locked for three months instead of three days).

It’s helpful to look at this from a timeline perspective (before, during, and after the dispute). What can we do to prevent disputes happening? What can we do to optimize the dispute resolution process? What we did learn from the disputes when they are over?

We can also kick individuals out from the community. It’s effectively reversing the signing of the contract. If some individuals are the source of many disputes, the community can exclude them. It’s also possible to do this with voluntary blacklists. For example, exchanges can use a common blacklist to prevent scammers and other bad people using their services.

All parts of the system that I have presented here are like parameters which can be adjusted in order to find the right balance between justice and efficiency.

I hope this also helps application developers to understand what kind of processes they have to design for their apps.

Notes:

You might want to read my earlier post to understand what kind of environment EOS operates in: https://medium.com/@Samupaha/all-blockchains-are-governed-blockchains-2f4896bf2747

Application developers should understand how Ricardian contracts work: http://iang.org/papers/ricardian_contract.html