Hashing out the Implications of Smart Contracting under English Law

Distributed Ledger Technology (DLT), commonly known as blockchain technology, is driving a new wave of innovation across many industries. Blockchain is often billed as a technology able to revolutionise how businesses operate, by improving reliability, security and speed due to the decentralisation of transaction approval processes. However, there remain a number of regulatory, technical, legal and practical challenges to the widespread commercial implementation of this technology, which need to be overcome.

One of these challenges is to understand how so-called ‘smart contracts’ may be treated under the law as it stands today and to what extent it is necessary for the law to evolve in order to keep pace with the digitisation of business practices. This is a wide-ranging and important task which is now under review by the Law Commission (as can be seen in its Annual Report for 2017/2018). What is apparent is that significant complexities and practical difficulties could arise when applying existing legal principles in the context of smart contracts – including basic English law concepts relating to contract formation, interpretation and enforcement. 

What are smart contracts and why are they exciting?

Blockchain – the basics

Blockchain was born out of Satoshi Nakamoto’s work on the cryptocurrency Bitcoin and the technology used to prove ownership of that digital asset. The application of this technology, however, goes well beyond cryptocurrencies.

In simple terms, blockchain is a way of recording and verifying data in a decentralised way. This is done through a distributed ledger of transactions (ie a bookkeeping record that is visible simultaneously to all users and updated in real time), which is maintained by its users rather than by a single centralised authority. Each transaction is recorded by all members of the network so that the network contains a continuous and complete record (the chain) of all transactions performed. These transactions are grouped into blocks. A block is only added to the chain if members in the blockchain network reach consensus that it is the next ‘valid’ block to be added to the chain.

Smart contracts – a software tool for automating business practices

A key practical application of blockchain technology is 'smart contracting'. The advent and adoption of smart contracts pre-dates blockchain technology. However, their use as an application of this burgeoning technology is giving smart contracting a renewed appeal.

The term 'smart contract' was coined by Nick Szabo in 1994 as ‘a computerized transaction protocol that executes the terms of a contract. The general objectives of smart contract design are to satisfy common contractual conditions (such as payment terms, liens, confidentiality, and even enforcement), minimize exceptions both malicious and accidental, and minimize the need for trusted intermediaries. Related economic goals include lowering fraud loss, arbitration and enforcement costs, and other transaction costs’.

In short, this term refers to a piece of computer code that is capable of monitoring, executing and enforcing a digital action between two or more parties. Put another way, it is a computer programme which executes a command, such as ‘if A, then do B’.

Use cases for smart contracts

Smart contracts can automate many different kinds of processes and operations. While the most obvious are payments and digital actions conditional on payments, the possibilities for smart contracting to become pervasive – including in relation to complex commercial arrangements – are exciting. Indeed, the potential efficiency gains from digitally automating an action previously completed manually are obvious. Potential use cases are relevant to most, if not all, industry sectors. Some of the most often-cited use cases for blockchain include supply chain tracking, provenance verification, IP licensing, financial and commodity trading, real estate title registration and identity verification. However, the scope for blockchain to disrupt business practices applies more broadly to processes ranging from data control, authentication and title transfer to improved regulatory or contractual controls, increased transparency and security of data.

The Australian National Blockchain

The potential benefits of smart contracting are difficult to dispute and have been heralded for some time. However, to date, existing blockchain infrastructure (ie the underlying digital platform on which blockchain applications can run) has been designed primarily with cryptocurrencies in mind. The 'cyberpunk' objectives of developing fully distributed and permissionless ecosystems (which led to the advent of this new technology) cannot readily be reconciled with the way in which large companies and regulators operate. For this reason, our firm, Herbert Smith Freehills, has teamed up with IBM, CSIRO's Data 61 and King & Wood Mallesons to launch a new digital infrastructure using a private blockchain, which has been designed to account for the practical realities of operating in a regulated world in which parties' contracts need to comply with applicable laws and be enforceable before national courts or tribunals in the event of disputes.

The 'Australian National Blockchain' will be Australia’s first large-scale, enterprise grade and industry-agnostic digital platform and will provide businesses with the ability to automate aspects of their business practice in a legally-valid and compliant, pragmatic way.

The legal effects of smart contracting under English law

Contract formation

The term ‘smart contract’ is a confusing one; it has often been remarked that a smart contract is not, in fact, either smart or a contract (in the traditionally recognised sense). As mentioned above, a smart contract is a computer programme that can execute an ‘if A, then B’ command. While the A and B in this example could themselves be an embedded series of digital actions, it is clear that a command of this nature – if written directly into code – may not necessarily be what English law would call a 'contract'.

On the contrary, treating a smart contract as if it automatically has the effect of a traditional 'natural language' contract under English law would be foolhardy. The qualitative differences between computer code and natural language raise potential hurdles for parties seeking to rely on a smart contract to create binding legal relations.

The technological innovations associated with blockchain technology, which result in the practical immutability of published transactions, create legal uncertainty about how courts and tribunals will interpret and enforce parties' agreements written in code. This is especially the case when parties seek to rely on the smart contract language (ie the computer code) directly, rather than agreeing a traditional, valid and binding natural language contract of which one or more clauses are subsequently translated into code and published to the blockchain.

Indeed, to have a legally enforceable contract which gives rise to new rights and duties between its parties, the following five elements need to be present: (i) offer; (ii) acceptance; (iii) consideration; (iv) intention to create legal relations; and (iv) certainty of terms. Quite plainly, a standalone 'smart contract' to the effect that ‘If the FTSE 100 is below 7,500 at 1pm London time on Tuesday, transfer [a digital asset] from Charlie to Rachel’ lacks several of those elements.

Offer and Acceptance

Insofar as the applicable blockchain infrastructure requires all parties to a transaction to approve it using their respective private keys, the very publication of the smart contract to the blockchain may evidence that an offer has been made and accepted. However, it might be more difficult to identify which party made the offer and which party(ies) accepted it. Similarly, it might also be difficult to identify when the acceptance took place (and therefore when a valid contractual obligation came into effect). For example, acceptance could be said to occur at the time when the final party to the transaction approved it by means of entering its private key or only when the transaction is approved through the consensus mechanism and published to the blockchain (in encrypted form) as part of a valid block. A third option, depending on the way in which the applicable blockchain platform is designed, might be to treat transactions as 'final' only when the block in which they feature has been linked to a certain number of subsequent blocks.

A similar issue in this context would be to identify where acceptance took place. The answer to that question would be relevant to the question of jurisdiction (ie failing an express agreement between the parties, which courts would be the right place to bring a claim).

Consideration

As to consideration, English courts do not question the adequacy of consideration, but there must be some exchange of value. Where a smart contract reflects a digital action which turns on an event which is outside the parties' direct control, it may be unclear what consideration is being given by the recipient. It is therefore important that any smart contracts of this nature sit within a broader interlinked network of smart contracts or link back to a broader (natural language) agreement in which bilateral consideration can be identified.

Intention to create legal relations

A valid contract under English law requires intention to create legal relations. The parties’ ‘intentions’ are gauged by reference to an objective analysis of the contractual documentation itself including, for instance, by reference to any contractual recitals. However, of itself, the smart contract may not evidence any intention to create a binding legal obligation (particularly where it does not identify any applicable law or dispute resolution forum). Parties could instead try to rely on the presumption of intention between commercial parties. However, this could more easily be rebutted in the context of a standalone smart contract, particularly as the smart contract would probably not be drafted directly by lawyers.

Certainty of terms

Two aspects of smart contracting could represent a hurdle for 'certainty of terms'. First, smart contracts may be designed (particularly when further developments are made in the field of artificial intelligence) to evolve autonomously and in a way which the parties (and courts or tribunals) may not be able to anticipate at the time of contracting.

Second, natural language terms which are often used in practice to avoid absolute obligations while maintaining adequate certainty (such as concepts of ‘reasonableness’, ‘unconscionability’ or ‘negligence’) cannot be written in computer code.

The potential issues raised above could theoretically be solved as part of the coding process (eg evidencing an intention to create legal relations by including non-functional notes in the software coding, which would have a similar effect to recitals and confirm the parties' intentions to be bound). However, this requires parties to engage in a legally-compliant and lawyer-led approach to the design of the blockchain ecosystem and the drafting of smart contracts. This is the approach that Herbert Smith Freehills has taken in designing the technical infrastructure for the Australian National Blockchain and the ‘smart legal contracts’ (as opposed to ‘smart contracts’) which it is intended will operate on it.

Contract interpretation

If the FTSE 100 example above was correctly coded into a smart contract and published to a blockchain platform, then the programme may execute according to the parties' wishes. However, if the data source which was intended to confirm to the computer programme the index level at the relevant time failed or no longer existed, or if the digital asset to be transferred was not available in Charlie's wallet at 1pm on Tuesday, then Rachel might get limited support from the English courts or an arbitral tribunal applying English law. The smart contract may not be enforceable as a matter of law should things not happen as planned. Assuming, however, that a smart contract has been written in a way that clearly evidences the requisite conditions for contract formation, how would a court or tribunal proceed to interpret the parties' agreement?

However clearly parties think they have articulated their intentions at the time of contracting, natural language contracts very often generate difficult questions of interpretation when a given clause or provision comes to be implemented.

This may be because the parties had different understandings and intentions at the time of contracting which did not get flushed out in the negotiation process (or were deliberately left somewhat ambiguous), or because circumstances have changed in such a way that the words (when re-read) no longer carry the same meaning as they initially did to one or other party. In a scenario where the parties to a 'traditional contract' disagree on the meaning of the words used, they can refer the question to a neutral decision maker (generally the courts or an arbitral tribunal). But where the parties have written an obligation or contractual provision into a smart contract, the software will execute in the only way the computer can understand it. In short, computers do not interpret computer code, they merely execute it. That is not to say, however, that the computer will always execute in the way the parties expected or intended.

How would courts or arbitral tribunals apply Lord Neuberger's seven steps for contractual interpretation set out in his judgment in Arnold v Britton [2015] UKSC 36 (at [17]-[23]) when the 'language' which the parties have used is computer code?

To identify the 'natural meaning' of the words used in the computer code would be of no assistance, as the syntax and literal translation of code into English would be largely meaningless. In addition, judges or arbitrators may not themselves have the skillset to read and understand the coding written by the parties. This raises the question of whether parties would need to adduce expert evidence on even the most basic issues of contractual interpretation or, alternatively, if courts and arbitral institutions may need to have on hand for any smart contract-related dispute a standing ‘expert’ who can support the judges or appointed arbitrators. Careful consideration would need to be given to the role of such a 'standing expert' to avoid detracting from the ultimate decision-makers' judicial powers. This also emphasises the need for lawyers to develop a greater understanding of coding logic and languages, and a number of law firms (including ours) are implementing courses to further develop these skillsets internally. It will take a long time, however, for these skills to become pervasive among legal practitioners (let alone among members of the bench).

It is also unclear how the court would identity the intentions of the parties in a case of this nature. In Arnold v Britton, Lord Neuberger refers to ‘identifying what the parties meant through the eyes of a reasonable reader’. However, in the context of smart contracts, the reasonable reader of a piece of code (subject to having evidence of an error or mis-translation in the code) would likely read it in a way that identifies how the computer would execute it. Again, that would not much assist the court, particularly if the principles for contract interpretation remain that the court or tribunal should not depart from the meaning of the words used if they are unambiguous.

A viable solution at this stage would be for parties to ensure that they sign a valid and binding agreement in natural language which expressly takes primacy over the translation of any of its provisions into smart contracts in relation to issues of interpretation. This may not prevent parties, however, arguing that the smart contract in question represented an amendment or collateral agreement which had the effect of changing the way in which the natural language contract should be read.

Remedies where the smart contracts fail to operate as expected

Rectification

Instead of parties seeking to argue that a court or tribunal should interpret a smart contract to mean something different to the way in which it was executed by the computer, they may stand a better chance of implementing the parties' true intentions by seeking to 'rectify' the smart contract coding. In cases of mutual mistake, this would involve one of the parties evidencing that the 'coder' who translated the parties' ‘common intentions’ got it wrong.

Where parties have written their agreement directly into code, the court will look at the evidence available to it, including that of prior negotiations, to determine whether the agreement between the parties is properly re?ected in the code of the smart contract. Interesting questions arise regarding the interplay between contractual interpretation and rectification where the smart contract is a translation of a natural language agreement between the parties.

In a claim for rectification, the parties' subjective intentions will need to be ascertained. However, if the smart contract translates a written agreement, the error would be in the translation of how the written agreement required the parties to act. Interpreting that written agreement would be an exercise in contractual interpretation, ie ascertaining the objective intentions of the parties in accordance with the principles set out in Arnold v Britton.

A further difference of substance with the operation of traditional contracts arises here. Unless the parties have included a 'pause' command – which suspends the operation of the smart contract in the event of a dispute – the smart contract will execute regardless of whether the result reflects or is wildly at odds with the parties' intentions. The computer executing the code will not apply any reasonableness or common sense threshold in executing the code. As such, instead of the usual scenario where a party who complains of the mistake refuses to perform the contract pending an agreed amendment or a determination from a court or tribunal, claims for rectification will often need to be accompanied by a claim for breach, restitution or specific performance (i.e. to undo or counteract the operation of the 'erroneous' smart contract). Declaratory relief in this scenario would likely be inadequate, particularly given the immutability of the smart contract once published to the blockchain.

Frustration, fraud and invalidity

Similar questions may arise where a command of the smart contract reflects an agreement between the parties which, by virtue of a change in circumstances in the non-digital world or by virtue of applicable law, becomes voidable, frustrated or invalid. Again, in the absence of any 'pause' command expressly built into the software code which can be triggered by the parties to suspend the operation of the smart contract, it is unclear how (from a practical perspective) the smart contract could be rescinded. In such circumstances it may be necessary for a court or tribunal to order that the parties take such steps as is necessary to undo or counteract the execution of the smart contract. This may involve the more frequent use of equitable remedies such as accounts of profits, equitable compensation, equitable liens and asset tracing.

Conclusion: is English law ready for a transition to smart contracting?

Current principles under English law regarding contract formation, validity, interpretation or suspension are ill-suited to be directly applied to a contract drafted entirely in computer code. Clearly, there are also practical issues regarding the ability of lawyers, judges and arbitrators to understand, opine on and/or seek to counteract or correct software execution. That being said, the English courts have historically taken a pragmatic approach to the use of new technologies or business practices and the law has developed to accommodate for them in order to ensure that justice is served. It remains to be seen whether a similar approach can or will be taken in relation to smart contracts.

In the meantime, parties can mitigate the risk that the intentions behind their ‘smart contracts’ might be mistranslated into code or misconstrued by judicial or regulatory authorities by reverse engineering blockchain infrastructure and smart contracting design from existing legal principles and legislative requirements. Parties could achieve this by agreeing a 'traditional' natural language contract which sits outside the blockchain and relevant provisions of which are translated into code and published to the blockchain (as a means of implementation, but without any contractual effect). Alternatively, parties can look to develop ‘smart legal contracts’, which are held within the blockchain ecosystem but for which the operative code of the 'smart contracting' applications is not a part of the binding legal mechanics of the agreement. These approaches will also ensure that parties can more readily seek support from traditional judicial authorities (be it courts or arbitral tribunals) to enforce their contractual agreements when the smart contract itself may not execute as planned.

This article was first published in www.scl.org