This article was written by Cheng Lim, Partner, KWM, TJ Saw, Co-founder, Ethcore, and Calum Sargeant, Solicitor, KWM.
The full article was originally published on the Oxford Business Law Blog.
There has been an explosion of interest in “smart contracts” and blockchain technology over the past two years, with software developers, financial institutions, regulators and law firms rushing in to explore smart contract design and blockchain development. The hype over smart contracts has resulted in headlines such as “Blockchain 'smart contracts' to disrupt lawyers” and speculation that blockchain smart contract technology “threatens thousands of legal jobs and lawyers' role in intermediating commercial negotiations and disputes”.
Advocates of the technology are excited by the potential for smart contracts to encode and perform complex agreements automatically. The dream is to build a contract from a code library which will be stored on a blockchain, signed digitally and which will set in motion an irrevocable set of instructions that will be automatically executed, subject to clearly pre-defined exceptions.
To commercial parties, the appeal of smart contracts lie in (i) the digitisation of trust through certainty of execution, and (ii) the creation of efficiency through the removal of intermediaries and the costs they bring to transactions.
There is little doubt that smart contracts will find compelling use cases and achieve those objectives. But equally, it is important to realise the limitations of smart contracts and understand that there are many elements of contractual relations that are not suitable for performance through deterministic computer logic.
What is a smart contract?
A smart contract shares theoretical similarities with a legal contract, in the sense that they are both frameworks for regulating the interaction between different entities, but it is important to note where those similarities start and end.
A smart contact is, at its heart, a computer programme – encoded logic that receives certain inputs and executes a set of instructions to reach one of many pre-defined outcomes. It is not relevant whether promises or considerations exist between the parties, or whether its instructions were intended or legal. At its heart, a smart contract’s encoded logic simply guarantees execution of a particular code base.
What is the difference between a smart contract and a normal contract?
A normal, non-smart, or “dumb” contract, on the other hand, is an agreement between two or more parties characterised by mutual promises or obligations, and is enforceable by law.
A dumb contract can be thought of as serving multiple and possibly interlocking goals:
- database of obligations – a contract serves as a catalogue of the mutual obligations and promises between two or more parties. It is a collection of negotiated points relating to a particular agreement between the parties, stated in language that parties can refer to and at least in theory understand. Even so, there are many situations in which courts have to determine what the parties agreed, or intended to agree, in their contract, leading to rules of law such as the parol evidence rule, and the implication of terms into contracts which are “so obvious, that they go without saying”;
- regulating the relationship between contracting parties – a contract is given legal effect by the surrounding framework of laws in which the contract sits, thus ensuring that parties are held to their obligations. The legal framework elevates an agreement from a moral obligation to an obligation that is recognised and enforced by society at large; and
- part of the execution mechanism – a contract may also contain elements of a mechanism by which contractual obligations can be executed. Wrapping an obligation in the cloak of contract creates an expectation of performance supported by the external legal framework, giving rise to an “execution norm”. The prospect of legal enforcement that attaches to a contract, as opposed to a moral obligation, increases confidence that the obligation will be performed.
How does a smart contract compare to a “dumb” contract?
While a smart contract may contain some part of the “database of obligations” between the parties in its instructions, it is unlikely to be a comprehensive catalogue of all those obligations, particularly where the contractual obligations are complex. This is because:
- parties may negotiate terms that are not capable of being assessed deterministically by a computer program (that is, not capable of Boolean expression and an algorithmic determination, but instead requiring human judgement);
- in order to be sufficiently expressive, obligations may import indeterminate concepts of reasonableness or appropriateness that again are not suited to algorithmic determination;
- the expression of an obligation in code may not accurately reflect the agreement between the parties (for example because of error or omission); and
- the contract may itself contain a further agreement to agree, or a mechanism for amending the contract which is not in itself algorithmically deterministic.
Of course, a smart contract is clearly part of the execution mechanism. In fact, it is possible for the smart contract to be the entire execution mechanism and not just an element of it. The execution norm established by a dumb contract could be replaced by the execution norm of irrevocable instructions of a smart contract that guarantees performance. This “guaranteed execution” of encoded obligations is the key feature of a blockchain smart contract.
Smart contracts and our legal framework
The execution of obligations within a smart contract happens independently of the surrounding legal framework. However, this does not prevent that legal framework from applying to and affecting the broader contractual relationship between the parties. It is possible that the law may mandate an outcome which is different to that which is programmed into the smart contract e.g. in order to correct a misrepresentation which is embodied in the code of the smart contract.
In other words, smart contracts do not exist in a vacuum. Leaving aside the inability of smart contracts to document obligations which are not algorithmically deterministic, those who wish to use or establish smart contracts will have to deal with issues which have existed for many years in the “dumb” world. These are issues such as:
- What if the code base does not reflect what the parties understood to be their agreement (e.g. a common mistake of law or fact)?
- What if the effect of the code base was represented by a party to be different to what it actually was (e.g. a misrepresentation)?
- What if one party did not have the legal capacity to enter into the smart contract (e.g. being under age)?
Challenges with public blockchain smart contracts
One particular new issue is the design of smart contracts which sit on a public blockchain and interact with different and possibly hostile actors with misaligned incentives. These smart contracts need to not only deal with the challenges referred to above, but also incorporate principles of defensive programming as well as analysis of the underlying game theoretic design.
In particular, it is imperative for a public smart contract to:
- have its scripting language compile properly into its machine language, in the way it was intended;
- be structured in a ways which is computationally efficient (making use of the fewest state changes to achieve the desired outcome) as it is expensive to devote computational resources over the blockchain to run a program; and
- be robust in its design so that malicious actors may not exploit weaknesses in the code to “stalk” or “spam” the contract and its prevent legitimate intended uses from being executed.
This is more than a theoretical possibility, as illustrated by the recent attack on public blockchain network Ethereum and its Distributed Autonomous Organisation (DAO) smart contract. The DAO was a smart contract created to pool investment funds which at one point totalled $150M worth of the cryptocurrency, Ether. A hacker spotted a mistake in the programming and utilised it to drain the Ether from the DAO into child DAOs controlled by the hacker. Importantly, the underlying Ethereum blockchain and smart contract both functioned in the pre-determined way it was designed, but the failure of proper smart contract design created a functional vulnerability which ultimately undermined the intent of the DAO.
For a non-technical overview of the DAO attack, see How to use humans to make “smart contracts” truly smart.
A model for designing smart contracts
We start from the proposition that a contract is not a set of irrevocable instructions but rather a collection of mutual obligations subject to the overlay of law. A smart contract is a set of instructions that may give effect to the obligations of the parties, but it must also be amenable to rectification where it no longer satisfies the requirements of law or fails to reflect the obligations agreed by the contracting parties. When a smart contract is designed in a way that cannot achieve this, it may result in misalignment between rights recognised by law and rights recognised by the public.
Looked at in this light, a smart contract is really best suited as an execution mechanism for a set of deterministic obligations, rather than as a contract in itself. In some ways it is similar to an “escrow” mechanism which is common in M&A transactions, where money is paid to a trusted third party stakeholder, and which can be released to one or the other party in certain specific, determined circumstances. The smart contract is part of the contractual matrix between the parties and is the mechanism by which execution of certain obligations is guaranteed.
We consider the following to be an appropriate model for designing and implementing smart contracts:
- there would be a dumb contract between the parties, in the form of a “legal wrapper” which sets out terms of the contract which are not deterministic and not suitable for execution through the smart contract. An example of this would be a right to terminate a contract or take a particular action because of the occurrence of a “material adverse event”;
- the smart contract code must be designed to execute elements of the contract suited to algorithmic determination, for example an obligation to pay an amount of money at a fixed time, or a process for determining an interest rate by reference to a margin and a particular published reference rate such as LIBOR;
- the legal wrapper would incorporate the smart contract code by reference into the contract, but would take priority over the code if there was some conflict between the two;
- there should be a “fail-safe” in the smart contract code, that allows the code to be terminated in certain agreed scenarios by any party to the contract (e.g., by trusted authorities with multi-signatory keys). Consequences of the use of the fail-safe (whether appropriate or not) would be resolved by the parties in accordance with the legal wrapper and within the framework of the law. The “fail-safe” could also allow parties to amend the smart contract code when there is a contract variation, or where a party chooses to waive certain rights under the contract.
We posit that smart contracts are unlikely to make lawyers extinct. In fact, lawyers are going to be just as important for society moving forward, to make sure that smart contracts, like dumb contracts, reflect the intention of the parties and allow for execution of agreed outcomes!