“Smart contract” is a buzzword phrase which could mean anything and be used to justify everything, from the realisation of the value of blockchain (another buzzword) to the end of lawyers (that can’t be right). To many, the recent “attack” on the most visible large smart contract in the world (the ominously named Decentralised Autonomous Organisation or DAO) has been a reality check for the dreams of replacing laws with computer code. Was this the warning of the “Skynet” moment for this nascent technology, a prescient alert to the dangers in delegating too much to the machines? Well, yes and no: but there is a way of combining the best of both human judgment and computer efficiency in the world of financial market contracts.
In this alert, we strip away the hype and decode the buzzwords. We tell you what these “smart contracts” really are and why people care. Also, we explain (in non-tech speak) what the “DAO attack” was and the fears it created for smart contracts. We then propose a solution, a new “DnA” (Digital and Analogue) architecture for smart contracts, a blend of human and machine. We provide a link to our work on this for you to review, test and improve. All open-source.
Are smart contracts actually … well, not that smart?
A smart contract is simply any agreement which can execute part of its functions itself. An example is a contract which automatically calculates the amount of the payments which have to be paid and then arranges for them to be made. The self-executing part is achieved through a software program that gives effect to what the parties have agreed and the agreement is recorded on a system which allows that software to take effect. That’s all it is. Other than this, nothing else is needed for it to be a “smart contract”. So it doesn’t really have to be that smart. There are a whole range of possibilities and a smart contract could automate its entire life-cycle or just a single process. We think that in between is the best approach, but more on that later.
If you want more on smart contracts, take a look at 10 points on financial market smart contracts.
Why does anyone care about smart contracts?
Smart contracts can make life easier. Automating the processes required to be performed under a contract – such as calculations, payment flows and settlements – can occur much faster and with less risk of error. This is because those processes don’t need a human to perform them. On these sorts of tasks, humans can make errors and are not as fast as computers.
The upside of smart contracts increases when another buzzword is added - blockchain. When smart contracts are designed to interlock on a blockchain (or other distributed ledger technology) then certainty and resilience is added. If the contract is going to be making its own payments and deliveries on behalf of the parties then it is a good thing that the terms have been verified as having been agreed by other disinterested parties and are protected from attack by being held on multiple systems. This is what blockchain can do (see 10 points on blockchain in financial markets). Putting smart contracts together with blockchain can significantly transform the way in which contracting parties deal with each other.
So what was that problem with the “DAO”?
The DAO (Decentralised Autonomous Organisation) is an application on a particular blockchain (one that is run by the Ethereum Foundation). This blockchain is a platform for running smart contracts. It was created to offer “a new kind of law”, which uses a digital currency and a programming language to define and enforce “unbreakable” agreements between parties. According to this line of thinking, the software code acts as if it were the law, the sole determinant of the rights and obligations of the parties. What the code says is what gets done. The smart contracts on this platform are described as "applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference."
The DAO application used this smart contract platform to operate a collective investment facility without needing an entity to play a coordinating or administrative role, to “run” it. Participants contribute amounts of digital currency (called “ether”) which becomes subject to the software code and then those participants vote through the software code to determine how the digital currency is invested and used. It was amazingly popular. By the end of its funding period it had raised US$150 million from more than 11,000 members. This was all held on the terms of the software code only.
Earlier this month, things took an unexpected turn. An “attacker” took advantage of a loophole in the software code of the DAO (not the Ethereum platform). This appears to have been something called a “recursive call bug” which allowed the attacker to keep making withdrawals of digital currency before the previous withdrawals took effect. By the time that the attack became apparent a substantial portion of the total amount of digital currency held on the DAO (worth around US$50 million) had been moved to a separate account, out of the control of the DAO’s members. The infographic below explains this:
This caused lots of problems. The fundamental issue is that the “attack” was technically permitted under the terms of the DAO’s code. It was not a “hack” of that code. If the “code is law” then the result should stand – the members contributed on the basis of the DAO’s code and should remain subject to it, even if it produced this unexpected result. The alternative approach is to orchestrate a “fork” (which is what happens when a blockchain is itself changed) in the Ethereum blockchain to remedy the attack. This would contradict the “code is law” thinking but would arguably be more in line with what would happen in a collective investment arrangement which was not solely governed by software. It is not clear what will happen next, the complexity is increased by there being no centralised resolution framework – this was designed to be a decentralised structure. Whatever does happen next, it is a blow for confidence in smart contracts which are designed for full automation. Trusting the machine to do everything did not work out so well.
But it does not have to end this way. If the framework allowed for human intervention when needed then the incident could have been easily fixed. There should be a smart contract solution which takes the best of computational code and human discretion. We believe that a “Digital” strand has to be blended with an “Analogue” strand – computer with human, to produce a single “truly smart” contract which has the best of both worlds. We refer to this architecture which combines these two strands as “DnA”.
Please read on if you would like to know more about this.
What is DnA smart contract architecture?
One thing which the last two decades has taught financial market participants is that there is such complexity in the marketplace that it is impossible to predict what will happen after something unpredictable happens. Human judgement is needed when dealing with financial market contracts, to assess an extraordinary range of possibilities and to take into account facts and circumstances which are far beyond the terms of any contract.
Take the concept of good faith for example. Trying to explain this to a group of transistors so that it can be computationally executed is currently science fiction (without the use of an enormous amount of code or computing power). Another example is default. Although the loss which is caused by someone’s default might be calculable without using human judgment in some cases, the choice to exercise rights against a defaulter is not. It is based on many factors including other relationships, other assets and other transactions. Quite often the decision whether to enforce against someone in default is a highly nuanced decision, an “art” rather than a “science”. An attempt to codify that decision would only deprive the parties of a valuable right to choose what to do, as well as potentially drain an enormous amount of computer resources. It is just not efficient to try to turn a whole contract into computer code, unless it is truly very simple. And financial markets contracts are not very simple. So if a financial markets contract wants to be “truly smart” then it needs human judgment as well as computer automation.
There are two types of terms in a contract which wants to become “truly smart”: “Digital Terms” that can be efficiently automated through a software program and “Analogue Terms” that cannot. The automation of the Digital Terms takes a lot of manual work out of the performance of the contract. For instance, whenever a calculation needs to be made, a routine payment authorised, or any other computation required, a (properly coded) software program can be used to flawlessly, consistently and efficiently carry out those tasks. The Analogue Terms are the remaining discretionary elements that are impossible, uneconomical or undesirable to automate. These form the rule-book for when humans need to exercise judgment or make decisions.
During the ordinary life-cycle of the contract, when nothing unpredictable is happening, most of the performance should be automated without the need for human intervention. The provisions governing “business-as-usual” are likely to just involve the Digital Terms. Most contracts are likely to stay in that life-cycle for their whole life. When a human has to make a judgement in order for the contract to work (such as because a particular interest rate was not published) then the Analogue Terms come into play. Once this is done, the Digital Terms could return into effect – for any further automated processes or calculations.
Of course, it is absolutely critical that the Digital Terms and Analogue Terms fit together seamlessly and do not give rise to gaps or inconsistencies. The Digital Terms and Analogue Terms need to comprise the one single “truly smart” contract, the “DnA Contract”.
If you would like to see more on how this works, please read on.
Nice theory, but can that actually work?
To show how it works we tested it on a simple interest rate swap. These types of contracts already contain a high degree of standardisation and are well suited to a level of automation. Also, their existing document structure distinguishes between most of the ordinary life-cycle from most of the “out of the ordinary” events. So to test the theory, we prepared Digital Terms to focus only on the calculations and processes in the ordinary life-cycle document, and we found that a significant increase in efficiency was achieved.
The efficiency is depicted in the comparison of the two “swim lane” diagrams below. Each lane represents the involvement of a person, or a computer, in the contract and shows what they need to do to make the contract work. The first shows a traditional interest rate swap. From this it can be seen that the calculation agent has to do a lot of work to make it work. The second shows a DnA contract form of the same interest rate swap. It shows that most of the work is done instead by the computer functions, and the humans are involved only when the judgment is beyond what the computer can efficiently perform. From the difference between the two, it can be seen that under the DNA contract humans need to be involved much less, but without sacrificing important human judgments and discretions when needed.
Diagram 1: Human input under the “business as usual” model
The interest rate swap documented under a traditional contract. The top and bottom "swim lanes" represent the actions of the parties, the middle "swim lane" represents the actions of the calculation agent.
Diagram 2: Human input under the DnA Contract
The DnA Interest Rate Swap. Here there is a new line, representing the Digital Terms. Note that almost every action that was taken by the calculation agent in the “business as usual” model is now automated.
For more on these diagrams, refer to our DnA Contract BPMN processes paper.
Where can you find the open source materials?
Our proposed DnA architecture is available in open source now. We welcome your contributions to it. We have produced discussion drafts of the three elements that are needed for the DnA Interest Rate Swap:
- Digital Terms that demonstrates the computations and inputs that make up those automated aspects of the DnA Contract. These are in a pseudocode, ready to be translated into a functional computing language once a suitable platform is chosen
- Smart contract confirmation that incorporates Analogue Terms from the IRS_Definitions and provides for the DnA Contract to form part of and be subject to a master agreement
- IRS_Definitions that contain a sample of relevant definitions which could be automated and integrated in the Digital and Analogue Terms. This document only seeks to demonstrate the methodology we have applied to convert the required definitions into code and does not comprise a complete or finalised piece.
These are prototypes prepared for testing and discussion only and should not be used for real transactions. All of our documents mentioned in this alert (including the three listed above) are available in open source on our Github repository. This is also where you can access more technical detail on what we have summarised in this alert. We welcome and look forward to your contributions to this project.
Please contact us if you would like to discuss this case study with us.
