Usually when a written contract ‘goes wrong’, it is a question of interpretation and clarity of drafting. This is usually resolved by looking at the intention of the parties, and by bringing in witnesses and evidence to support a position. With smart contracts, however, the landscape is fundamentally changed as the code itself is said to comprise the contract.
A “smart contract” is, at its heart, a self-executing computer program on the blockchain — where the outcome under the contract is coded within the contract itself. The computer program not only defines the rules for an agreement (in the same way as a traditional contract), but automatically enforces those rules as well. Smart contracts operate on an ‘if-then’ premise, so singular digitised data points represent the most simple triggers. Examples of where smart contracts are currently being used (or designed for use) are in:
- the banking and financial services sector, including insurance;
- real property sector (sale and short term/long term rental);
- intellectual property (for example, music licensing/royalties); and
- capital raising (via initial coin offerings)
These areas tend to relate to the transfer of property or value, in some form. Title to assets or security interests are some of the simplest rights to tokenise and manipulate with smart contracts. For example:
- executing a sale of shares at a particular price on a stock market;
- automating individual payments on each delivery of a product through the distribution chain; or
- codifying securitisation rules to avoid the need for security trustees.
What happens if smart contracts go wrong?
Usually when a written contract ‘goes wrong’, it is a question of interpretation and an issue around clarity of drafting. This is usually resolved by looking at the intention of the parties at the time, and often by bringing in witnesses or documentary evidence to support a position. Typically, a trusted third party (for example, a mediator, arbitrator or the judiciary) will then assist the parties to reach a resolution, or make a binding determination on the outcome. Those trusted third parties have a body of law (in statutes and legal precedent) to assist them as well. If a lawyer has been negligent in drafting the terms of a contract, a party may have recourse.
With smart contracts, however, the landscape is fundamentally changed as the code itself is said to comprise the contract. An often-cited example of a smart contract going wrong is The DAO. The DAO was a “decentralised autonomous organisation” created as a sort of venture capital fund and effected via a smart contract on the Ethereum platform. It had no management; instead, participants would directly agree to fund projects according to the terms of its establishing smart contract.
In June 2016, a participant to the DAO smart contract exploited a feature of code to siphon off funds. This ‘hack’ raised two competing views on the enforceability of smart contracts. For blockchain fundamentalists, the view was that, as the code in the contract had permitted the breach, the outcome was legitimate by design. The DAO participants, they said, had agreed to be bound by the smart contract, and were therefore bound to any outcome under that code. The opposing view was that participants had more broadly agreed that the DAO would only be used to fund agreed projects.
The issue of which perspective will triumph in future disputes remains unresolved. A strict ‘the code is the contract’ view would see the contract’s code as sole evidence of intention; where the contract and its outcome are the same. In this environment, any parties wanting to enter into a smart contract should seek comprehensive advice as to what will actually happen when the program is run.
Due diligence in this regard will require a range of expertise. The contract might include complex programming and be difficult for anyone who is not an expert in the field to understand. Indeed, it is possible that no one party (ie the contracting party, the lawyers, nor the developers of a smart contract) will have a full understanding of the contract on their own, and there will be a need for strong communication between groups.
“There is a good argument that, as a matter of policy, smart contracts should be applied strictly, and any party to a smart contract intends for this to occur."
On the other hand, adjudicators may adopt a softer interpretation and consider, for example, wider intentions and business common sense. This is the usual approach to contract disputes and there is a large body of law relating to contractual interpretation. Put simply, the main focus here is the parties’ intentions — what would a reasonable person with the same background knowledge understand the contract language to mean?
Evaluated in this way, it seems unlikely that a technical error in a smart contract or an unexpected outcome from an automated contracting process would be within the intention of contracting parties. However, it is unclear the extent to which courts will be willing to apply this traditional approach to smart contracts. There is a good argument that, as a matter of policy, smart contracts should be applied strictly, and any party to a smart contract intends for this to occur.
In this uncertain area, developers will need to carefully consider their risk profile. Small mistakes or misunderstandings in a smart contract might have huge and scalable consequences — and corresponding liability for negligence. For lawyers, this is a familiar concern — our role has always been to use our skill as professionals to ensure contracts work as they are intended, and to take on risk should they not. Smart contracts inevitably cause a blurring of roles for lawyers and developers. Developers who draft contracts and provide legal advice may well be held to the standard of a lawyer (and need similar insurance and professional certification).
While the standards and obligations holding lawyers to account will not change, the skills used will have to. Alternatively, lawyers will need to work with reliable third parties who can accurately code legal concepts on the one hand and interpret complex code on the other. Developers should seek legal advice on any software development agreement they are asked to sign in which they are creating a smart contract. We would be happy to help!
Note: This article is intended only to provide a summary of the subject covered. It does not purport to be comprehensive,or to provide legal advice. No person should act in reliance on any statement contained in this publication without first obtaining specific professional advice.
Tom Maasland specialises in technology-law related matters, including emerging tech, and is a Partner at MinterEllisonRuddWatts