A walkthrough of an EOS Arbitration saga
- Zhang - DApp user and Claimant
- Robert - DApp developer and Respondent
- Alice - ECAF Arbitrator
- Casey - ECAF Case Manager
Background - forming the initial Forum
- At the boot of the EOSIO MainNet, the EOS Core Arbitration Forum (ECAF) is instantiated by reference in the EOSIO Constitution. The Constitution also points to the default Rules for Dispute Resolution (RDR). The ECAF is intended as the default forum and forum of last resort for the resolution of disputes on the EOS MainNet.
- To staff the ECAF with Arbitrators, the Governance team solicit for Arbitrator nominations from the Community
- The Arbitrators selected are provisional, and will be in place for the first 180 days of the chain
- Alice, an EOS Community Member, is nominated by several community members
- She goes through Arbitrator training.On conclusion of the training, Alice is paired with an experienced Arbitrator adviser who will assist her through case procedure, ruling on a case etc
- Funding the initial Forum:
- The initial forum will need to pay for Arbitrator training, put IT systems in place, pay for administration and pay Arbitrators a market rate whilst they are ruling on disputes
- To do this an initial set of funds will need to be secured in advance of the worker proposal system being put in place
- (Context: this dispute begins before any Arbitrators are in place; by the time it’s filed as a dispute there are Arbitrators in training; the Case Manager ends up managing this case through the early stages until the right Arb is available.)
- Robert is a developer of an Insurance DApp which is expected to pay out when a certain real-world event happens. Zhang, a frequent business traveller uses the Robert DApp to buy insurance against flight delay.
- One day, whilst Zhang is on a trip to the USA, a volcano erupts in Iceland spewing ash into the atmosphere and throwing the global airline system into chaos. Thousands of flights are disrupted and millions of travellers are affected.
- Once he finally gets back to China, Zhang expects to have received an automated payout of 500 EOS tokens for his multi-day delay. After all this is what Robert’s DApp promised! It was supposed to use a smart oracle to check an off-chain information source for flight delays and based on the data gathered automatically payout compensation.
- Unfortunately no payment comes through according to the stated payment schedule and due dates described in the Robert DApp contract. Additionally, Robert is not responding to Zhang’s requests for more information.
Filing the dispute
- Zhang looks into the T&Cs for the contract he digitally signed with the Robert DApp. He finds that the contract names the ECAF as the dispute resolution forum.
- Zhang goes to the ECAF website and in the FAQ finds out how to file his claim.
- On a form on the ECAF website he raises a dispute naming the Robert DApp as respondent. Zhang puts in details of his claim and requests an award of 500 EOS.
- In order to file his claim Zhang needs to pay a small filing fee, which he does in EOS.
- Before submitting his claim, Zhang confirms that he is not filing a false claim and that he will be held liable if this is found to be the case. He also confirms that he will be able to put up a deposit (in the form of a Bond) of at least 10% of the claim.
- He marks the claim as Not urgent (as no tokens are at risk of vanishing from the chain; no imminent harm is feared) and requests that the case is conducted in Chinese.
- Zhang submits the claim on the ECAF website, where it calls an Arbitration smart contract that writes key details of the claim onto an on-chain case registry. This step also sends the claim to the ECAF.
ECAF receives the claim
- Casey, a Case Manager in the ECAF, receives notification that there is a new claim.
- She reviews the case and sees that Zhang has not put in account details for the Robert DApp. She sends an email to the address Zhang provided when he submitted the claim. Zhang responds with more details which Casey adds to the claim. The claim is now complete.
- Casey reviews the claim and notes the industry sector and Zhang’s preference to conduct the arbitration in Chinese. Unfortunately, the Forum’s main Chinese speaking Arbitrator is currently conducting another case. Casey notes that even though the Robert DApp contract that Zhang signed did not specify a language for Arbitration, it was written in English. Using this as a basis to conduct the Arbitration in English, she asks whether Zhang is able to proceed with an English speaking Arbitrator, or if he would prefer to wait for a Chinese speaking Arbitrator. Zhang confirms that he will proceed with an arbitration in English.
- Casey assigns the case to Alice the Arbitrator who is free and has prior experience ruling on insurance disputes. This marks the case as assigned in the Arbitration Smart Contract.
Notice of Claim
- The Arbitration Smart Contract sends emails to both Zhang and Robert using the on chain email service, notifying Zhang that his case has been accepted, and notifying Robert that there is a new dispute filed against him. The email details the case name, Arbitrator assigned, claimed damages etc.
- The emails Zhang and Robert receive ask them both to confirm their receipt of the email. Zhang readily does so, Robert does not confirm.
- A short time period elapses, but Robert still has not confirmed his receipt of the email notifying him of a dispute. (Robert is expected to monitor his email channel and the case registry periodically.)
- The RDR allows Alice to proceed with the case after a certain time period.
- Alice reviews the case details, noting the claim for 500 EOS, she also factors in that it will take her a couple of hours to review the evidence and rule on the case. The ECAF sets guidelines on the maximum rate chargeable for Arbitrator services. Alice totals up the time she and Casey will spend on the case. She adds this amount to Zhang’s 500 EOS claim.
- Alice then writes to Zhang and Robert asking them each to submit a bond of 50 EOS tokens to progress the case. Zhang readily stakes his 50 EOS token share.
- Robert on receiving Alice’s latest message wakes up to the enormity of the situation he finds himself in and agrees to stake the 50 EOS tokens to avoid Alice temporarily ruling that part of his DApp’s assets be frozen.
- The case is now active.
- Alice reviews the evidence and finds that she requires from Zhang details that he took his flight as claimed, his delay, costs incurred for hotel accommodation etc.
- She also needs Robert to provide a defence for why his Dapp did not pay out as contracted.
- Alice passes Casey her requests for further details so that Casey can follow up with Robert and Zhang. This frees up Alice’s time to examine other cases and also ensures that her authority as Arbitrator is not undermined.
- Casey has to remind both Robert and Zhang several times to provide the information requested. (She even had to threaten to report Robert to Alice for non-compliance.) Finally Casey has collected all the information required from Robert and Zhang and attaches it to the case tracking system. She marks it as ready for review by Alice.
- Alice reviews the case details. She finds that Robert’s defense that Zhang did not have a valid insurance contract with the Robert Dapp to be false based on the evidence Zhang submitted.
- (As a famous case study into the incident will later reveal, it turns out that in the deluge of requests, the Robert DApp lost connection with the smart oracle providing flight delay details.)
Alice rules that Zhang’s claim is justified. She rules that Robert should pay Zhang 500 EOS tokens and that Robert should also pay the Arbitration costs to the Forum. The ruling is published containing:
- The identification of the Parties,
- the facts as established by Alice,
- the logic of the rules and law,
- the directions and actions to be taken by each party (the ruling),
- the date that the ruling is rendered,
- Alice’s name and digital signature,
- The distribution of costs for the case.
Alice decides to make the ruling public (she could also, based on the merits of the case, have decided to make it, or elements of it, private).
- On receiving notification from Alice, the ECAF in-house developer writes the transaction that will instruct the Block Producers (BPs) to transfer from Robert’s account the 500 EOS tokens to Zhang and the Arbitration costs to the ECAF.
- The instructions are then sent to the BPs.
BPs effect ruling
- The BPs receive the instruction from Alice. They check that it is indeed her issuing the transaction, that she is affiliated with a valid Arbitration forum and that the instruction is valid.
- The BPs then put the instructions into the queue for execution after 30 days.
Once the ruling is executed and the transfers/remedies are completed, then the case is marked as complete.
Finality of ruling
- Robert is obviously not happy with the turn of events. However, the arbitration ruling is final on both parties.
- Robert may, if he wishes, appeal by filing a new dispute, however this will only be allowed if there is new information that was not considered during the original case. If Robert failed to file all supporting documentation or evidence, it is not justification for the case to be re-opened; it was Robert’s responsibility to adequately document his side of the claim.
After 180 days
- Alice goes on to deal with many more disputes of increasing complexity as she gains expertise and confidence in Arbitration.
- During this time she acts on an interview panel to select additional Arbitrators to the Forum.
- Finally, after 180 days, it is time for the boot forum to get ratified.
- Alice and the other nominee Arbitrators are presented to the Community for ratification.
- A referendum is held where token holders are given the option to reject or approve the ECAF and its Arbitrator nominees.
- The vote passes and the ECAF then has the mandate to continue as the default EOS Arbitration Forum!
(Thanks to the Governance team for reviewing drafts of this.)