A Smart Contract Arbitration Standard for the Internet Age

By Clément Lesaege and Federico Ast

“The grand utility of the law is certainty”.

Jeremy Bentham

The late Middle Ages saw a rapid expansion of long-distance trade. English wool, Italian textiles, German beer, French wine and Greek wax were traded in fairs and independent cities such as Venice, Florence and Genoa. Merchants started to experience the need of a reliable system ensuring that debts were paid, goods were delivered and property was safe.

As merchants spent most of their time traveling in foreign land, a critical concern was how to create a set of common rules and contract standards which could be adjudicated in courts of different fairs and cities.

Lex mercatoria (merchant law) was born to provide fast arbitration and reliable enforcement for an age of growing international trade. It was formed by a number of generally accepted merchant practices concerning the use of bills and notes, insurance, banking, shipping, suretyship, and agency. The main source of the law were merchants and their guilds, not governments. It was based on principles of contract freedom and alienability of property.

Adjudication was done by merchant courts across Europe’s fairs. Thanks to the common standards, a contract signed in Genoa could be adjudicated by a court in Paris or Antwerp. Enforcement was done by the community with a reputation system. Those who failed to comply with the decision of a merchant court were ostracized. Other merchants wouldn’t do business with them (to learn more about the economic impact of medieval merchant law, read Gillian Hadfield’s Rules for a Flat World).

Economists Paul Milgrom, Douglass North and Barry Weingast argued that the private law system of lex mercatoria explain the revival of trade in the Middle Ages. Some towns and fairs became wealthier because their institutions did a better job in supporting trade than their neighbors, in particular those allowing for commercial disputes to be adjudicated by merchant courts, instead of government officials or priests. This was the case of the Champagne fairs of the 13th century and the city state of Venice.

Shakespeare’s “The Merchant of Venice” climax scene takes place in a Venice court of law, where financier Shylock demands that his contract be enforced against Antonio, a merchant who defaulted on his loan. Painting: “The Merchant of Venice’, Act IV, Scene 1, the Trial Scene, Richard Smirke, Royal Shakespeare Company Collection.

The internet age poses a number of similar challenges. As a larger part of the economy starts to operate online across the jurisdictional boundaries of state courts, a new body of law is emerging. It is not created by governments but, as the medieval lex mercatoria, by e-commerce merchants and the platforms where they do business. The nascent ecosystem would greatly benefit from a set of common rules and contract standards allowing for the interoperability of arbitration services.

As part of Kleros’ vision to build a justice protocol for the Internet, we will propose a number of guidelines for building this standard for blockchain smart contracts. Any smart contract following these guidelines should be able to be adjudicated by any court. As the merchants of the Middle Ages chose the best cities and fairs to adjudicate disputes, e-merchants of our time will be able to choose from a variety of adjudication services, all using the same contract standard. Users will be able to select their preferred arbitration service at the moment of doing a transaction which will result in wider choice, better arbitration services and faster growth for the ecosystem.

A case where a user could select the adjudication service provider among a set of different options complying with the standard.

Arbitrable and Arbitrator Contracts

The standard will consist of two kinds of contracts: Arbitrable and Arbitrator contracts, such that every Arbitrable contract can be adjudicated by every Arbitrator contract. Using two contracts allows separation between decision making (i.e ruling) and its execution. This standard will be the subject of an ERC (Ethereum Request for Comments).

Arbitrable Contracts

Contract hash

event ContractHash(bytes32 _contractHash)

When the transaction happens purely on-chain, smart contracts have the ability to self-enforce. When this is the case, there is no need for arbitration.

However, many transactions do not happen purely on-chain. Some smart contracts refer to off-chain elements.

For example:

“Alice agrees to pay Bob 0.1 ETH for 5 pairs of brown alpaca socks to be delivered at 42 Little Indian Street, GA, before October 8th”.

This contract refers to off-chain elements and cannot self-enforce exclusively by code. Adjudication will require some human intervention. Thus, a plain-English version of the contract will be required for human arbitrators to understand it and decide on it.

Should a dispute arise, the arbitrator needs to have access to the contract in plain English. But there are two important issues to consider.

- The arbitrator should not be sent the plain-English contract immediately after it is created.

Only a small fraction of all transactions end in a dispute. This mean that the arbitrator will probably not need the contract. Moreover, in many cases, the arbitrator will not be known at the time the contract is created. For example, in Kleros dispute resolution mechanism, jurors are selected only after the dispute has started.

- The information should not be stored on-chain.

Storing the information on-chain has a high gas cost. Moreover, since since the blockchain can be read by anyone, it would pose severe privacy issues (does Alice want everybody to know her address and that she wears alpaca socks?).

These problems can be addressed by inputting the hash of the plain English contract and a random value at the moment the smart contract is created. It is not possible to obtain the plain English contract from the hash. However, when an arbitrator is given the plain English contract, he can verify that it corresponds to the hash present in the smart contract. In this way, the arbitrator can verify that the plain English contract he is about to adjudicate is exactly the same contract that was agreed by the parties.

The random value helps protect the privacy of the transaction. If the random value was not used, a malicious agent (Chuck) who had access to the contract could try small modifications of it in order to detect similar contracts. Chuck could try to substitute “brown” with other colors like “red”, “black” or “green”, compute the hash and search the blockchain for other contracts referring to that contract hash. In this way, he could know all the colors in Alice’s alpaca socks collection.

The hash of the plain English contract can just be emitted in an event. Since no other smart contracts refer to it, it is cheaper to do it this way than to store it in the state.

Evidence

event Evidence(Arbitrator indexed _arbitrator, uint indexed _disputeID, address _party, string _evidence);

This event is emitted when some piece of evidence is submitted. This allows arbitrators to be alerted of the submission of evidence, and allows parties to prove that they submitted the evidence on time.

In some cases, the parties and arbitrator will have previously agreed on a specific communication channel. Using it would be more efficient since it does not consume gas. But if they have not agreed on the channel, if the channel has become unavailable or if they need to timestamp evidence submission, they can emit evidence events.

Evidence should contain a URI to the resource used as evidence (for example ipfs:/QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG). The file used as evidence must be named as this hash using the multihash protocol. Failing to comply with this requirement would allow a malicious party to change the content of the evidence.

Evidence should be encrypted such that only arbitrators can read it.

Dispute

event Dispute(Arbitrator indexed _arbitrator, uint indexed _disputeID, string _rulingOptions);

This event allows the arbitrator to be notified when a dispute arises. The variable _rulingOptions maps ruling IDs to a short description of the ruling in a CSV format using “;” as a delimiter.

Note that ruling IDs start at 1. For example “Send funds to buyer; Send funds to seller”, means that ruling 1 will make the contract send funds to the buyer and ruling 2, to the seller. The ID 0 is reserved for cases where an arbitrator refuses to arbitrate.

These short descriptions allow arbitrators to understand the consequences of their rulings without having to understand in depth the Arbitrable smart contract. Since the descriptions are short, the amount of gas used will be low.

Arbitrator

Arbitrator public arbitrator

This is the contract that can adjudicate the Arbitrable contract. In this standard, a contract can only be arbitrated by a unique Arbitrator contract. If we wanted to aggregate the ruling of multiple arbitrators, we should make an Arbitrator contract for this purpose.

Rule

function rule(uint _disputeID, uint _ruling)

This is the function the Arbitrator contract should call to adjudicate. In most cases, rule should only be called by the arbitrator contract. Its role is to verify that the caller has the right to rule on the Arbitrable contract. (Note that rule should not be called if parties still have the possibility of appealing the decision).

Execute Ruling

function executeRuling(uint _disputeID, uint _ruling) internal

This function should be called by rule. It executes the actions resulting of the ruling.

The variable _ruling represents the decision of the arbitrator as explained in Dispute. For example in case of a “refund buyer” ruling, this function would send the ETH to the buyer.

Arbitrator

Appeal Possible

AppealPossible(uint _disputeID);

This should be emitted when an action generates the possibility of appealing (e.g., when a first instance decision has been made). Note that, in some cases, the possibility of appeal will arise after some time has passed, but not after a particular action has been made.

In those cases, it is not possible to emit the event (because contracts need to be called to emit event. Of course we could use something as the Ethereum alarm clock, but that would make it more complex and expensive). But it should not be an issue as parties would know in advance when appealing will be possible.

Create Dispute

function createDispute(uint _choices, bytes _extraData) payable returns(uint disputeID)

This function should be called by the Arbitrable contract when a dispute is created.

The variable _choices contains the number of options the arbitrator can choose from. Refusing to arbitrate (choice 0) is not counted toward the number of options.

The _extraData variable allows for the possibility of transferring arbitrary data. This is particularly useful for choosing arbitration options (e.g., in Kleros, the amount of jurors required). Arbitrator contract should always have a default option when this variable is empty.

When creating an Arbitrator contract, creators will need to choose both the Arbitrator and the arbitration options.

It returns disputeID, which is useful as it allows an Arbitrable contract to have multiple disputes, to keep track of them and to know to which one the Arbitrator contract refers to when he calls rule.

Arbitration Cost

function arbitrationCost(bytes _extraData) constant returns(uint fee);

Returns the amount to pay in wei as arbitration fees. The variable _extraData is required as the cost may depend on the arbitration options.

Appeal

function appeal(uint _disputeID, bytes _extraData) payable

This function is to be called to appeal the current ruling. Note that it should be called before rule is called. We don’t expect all contracts to implement an appeal functionality, but in most sophisticated dispute resolution systems the possibility of appealing will exist. Even for a basic centralized arbitrator, the possibility of appealing is important to solve cases where the arbitrator stops responding (otherwise funds could be locked in the contract forever).

Appeal Cost

function appealCost(uint _disputeID, bytes _extraData) constant returns(uint fee);

Returns the amount to pay in wei as arbitration fees. The variable _extraData can be used to choose appeal options. Contracts should ensure that a party can’t delay the ruling too much by making successive frivolous appeals. Therefore we expect the price of appeal to be quickly increasing.

Current Ruling

function currentRuling(uint _disputeID) constant returns(uint ruling)

Returns the current ruling that will be done if there is no appeal. It is useful for parties to decide if they should appeal or not.

The New Contract Law Standard for the Internet

As argued by Milgrom, North and Weingast, the rise of trade in the late Middle Ages and the transition to early capitalism were enabled, at least in part, by a better protection of property rights resulting from the law merchant. This was facilitated by a set of common standards which allowed for contracts to be adjudicated in a network of private merchant courts in the main trade routes.

In the dawn of the decentralized economy, the time has come for the development of standards for securing property rights. The smart contract standard we propose here, since it enables interoperability of courts, is a key step in this direction. If you are building a platform requiring adjucations services, if you are building an arbitration system and if you are developing smart contracts, join us in this effort to build a new smart contract standard. Collaboration will make the ecosystem stronger.

How to contribute?

You can find implementations of this standard in our github. You are welcome to comment, especially if you find one of your use case would not fit in.

Are you attending Devcon3 or in the area at this time? We will hold a meeting to discuss these smart contract standards between all the interested people. Contact us to know more!

You can also join the #arbitration-standard channel our Slack to discuss about this.

Clément Lesaege. Co-Founder and CTO of Kleros.

Federico Ast. Co-Founder and CEO of Kleros.

Learn More

Visit our website

Read our white paper

Get updates on Medium

Follow us on Twitter

Join the conversation on Telegram or Slack

Check out our progress on Github

See Kleros Devcon3 Presentation on YouTube

Telegram Official Announcements Channel