Telos User’s Guide
Understanding: The Arbitration Process
Understanding the Telos Arbitration Process
As blockchain seeks to integrate a broader base of general users, there needs to be a way to address issues such as lost keys or disputes like mistaken transactions, stolen accounts, contracts not performing as described, and business disputes. EOSIO was built on a promise that it would create a way to address these issues that would not challenge the immutability of the blockchain. Telos embraces this promise and has integrated a system of elected arbitrators who can review disputes and order action by the block producers when there is enough evidence to support a clear decision. This chapter discusses the arbitration process so that participants can understand and take part in it.
Let’s start with a set of common definitions for the various parts of Telos and its arbitration process.
Arbitration: A process of dispute resolution outside of courts that
uses an impartial judge known as an arbitrator or arbitral judge.
Arbitration Forum: A set of rules and procedures under which
arbitration may proceed along with arbitrators and administrators
who are trained in and bound by those rules and procedures.
Arbitrator: An impartial judge for the dispute resolution who works
under the rules and procedures of the arbitration forum. In Telos,
arbitrators are elected by the token-holders.
Assigned Arbitrator: The arbitrator or arbitrators assigned to preside
over a case.
Administrator: An organizer of arbitration filings and processes.
In Telos, the administrator is the arbitration system smart contract
which manages all facets of a case throughout its life cycle.
Claimant: The member or members filing a claim in an arbitration case.
Respondent: The member, members, or contract that the claim is filed
against in an arbitration case.
Case: A dispute which has been filed using the arbitration contract.
It may be comprised of one or more claims together with the response(s)
from the respondent.
Claim: A charge that the claimant claims against the respondent.
Response: A respondent’s answer to the charge made in a claim.
Relief: An action that the claimant requests the arbitrator take against
the respondent to rectify the claim.
Decision: The action or actions that an arbitrator orders in order to resolve
the dispute. In Telos, a decision is rendered in the form of a transaction or
transactions to be enacted by the active block producers along with a written
explanation of the arbitrator’s findings in the case.
In order to resolve disputes, all parties must agree on the system to be used beforehand. On Telos, this happens in two places. First, everyone who uses Telos agrees to the rules of Telos governance including the TBNOA (Telos Blockchain Network Operating Agreement) and the TBNARP (Telos Blockchain Network Arbitration Rules and Procedures). All the Telos governance documents are available to read at any time, and are presented by wallet applications such as Sqrl wallet on the first use. In short, by using Telos, everyone agrees to be mutually bound by these rules which include accepting binding arbitration to resolve all disputes on the Telos network and to waive the right to hear these cases in any national court. This is important because Telos is a global network where users and block producers processing transactions exist in many different jurisdictions and some smart contracts arguably exist nowhere at all. Therefore, it’s necessary to have arbitration under Telos rules instead of the rules of the many countries that could otherwise be involved. The fact that users can vote to elect arbitrators and to modify the governance rules add legitimacy to this process.
So, under the Telos governance we all agree to arbitration. We also agree that unless a different arbitration forum is selected in the readable text of a contract, that the forum for this arbitration will be via the Telos elected arbitrators as administered by the Telos arbitration system smart contract. It is possible that other arbitration forums could be selected, including the concept of “code is law” meaning that anything a program actually does is deemed fair and therefore all parties waive their right to any dispute resolution at all. When interacting with a smart contract, always read the human-readable text to see if a different arbitration forum is listed and if it is, that you are comfortable with it as the way to resolve any disputes. If you are not comfortable with it, don’t execute the contract.
The authority for Telos arbitration, then, comes from the agreement from all users to the Telos governance documents’ mutual agreement to use binding arbitration, and from the text of the specific contract in question (if any) that may specify which arbitration forum is to be used. If it is not mentioned, then the forum will be the Telos elected arbitrators and TBNARP.
Standard of Evidence
While Telos aims to add the important abilities to reclaim accounts that have lost their private keys or that have been stolen, it is essential that these retain a very high standard of proof before any action can be taken. Otherwise, arbitration, itself, could become a potential exploit for account theft. In blockchain, the control of cryptographic keys is the general standard required to control any value or information recorded on that account. Telos arbitration aims for a standard of proof that is of the same caliber in almost all circumstances. In blockchain, it is deemed better to take no action and let some funds go to waste than to risk transferring control of an account to parties they do not belong to. Telos arbitration aims to offer an avenue for recovering accounts and resolving disputes when possible, but it needs to maintain this high standard of proof or else the validity of the entire blockchain may be in question. We must accept that there will be cases that cannot be resolved because the proof they can offer is not as strong or nearly as strong as cryptographic proof. All forms of dispute resolution have this limitation.
The role of arbitrators, then, especially in cases of disputed ownership of an account is to receive the arguments and evidence pertaining to the dispute, to evaluate the evidence under a very high standard, and, when sufficient evidence exists to take action, to render a decision that is enacted by the block producers.
Rendering a Decision
At the conclusion of an arbitration, the arbitrator will render a decision. This decision is a summary of the facts of the case: the claimant and respondent, their claims and responses, and a summary of evidence presented including the standard of evidence. Personal identifying information must be omitted from such a summary. (Remember, whatever is recorded on the blockchain is immutable.) However, if a user has chosen to include his or her name in the name of the account, that should not be considered personally identifying information because one could not identify the individual owner of the account from all similarly named people. Finally, a transaction or set of transactions will be ordered for execution by the active block producers.
Here is an example of a possible decision:
In the example, no personal information is revealed by the evidence in Exhibit A, so it can be revealed. Conversely, if the claimant had not possessed cryptographic proof, but instead provided the arbitrator with copies of bank and exchange statements showing the purchase of the account along with other identifying information to establish identity, this information would be described under evidence but not revealed.
This decision should be considered ideal because it mentions the Telos transaction where the owner of ‘accountname2’ recorded an additional cryptographic key for their account, the key itself, and the proof of a valid signing using the random words provided by the arbitrator.
Executing a Decision
Arbitrators have the authority to render decisions or judgements that include the changing of keys or the forced transfer of token amounts, but they do not have the ability to execute them. Only the currently active block producers at any given time may execute these orders. Conversely, the block producers have the ability to execute such changes, but do not have the authority to do so, except when operating under a duly processed judgement from an arbitration proceeding by an elected arbitrator. This provides a set of checks and balances.
The block producers are required to comply with duly processed arbitration judgements from elected arbitrators, and this is the only context in which Telos block producers can make changes related to an account’s keys or token balances. If the block producers do not execute such an order, any that do not are out of compliance with the block producer minimum requirements and may be removed from service for this reason.
Block producers are not expected to deny an arbitration judgement. Primarily, this is because the block producers did not hear the evidence in the case and cannot render an adequate judgement. There are information privacy concerns about revealing information in the arbitration proceedings that should not be revealed to additional parties, including block producers. This is the trusted role of arbitrators. By making execution of the judgements obligatory, block producers are also protected from the responsibility over them.
Block producers do technically have the ability, however, to refuse to execute arbitrator orders. They do this at a risk to themselves as they are liable to be removed for failing to meet the minimum requirements, in which case another block producer would simply rotate in and possibly execute the order, anyway. If a long stream of block producers refused to carry out an arbitrator’s order, at risk to their own ability to serve, this would be “block producer nullification” an unlawful, but not impossible circumstance that would trigger a governance crisis that the Telos voters would need to resolve through referendum or voting in of different block producers. While technically possible, this is expected to be an exceedingly rare occurrence with significant risk to any block producers participating, and therefore only likely in the event of a deeply contentious ruling.
Arbitrators are paid fees for their work. This is necessary both to attract high caliber arbitrators and to ensure that the arbitrators have no other stake in the outcome of a case. Arbitration requires work and experience and therefore deserves fair compensation.
Each arbitration filing carries an initial fee to prevent frivolous filings. This initial fee is not refundable, even if a case is dropped or dismissed.
The arbitrator assigned to a case will provide an estimated fee for the arbitration that may be borne by the claimant, respondent, or partially by each before the arbitration can proceed. The filing fee will be credited against the estimated fee the arbitrator calculates.
A final arbitration fee amount will be calculated at the end of the case, considering all work performed by the arbitrator and any additional expenses necessary, such as expert witnesses or translation services. The final fees may be paid prior to execution of the decision, or executed as part of the decision. If the arbitration decision determines the relative responsibilities of the parties and if their agreement allows, then arbitration fees may be levied on either side.
Arbitrators must not record private identifying information into the record. Instead, any such information submitted will be described as to its nature and whether or not it provided acceptable evidence (when combined with other evidence) to determine identity, ownership, or whatever is intended to be proven — without directly sharing the information itself.
For example, a copy of a claimant’s receipts from an exchange account showing the original transfer of funds into a respondent account would be described rather than posted because this information would be highly private. Only the fact that the arbitrator had received this evidence, had ruled it admissible (or inadmissible), and the fact that it did show payments from the claimant’s account into the respondent account need to be recorded, not the document itself.
Arbitrators who may have a personal stake in the outcome of an arbitration case or who personally have a relationship with, dependency on, or past action against any party in the arbitration, or any other reason that might influence their judgement separate from the facts of the case must recuse themselves from hearing an arbitration case. Arbitrators must recuse themselves from any case where pressure is brought to bear against them regarding the case by any government or organization with the ability to influence the arbitrator’s decision.
When an arbitrator recuses him- or herself, the case must be assigned a new arbitrator and will begin anew.
Arbitrators may remove themselves from a case as a recusal. When an arbitrator has been found unsuitable to serve by three other arbitrators, they may be dismissed from a case. While this may suggest situations where an arbitrator is pushed out of service by others with or without cause, it is perhaps more likely that this will occur when an arbitrator becomes incapacitated and unable to either complete the cases currently assigned nor remove him- or herself from service. There must be a way to remove arbitrators in such situations whether due to death, incapacity, or some other reason. Otherwise cases would become hopelessly stuck. Removing arbitrators already assigned to a case is expected to be an uncommon occurrence.
In cases where it is alleged that an account has been misappropriated by a thief, time is of the essence. Typically, a thief will be able to move any unstaked TLOS tokens immediately while staked tokens will have a three-day unstaking period where freezing an account may preserve funds. For this reason, arbitrators acting on a duly processed case may issue an account freezing order as an interim emergency action under the authority of TBNOA clause 16.
An account may technically be frozen either by adding it to a blacklist maintained by the block producers, or authorizing nullification of the account’s keys, meaning that current account keys would be replaced with “null” keys and no one would be able to perform any action on the account until the arbitrator issues a decision including a new order to restore the original keys or assign new ones. Of these, key nullification is the preferred method and it is highly recommended that it be the only method used.
Before issuing any emergency action, the arbitrator must at the very least receive a case filing requesting this action. It is advisable that prior to issuing such an emergency action order, that the arbitrator research the status of the account to determine if its permissions or keys have recently been changed in a way consistent with the claim, for example.
Here is an example of a possible emergency action order:
While alleged account theft is likely to be the most common reason for requesting emergency action by an arbitrator, other forms may also occur. For example, a contract that is behaving in a way that is clearly against the intent recorded in its human-language terms and therefore accused of misrepresenting its actions could be cause for emergency account freezing action by an arbitrator.
This section will provide an overview of the entire arbitration process. Telos arbitration is administered entirely by the system smart contract eosio.arb (as it exists on the blockchain; also called eosio.arbitration in the Telos Github code repository), so a walkthrough of the process is also essentially a walkthrough of all of the processes of eosio.arb. This part of the chapter will look at the processes and contract actions together, since they are irrevocably intertwined.
When you look at the arbitration process through the eosio.arb contract, something that becomes immediately clear is that, as a smart contract for managing an entire arbitration process on-chain, the eosio.arb contract is highly complex. It contains 26 actions and seven tables, and additionally interfaces with the Trail voting service. One could easily argue that the Telos eosio.arb contract is currently the most complex dapp in the eosio realm. About the only contract that competes with it at this time is the eosio system contract itself. Fortunately, the system is logically organized and many functions fit into groups that make understanding them easier.
Arbitration Phases and Actions
Arbitration is a process that includes eight distinct phases each with a number of possible actions to be called by the arbitrator, claimant, or respondent:
Before a case has been officially submitted, it is in the Case Setup phase. This starts when a prospective claimant calls the ‘filecase’ action to create a unique case number. The user can add or remove claims with the ‘addclaim’ and ‘removeclaim’ actions. Finally, the user pays the filing fee to eosio.arb and calls the ‘readycase’ action to submit the case and claims. (The fee must already be paid for the ‘readycase’ action to be successful.) If a user decides not to advance their case for whatever reason, they can delete all prepared elements using the ‘shredcase’ action.
A user can reclaim any amount held on their behalf in the eosio.arb account by calling the ‘withdraw’ action. A user may want to do this if they overpaid their deposit or decided not to pursue the case before executing the ‘readycase’ action. (Once ‘readycase’ is executed, the fee can no longer be reclaimed.) A user may use the ‘withdraw’ action at any time. It is not affected by the state of the arbitration.
Once a user has called ‘readycase’ and the case is created in the system, it will look for arbitrators that are available to hear new cases. Arbitrators indicate their ability to accept cases by setting their status to “available” using the ‘newarbstatus’ action. Whenever an arbitrator receives a new case, their status is reset to “unavailable” until the arbitrator sets their status to “available” again. This is to protect against an arbitrator being flooded with new cases. However, it means that new arbitration cases can wait for arbitrators to be ready to hear them. When an arbitrator is available, the contract will assign him or her to the case.
During the investigation phase, the arbitrator reviews the case and seeks initial information from the parties. The arbitrator will review each of the claims made by the claimant and move them from the case file to the claims table using the ‘acceptclaim’ action. If the arbitrator finds that the case is of a type that requires additional arbitrators for a hearing, he can request more arbitrators using the ‘addarbs’ action, which returns the case to the “awaiting arbitrators” phase until more arbitrators can be attached.
Once the arbitrator has accepted a claim, the respondent may provide a written response to each claim using the ‘respond’ action.
In some cases, the arbitrator may find very early in the process that the case is without merit the arbitrator may dismiss the case using the ‘dismisscase’ action. Or, less drastically, the arbitrator may dismiss a specific claim, leaving the rest of the case intact using the ‘dismissclaim’ action.
During the case investigation (and subsequent phases), the arbitrator determines the mode of communication with the claimant and respondent — email, for example. The arbitrator may ask for additional supporting evidence or information. For example, if a claimant is seeking restoration of account ownership and has previously stored a second cryptographic key on the account using the ProveAccount or a similar method, then the arbitrator may provide both the claimant and respondent with two random words and ask them each to show control of the second cryptographic key as evidence of account ownership. Parties may also submit additional proposed evidence to the arbitrator without their request.
When parties provide proposed evidence to the arbitrator, whether on their own or at the arbitrator’s request, the arbitrator will make a determination as to whether the proposed evidence will be accepted as evidence. Only accepted evidence will be recorded and used in determining the decision. Evidence that is not recorded may be summarized and the reason for its rejection noted at the arbitrator’s discretion, but this is not required. The arbitrator may record accepted evidence if it does not include personally identifying information. For example, the signed messages provided to establish control of the second cryptographic “ProveAccount” key does not include any personally identifying information. Evidence that does contain such information, for example a passport, should not be recorded, but only summarized.
When the arbitrator is satisfied with the case investigation, he or she can advance it to the next phase (case hearing) using the ‘advancecase’ action.
A case hearing differs from case investigation because the parties are very likely directly meeting with the arbitrator in person or, more likely, via video conferencing. In other ways, the actions of this phase are the same as with the case investigation and deliberation phases. While ideally arbitration would progress in an orderly fashion, in many cases, some action may not happen at the expected time, but should still be allowed, if it can occur later. For example, in a case where the respondent makes no response in the case investigation phase or even the case hearing, but appears during the deliberations with some response, he or she should be allowed to file the response at that time and have it considered. Also, a claim or case may be dismissed, withdrawn, or advanced at any of these times.
Once the arbitrator advances the case hearing to the deliberation phase, ideally the arbitrator or arbitrators would consider evidence presented. However, until a decision is rendered, the parties may still perform any of the actions mentioned in the case investigation and case hearing phases.
Eventually, the arbitrator will render his or her decision on the case using the ‘setruling’ action. This creates the order that will be sent to the active block producers for enforcement. At this point the ruling is set and no other actions from previous phases can be performed.
Once the case decision has been set using the ‘setruling’ action, it is sent to the block producers for enforcement. A decision is enforced when its orders have been completed. However, some orders may not be completely enforced immediately due to a lack of funds. Telos arbitration allows for orders to be maintained in the enforcement phase until fully enforced. For example, if a respondent is found to owe a large sum to the claimant, but does not have enough TLOS to fully enforce the decision order, then the unenforced portion will continue in the enforcement phase until those funds become available or identified as belonging to the same person (if this ever happens).
Resolved or Dismissed
The final phase of a case is that its decision has been fully enforced and it is now resolved. Cases that have been dismissed are in a similar phase. No further action is needed or possible in either of these types of cases. While it may be valuable for some of these cases to persist as precedents for future cases, many of them will simply take up system resources without adding value. (For example, many dismissed cases are unlikely to be of any future value.) To free up resources, arbitrators may perform housekeeping by calling the ‘deletecase’ action to remove these cases from the rolls.
Some functions of arbitrator management exist apart from the phases of an arbitration case. This includes ‘newarbstatus’, where an arbitrator marks himself as available, ‘setlangcodes’, where an arbitrator notes which languages he or she can conduct a case in, and ‘dismissarb’ where an arbitrator can be dismissed from a case by other arbitrators. An arbitrator may recuse him or herself from a case using the ‘recuse’ action.
The Arbitration Portal
The various phases of arbitration are managed by the arbitration portal, which serves to clarify the arbitration process for arbitrators and parties. If the Telos arbitration process is essentially a large decentralized application, then the arbitration contract and all of its various actions is the smart contract and the arbitration portal is the front end that users can interact with.
The Telos arbitration portal is accessible at https://arb.telosfoundation.io. All of the actions described above can be invoked there (only by the appropriate parties, of course). The Telos Users’ Guide “Arbitration Process Tutorial” is a companion to this chapter and illustrates each action step-by-step.
Failure to Respond
Telos arbitration has certain features that are less common in other judicial systems. One example of this is the strong cryptographic evidence that is expected in almost every case. Few other judicial systems can regularly expect such strong evidence. Another uncommon feature is the anonymity of many claimants and respondents. While Telos arbitrators must reveal their identities, there is no requirement for claimants and respondents to do so. A party may choose to reveal their true identity (supported by evidence) in an effort to better establish their case, but it is not required and certainly cannot be forced.
Because the parties can remain anonymous and because it’s very likely that one party (and in most cases, only one party) may be able to prevent very strong cryptographic evidence, it is very likely that the other party, typically the respondent, will simply not engage in the arbitration at all. In fact, in cases where the ownership of an account is in question, either from lost keys or account theft, it is expected that no respondent will ever respond.
Since there is an expectation that many respondents will never respond, arbitration must be able to continue “in absentia” where no response is ever received from the respondent, otherwise, the arbitration system would be stymied. This has been foreseen in the TBNARP clause #23 “Arbitration in Absentia.” The two important protections that must exist are that, if a respondent does emerge any time before a decision is rendered, they shall be heard and present evidence, and that claimants need to provide strong evidence, usually cryptographic evidence of ownership before arbitrators can order action. Otherwise there would be the risk of bad actors stealing accounts by filing arbitrations against parties who may not be available to respond.
Aside from managing various arbitration proceedings, the arbitration contract/system must also allow users to nominate themselves as arbitrator candidates and then conduct an election so that arbitrators can be elected for service. This is more fully explained in the TUG chapter “Understanding Telos Arbitration Elections”. However, we will touch on the processes here in brief.
Before any arbitrator elections can take place, the block producers must first configure the parameters. These are: how many arbitrators may serve at a time, how long each election will last, when the next election will begin, how long arbitrators serve, and the basic non-refundable fee that any filer is charged in order to register an arbitration case. These are all set by the ‘setconfig’ action. To begin a new election without changing the parameters from setconfig, the block producers can call ‘initelection’. These are the actions that the block producers alone can take and must sign via a multisig (multiple signature) transaction.
The next set of actions for the arbitrator elections are those taken by candidates themselves. Anyone who wishes to become a Telos elected arbitrator must call the ‘regarb’ action and agree to the terms of its human-language contract. To actually be added to a ballot, the account must also call ‘candaddlead’ (add candidate to leaderboard election) to be listed on the Trail voting service leaderboard election for arbitrators. Sqrl wallet automatically does both of these actions with its “Apply as Arbitrator” function on the Governance | Arbitration tab-page. Removing oneself as an arbitrator candidate similarly performs both ‘candrmvlead’ (remove candidate from leaderboard election) and ‘unregnominee’. When elections are complete, ‘endelection’ finalizes the results. (It can only be called by one of the registered candidates.)
Telos arbitration system is complex and fully understanding it may take some time. This chapter attempts to clarify the process as much as possible, but most readers are likely to require several readings before fully understanding the process. Telos arbitration is the world’s first self-contained and blockchain-managed judicial system. If you are an arbitrator or candidate, or if you are a party to an arbitration or may become one, give yourself ample time to understand the system and seek additional resources to round out your understanding.
More about GoodBlock can be found at: www.goodblock.io
Join us on Twitter @GoodBlockio
Vote for GoodBlock on the Telos Blockchain Network @goodblocktls