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 in (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 in many instances.  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 embodied in a smart contract.  If there are unrealistic expectations for what the technology can achieve, early adopters may find that they frustrate, rather than simplify, their dealings with others.

We set out in this article to define an appropriate role for smart contracts (whether on a public or consortium blockchain), and to provide a model for designing smart contracts which can operate effectively and safely in a world which is full of uncertainty, ambiguity and that is not deterministic.

A smart contract is not everything

The term ‘smart contract’ is a misnomer.  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 to the encoded logic whether or not promises or consideration exist between the parties, or whether or not representations have been made in relation to the subject matter of the instructions. It is not relevant whether its instructions were intended or legal.  At its heart, a smart contract simply guarantees execution of a particular code base.

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:

  • setting a 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, which has led 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.  The law of the relevant jurisdiction may compel performance of the obligation (as in the case of an order for specific performance or injunction) and may incentivise performance by penalising breach.  Alternatively, the external legal framework may allow for a modification of the obligations in the contract if, for example, there is a need to imply an additional term into the contract.  And of course, the legal framework may allow the contract to be completely voided if, for example, there is illegality or a total failure of consideration; and
  • providing 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 operate without reference to any external legal framework, in that execution or performance of the obligations in the 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, for example 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 (eg 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 (eg a misrepresentation)?
  • What if one party did not have the legal capacity to enter into the smart contract (eg being under age)?

Particular challenges with public blockchain smart contracts

One particular new issue is the design of smart contracts which sit on a public blockchain and which interact with different and possibly hostile actors with misaligned incentives.  These smart contracts need not only to deal with the challenges referred to above, but to 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 way 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 prevent its legitimate intended uses from being executed.

This is more than a theoretical possibility, as illustrated by the recent events surrounding the smart contracting public blockchain network Ethereum and the Distributed Autonomous Organisation (DAO) smart contract that sat on it.  The DAO was a smart contract intended to pool investment funds (which, at one point, totalled $150M worth of the cryptocurrency ‘Ether’) which could be allocated by members of the DAO to different projects.  A hacker spotted a mistake in the programming of the smart contract, 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 in which they were designed, but the failure of proper smart contract design created a functional vulnerability which ultimately undermined the intent of the DAO.

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. Where 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 should 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 should incorporate the smart contract code by reference into the contract, but the dumb contract should 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 (eg, 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 the execution of agreed outcomes.

Cheng Lim is a partner at King & Wood Mallesons, TJ Saw is a Co-founder of Ethcore, and Calum Sargeant is a solicitor at King & Wood Mallesons.