Smart arbitration. The Concept

Smart arbitration

In the previous post I shared some ideas about the smart contracts and fusion solution, when both programming and natural languages move towards each other in an effort to allow the machines to understand legal texts and compile code with minimal interference by humans. As a result, smart arbitration may become possible.

I used the following definition of smart arbitration.

"Smart arbitration is the process of granting an arbitration award by machine in case of a dispute in connection with the smart contract."

Definition

While speaking about smart arbitration definition, I want to address the following aspects.

Smart contract

Any dispute arises out of or in connection with an agreement of some sort. So, smart arbitration is the way to settle disputes out of smart contracts. Smart arbitration is not applicable to other forms of contract, i.e., paper contracts.

For a dispute to be referred to an arbitration, a smart contract has to have a section or block of code, which invokes an arbitration procedure.

Dispute

Dispute is the state of a smart contract, when there is a claim from one party, which is objected by the other party, i.e., when there is no agreement between the parties on some issue.

Parties can object:

the facts (i.e., inputs from oracles),
clauses or conditions (i.e., coding bugs) or
actions (i.e., smart contract performs not as intended).

Arbitration award

Arbitration award is the outcome of the dispute. Regarding smart contracts, an arbitration award may be designed as a function, which triggers actions to be performed by a smart contract.

Such action may be:

reimbursement of damages or payment of penalties — this is simply an execution of some action by smart contract;
granting extension of time — this is a change in the smart contract conditions, which means the time for completion must be variable, but not constant, and arbitration award function must have an override prefix;
termination of smart contract.

Automatic execution of the smart award allows the parties enjoy the core feature of smart contract — execution autonomity.

Machine

The term machine is intended to be construed as wide as possible.

This can be a dedicated server maintained by a reputable international dispute resolution venue.

This can be peering network with some consensus algorithm.

This can be a mix of both above.

Consensus

Usually, arbitration panel consists of several arbitrators, three, sometimes five, rarely more, but always of odd number of persons. In case of even distribution of votes, the vote of the chairman prevails. This is the normal way of achieving consensus among humans.

In blockchain or distributed ledger technologies (DLTs) reaching consensus is far more complicated due to the scale of the network and variety of attacks intended to defraud the network.
A good example of the possible attack scenarios is given at a DLT network IOTA Tangle white paper, section 4, page 15, which can be found here.

However, if the arbitration network is in place, the consensus techniques developed for the blockchain and DLTs may be applicable.

Such arbitration network may consist of multiple nodes, each node being an arbitrator. If a dispute is referred to such arbitration network, each node makes a judgement upon certain algorithm. When the whole network reaches the consensus, the arbitration award is given.

The choice of the consensus algorithm largely depends on the network configuration.

If an established dispute resolution venue maintains the pool of dedicated servers, Raft consensus method may be the preferred choice. Raft naturally mimics the human arbitrators voting process, is a fault tolerant and provides good performance.

In Blockchain/DLTs world the choice of the consensus algorithm becomes one of the major issues. Will it be proof-of-work (PoW), proof-of-stake (PoS), or their derivatives, Tangle-based solution or any voting-based consensus mechanism?

Confidentiality

Blockchain/DLTs however bring to life some issues for in the commercial arbitration sphere. Because the entire case will be visible to the whole network, it becomes impossible to preserve confidentiality.

Masked Authenticated Messaging (MAM) might be a solution, however so far it is applicable to Tangle-based DLTs, specifically IOTA.

Codelegit Arbitration Rules

Here I want to address one of the solutions in the smart contracts arbitration sphere developed by Codelegit, namely Codelegit Arbitration Rules.

Codelegit developed a library, which can be inserted into a smart contract. According to Codelegit, once triggered the library will pause the further execution of the smart contract, and the dispute is referred to arbitration. Triggering the arbitration library can be performed by calling the function pauseAndSendToArbitrator().

My first concern is about suspending the execution of the smart contract. Execution suspension must not be mandatory and must be defined by the parties during the bargaining of the contract, as sometimes the parties explicitly agree that dispute is not a reason to suspend the performance (i.e., see FIDIC Red Book 1999 DAB guide, page 45, Proceed with the Works).

So, two options must be envisaged by a developer:

suspend the smart contract as Codelegit proposes with pauseAndSendToArbitrator(); and
continue the performance continueAndSendToArbitrator().

The second concern relates to the fact that Codelegit solution does not benefit from automatic execution feature, attributable to smart contracts. Codelegit Arbitration Library just suspends the execution, but the dispute is settled by human arbitrators.

Conclusion

The smart contracts have a huge potential. The flip side of the coin is the fact that agreements imply disputes. Inability to effectively resolve disputes out of smart contracts may become an obstacle for smart contracts further development.

So, the convenient, effective and trusted way to settle disputes out of smart contracts is to be designed. Smart arbitration may become a solution, which ideally fits for purpose.