Smart Contracts

Introduction

This chapter from the forthcoming book The Contents of Commercial Contracts: Terms Affecting Freedoms was co-written by Dr Adam Sanitt, Head of Disputes Knowledge, Innovation and Business Support, Norton Rose Fulbright and Professor Sarah Green, University of Bristol, Law Commissioner for England. Reproduced by kind permission of the editors, Professor Paul Davies and Dr Magda Raczynska of University College London.

The technology that makes smart contracts possible³ was developed with a view to enabling transactions to be made end-to-end without the intervention of third parties, intermediaries, adjudicators or courts. In this sense, it achieves in principle complete freedom of interaction. Whether this is the same thing as freedom of contract, however, remains to be seen. It is not yet clear, for example, which smart contracts will be legally enforceable, either because the parties do not want them to be, and/or because the courts do not recognise them as being so. What seems inevitable at this stage in the development of smart contract technology is that conventional contract law in its current form is unlikely to be the most effective way of adjudicating smart contract disputes. One reason for this is that securing performance will be far less of a problem under smart contracts than it is in relation to conventional contracts: the automated nature of the former means that actions are far more likely to be executed than those promised in the traditional way, albeit that their results might not accord with the parties’ expectations. Any issues are therefore far more likely to arise (or at least to be brought to a court’s attention) after a transaction has occurred. Automated execution means that parties are free to determine the contents of their agreements, and that machines will abide by those agreed instructions. The way in which smart contracts operate, therefore, means that any adjudication of them is likely to need to emphasise restorative rather than enforcement remedies. The extent to which the law chooses to do this will effectively determine how free smart technology users are to make legally recognised contracts.

In order to make clear how and why smart contracts differ so markedly from conventional contracts, it is worth setting out a brief description of the relevant technology before turning to its legal analysis.

What is a smart contract?

Smart contracts are self-executing transactions, written in computer code and performed in an automated way. They have been made possible by a particular series of technological developments that have happened over the past decade. These developments have enabled decentralisation and consensus to replace intermediaries in transactions between contracting parties. In other words, contracting parties can now deal directly with one another without banks, without offline registries and, potentially, without lawyers.

Decentralisation and Distributed Consensus

Deentralisation and distributed consensus are the components which distinguish smart transactions from those which use intermediaries and electronic bank money, such as Paypal, WorldPay and BACS. These components also explain why smart contracts are often described as “trustless”, meaning that transacting parties need not trust each other in the real world, so long as they trust the payment protocol (which, for reasons which will soon become apparent, they Pobably should).

Decentralisation is probably easiest to explain in the context of Bitcoin and its Blockchain (Bitcoin being the cryptocurrency and Blockchain the distributed ledger), although there are other platforms, such as Ethereum, on which smart contracts could be made. Decentralisation is achieved through Distributed Ledger Technology (or DLT). This means that everyone who wants to contract using a particular piece of software has, as an integral part of that software, a copy of a ledger. This ledger is a record of every transaction made using that protocol, and each computer operating the software (known as a node) has a copy of the entire thing: from the beginning (the “Genesis Block”) to today’s latest block. Blockchain, which was created to underpin Bitcoin, was the first distributed ledger, but there are now distributed ledgers of several different forms. Common to every one, however, is the idea that all participants have access to the full history of transactions made using that protocol. This is a novel way of dealing with the age-old double spend problem. Historically, the challenge of how to prevent double spending has been met in two ways: the first is by using physical tokens, whose corporeal form physically prevents their being spent more than once, and the second is by employing an independent third party, such as a bank, to keep a record of transactions and their effects on the subsequent spending power of the parties involved. DLT achieves the same thing by sharing information with every user and by ensuring that the information so shared is perfectly synchronised. This way, “coins” cannot be spent twice because everyone would know that this is what was being attempted, and the consensus necessary for validation and recording would not be reached. Security is thus achieved through complete transparency, and distributed ledgers have no need for any centralised record-keeping, nor for any third party intermediary to verify the integrity of transactions. In other words, “total validation replaces central control”.⁴

Such transparency is achieved through what is known as distributed consensus protocol, and this is characterised by two features:

1. All computers on the network (referred to as nodes) must agree on which transaction data is ultimately recorded on the ledger
2. The transaction data must have been generated by an honest node⁵

The question remains how any of this can be achieved. One method, used by Bitcoin, is known as proof-of-work, and this allows nodes to reach a consensus on which transactions to record and in which order to do so. (The order is of course all-important, as it is with any spending pattern, since what you have already spent determines how much you can spend in the future.) Proof-of-work is the means by which nodes persuade other nodes that the block of transactions that they wish to add to the chain is legitimate and should be trusted. The work involved here is cryptography; the solving of a mathematical puzzle, and this puzzle is of a very specific type: the optimal way of solving it is to work through very large numbers of trial and error iterations. In other words, lawyers might say that it is a difficult case, but not a hard one. It is clear what needs to be done, but it takes an immense amount of computational power⁶ to work through the many repetitions of the same calculation, each time trying a different input. The puzzle is known as a hash puzzle and success requires finding the input necessary for a function to produce a specified output. The hash function itself, which is the crux of this whole process, could be described in non-mathematical terms as a function which takes an input and produces an output which will look nothing whatsoever like the input.⁷ In fact, it is practically impossible to discover the original input simply by looking at the output, unless you know the hash function. Diedrich has provided the following illustration of how hashes work.⁸

There are different hash algorithms. One hash algorithm that was once popular was called MD5. For example, this text:

MD5’s designer Ron Rivest has stated “md5 and sha1 are both clearly broken (in terms of collision resistance)”. So MD5 should be avoided when creating new protocols, or implementing protocols with better options. SHA256 and SHA512 are better options as they have been more resilient to attacks (as of 2009).

has the MD5 hash:

ed7f56281b8d079ff101009105f75b44

…The hash ed7f56281b8d079ff101009105f75b44 can be used as a unique id for the above text, for two reasons:

1. If any punctuation or word was changed, you’d get a different hash for it.
2. You will not for your life be able to find another text that results into exactly this hash.⁹

Crucially, the same hash function, applied to identical inputs, will always produce the same output. Applying the same hash function, however, to an input which is different from the original in only a miniscule detail will nonetheless result in a completely different output. This explains why the only way to solve such puzzles is through repeated trial and error: there are no shortcuts or clues provided by previous work and the results of previous attempts are not in any way cumulatively helpful. So, Sherlock Holmes could not take the approach he took to the Dancing Men.

Instead, nodes who wish to add a block to the chain first take a set of transactions that have been broadcast¹⁰ across the network. They then add to this something called a blockhash. A blockhash is the output generated when the hash function is applied to the whole of the previous block in the chain. This blockhash serves therefore as a unique identifier of all the data in that previous block, and so is what links the blocks (hence the term chain) and at the same time makes the protocol so secure: embedding this unique summary of the previous block’s data in the following block, and therefore in all future blocks,¹¹ makes the blockchain practically tamperproof. If any node wants to alter or modify the content of any given block, it would also have to rehash all of the blocks which follow it, and compete to persuade all nodes (who would be working on the basis that the original date were correct) that the new reality was the right one. This is so difficult, particularly in terms of computational power, as to be well-nigh impossible in the current environment.

So, to return to the proposing node, which has taken the set of transactions it wishes to verify, and added the blockhash.¹² The node then starts the real work: it also adds a value as the mystery input, which is known as a “nonce” in cryptography. It then hashes all of this together (which means applying a specific and consistent hash function, which in the case of Bitcoin is called SHA256) and keeps doing this, using a different nonce each time, until it gets an output with the “correct” number of leading zeros.¹³

At the heart of this scheme is the fact that a nonce is hard to find but easy to verify. While it routinely takes trillions of trial-and-error calculations to find it, it requires but one calculation to verify it: to test that a nonce is in fact resulting into a hash with the required number of leading zeros when added to the block data that it was found for.¹⁴

This is known as “trapdoor” maths because of its one-way structure; it’s very difficult to find the answer but, once you have the answer, it’s very easy to verify that it’s the right one. A simple analogy can be made with the combination to a briefcase lock. Anyone wishing to open the briefcase without knowing the combination will have to try (probably) very many attempted combinations to find the one which opens the case. Once she has found it, however, it is very easy for someone else to verify that she has found the correct combination: the verifier simply needs to put that combination into the briefcase dial and see if it opens. The result is a binary one – pass or fail. Similarly, once a node has found what it believes to be the right nonce, the other nodes verify that it’s correct by simply applying it to the publicly-available data. If this produces the same output (the one with the required number of leading zeros), verification is complete. Once this happens, the proposed block gets added to the chain and the transactions in it get confirmed.¹⁵

This, however, is not the only thing which happens when the block gets verified. Another of DLT’s revolutionary qualities is its alignment of self-interest with altruism. Verifying blocks is hard grind and very expensive in computational terms, and yet it is essential to the continuation and security of the system. So, when a node successfully adds a block to the chain, it gets rewarded with bitcoin. In the Bitcoin protocol, the verification process is known as mining, and is simultaneously the means by which new coin is minted.¹⁶ This is a system, therefore, in which self-interest works in favour of the collective interest, and the two are mutually reinforcing. Not all DLT systems use proof-of-work, and not all reward nodes with cryptocurrency, but some sort of consensus is required to maintain the ledger. This consensus may be limited to approval by an entity or group of entities, known as notaries, nominated by the parties to a transaction, with the DLT system providing only a secure messaging protocol to communicate that consensus. A more distributed approach is achieved by DLT systems that dispense with a blockchain and instead require transactions to be approved by groups of later transactions forming a web carefully designed to avoid circularity (known as a directed acyclic graph, or DAG). Other variants keep the blockchain but opt for consensus protocols other than proof-of-work. To the extent that DLT systems employ distributed consensus as the means of achieving decentralisation, they are all able to facilitate direct contracting between parties without needing to involve intermediaries.

In practical terms, smart contracts differ from conventional contracts in the following ways:

• The entire lifecycle of a smart contract, from formulation to execution, occurs online
• That lifecycle need not at any point involve any entity other than the contracting parties (since, for instance, payment can occur directly from bitcoin wallet to bitcoin wallet)
• Performance is automated and is carried out by the machine, following its programmed instructions
• Smart contracts are immutably recorded and programmed on the distributed ledger and cannot be altered. If “rectification” is required, a new contract must be written which reverses or modifies the effects of the previous contract
• A smart contract can only perform in a situation in which there is an “algorithmically determinable solution”. In other words, there is no room in a smart contract for discretion, reasonableness or judgment: potential outcomes will be binary in form

Smart contracts, therefore, will only be useful for transactions of a certain type. An obvious example of the type of transaction to which smart contracts would be well-suited is the transfer of title to assets. Such transactions often take the form of requiring title to be transferred on the receipt of a certain amount of funds into a particular account, perhaps with the added requirement of verifying the absence of any charges over the asset.¹⁷ According to the logic of machines, this is simply an action to be performed on the satisfaction of a given condition or set of conditions: ideal for a self-executing algorithm. Machines are arguably better placed than humans to perform such one-dimensional tasks, since, properly programmed, they are simply unable to refuse to act, to omit a condition or to fail to perform. Smart contracts offer, therefore, the potential for reducing transactions costs, defective performance and informational asymmetry between parties. (The potential for defective performance does not, of course, disappear; it shifts its locus to the coder responsible for programming the machine, but that is an issue for another time and place.)

Formation: The spectrum of smart contracts in practice

A lawyer and a coder will not necessarily have the same conception of a smart contract. The term “smart contract” was coined by Nick Szabo, and was defined by him 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”¹⁸

This use of the c word would probably not satisfy a lawyer. At the very least however, there will be a subset of those transactions referred to by users as smart contracts which will also satisfy the legal criteria of enforceable contracts, such as those which adhere to the legal rules of formation.

There may be more to a smart contract than an independent chunk of self-executing code. At one end of the spectrum, a conventional natural language contract may include a short section of code that implements a single clause. This is similar in effect to the inclusion by reference in a contract of a formula or a specific manufacturing design. The Courts have interpreted these references strictly – requiring them to be followed precisely while simultaneously complying with all other obligations in the contract, even ones that are apparently contradictory:

“Where a contract contains terms which require an item (i) which is to be produced in accordance with a prescribed design, and (ii) which, when provided, will comply with prescribed criteria, and literal conformity with the prescribed design will inevitably result in the product falling short of one or more of the prescribed criteria, it by no means follows that the two terms are mutually inconsistent”¹⁹

The effect appears to be that a counterparty cannot satisfy its obligations merely by executing a piece of code even where that code is explicitly agreed in the contract. Other contractual terms may be used to show that the counterparty had to do more. The code provides convenience but not necessarily certainty. The harshness of this approach is illustrated in Hojgaard v EON, from which the extract above is taken. In a contract to build an offshore wind farm, both parties agreed to use an international standard for the design of wind turbines. Unknown to them, one formula in the standard contained a constant with a misplaced decimal point. When the defect came to light, the builder was held liable for breach of warranties contained elsewhere in the documentation – its exact compliance with the design specification was not sufficient. Applied to smart contracts, this suggests that a piece of code included in a natural language contract will not be interpreted in isolation and executing the code may not be sufficient to comply with the contract.

Further along the spectrum is the combination of self-executing code and natural language contract known as the ‘Ricardian contract’²⁰. This consists of a piece of code contained in a DLT which contains a hashed reference to a natural language contract. As described above, a hash is a cryptographically secure method of creating a reference to a particular document. Anybody with the natural language document can easily check that it corresponds to the hash in the code. And changing even a single comma in the document would lead to it producing a completely different hash. So this mechanism inextricably links the code and the written document into a single agreement. A Ricardian contract could be used simply to implement the single formula in code considered above. In practice, it is generally employed to supplement a contract that is primarily smart, by adding a few natural language provisions. Popular options for natural language clauses ‘bolted on’ to a smart contract in this way include governing law and jurisdiction clauses and dispute resolution mechanisms.

Furthest along the spectrum is a smart contract that consists only of code and expressly excludes any other language and all contractual oversight. This is achieved through an apparently paradoxical method. The smart contract includes a natural language provision stating expressly that it is not a legally enforceable contract: an explicit denial of an intention to create legal relations. This type of smart contract is for parties who wish to rely entirely on the DLT to carry out their intentions and to remove any possibility of the legal system stepping in to reverse their immutable transactions. The motivation for this may be ideological – parties might be transacting on a DLT in order to remove themselves from the sphere of influence of a particular legal system or to facilitate cross-border commerce when there is no single legal system to which they will agree to submit. Although it may seem farfetched to lawyers and legal academics, this ideology is common in the communities from which DLT emerged. Indeed, Bitcoin is often portrayed as a means of payment that is beyond the reach of legal oversight. Whilst this has led in the past to negative publicity, centred on the technology’s involvement in criminal activity, it is a fact that many legal systems are expensive, inaccessible or corrupt, and many fiat currencies subject to bouts of inflation. There are, therefore, legitimate reasons why people seek to exclude the apparatus of national law. The concept of an intention to create legal relations in the context of smart contracting is examined further below.

Code as Contract

The technology which makes smart contracts possible, and perhaps more significantly the ethos underlying that technology, gives rise to a fundamental question: to what extent can and should the law govern smart, peer-to-peer interaction? The original Blockchain protocol was, after all, created with a view to eschewing conventional third party intervention and regulation, explicitly substituting a model by which all users participate in complete self-governance. Although it is neither realistic nor practical to suggest that total internal governance should prevail, given the now extensive uses made of DLT, a question nonetheless remains about the extent to which those engaging in smart transactions could expect to have their interactions regulated by the protocol, rather than by external agencies such as courts, arbitrators and lawyers. Internal regulation and resolution is certainly possible as a result of DLT technology: this could take the form of coded responses to certain conditions, or a requirement for multi-signature approval for the transfer of funds. In the latter situation, a third party would need to verify that, for instance, payment conditions had been met before releasing funds to either party. Such an arrangement could perform the role played in conventional transactions by escrow or trust arrangements.

In forensic terms, this amounts to a question of whether the parties have demonstrated the necessary intention to create legal relations. Such an intention is, of course, a prerequisite for an agreement to be the source of legal rights and obligations and to be enforceable by the Courts. Most problems concerning an intention to create legal relations arise from an agreement that features a level of informality or vagueness which precludes the Court from applying the machinery of contract law to it, disappointing one of the parties to the agreement who cannot enforce it. Smart contracts feature the converse situation: an agreement which is precise and intended to be carried out on commercial terms, but which the parties nevertheless do not wish to be enforceable through the Courts. The self-executing nature of smart contracts mean that this is not a contradictory position, but it is one nonetheless that the Courts have not previously addressed.

Take a Ricardian contract, expressed partly in code and partly in prose, where the wording of the prose section includes a statement that the parties do not intend the agreement to create legal relations.²¹ The intuitive starting point is that this statement is inconsistent with an intention to create legal relations and so no contract is formed. That starting point is not necessarily correct. The Courts will look at the entirety of the agreement to determine the objective intention of the parties and they will apply a strong presumption that a commercial arrangement is intended to be legally binding:

“Whether there is a binding contract between the parties and, if so, upon what terms depends upon what they have agreed. It depends not upon their subjective state of mind, but upon a consideration of what was communicated between them by words or conduct, and whether that leads objectively to a conclusion that they intended to create legal relations and had agreed upon all the terms which they regarded or the law requires as essential for the formation of legally binding relations.”²²

Applying this principle, the Supreme Court held that a statement that an agreement was ‘subject to contract’ did not prevent it from forming a contract when the subsequent conduct of the parties showed that they intended to treat the terms as binding. In particular, the fact that the operative terms of the agreement were actually carried out by the parties was a “very relevant factor”²³ pointing towards enforceability. The analogy between a ‘subject to contract’ statement and conduct carrying out the terms of the agreement and a ‘no intention to create legal relations’ statement and self-executing code that has or will carry out the agreement is a close one. It suggests that the courts, looking at the entirety of the relationship between the parties, could impose a legally binding contract on a Ricardian smart contract despite an express statement of lack of intention to create legal relations.

The analogy is not, however, an exact one. ‘Subject to contract’ implies that the parties consider that at some future point a contract may come into existence and the relevance of conduct is to determine whether that point has been reached. A straightforward denial of intention to create legal relations makes it harder to imply that intention from later conduct. In RTS Flexible Systems v Molkerei Alois Muller,²⁴ this was a policy decision for the Court: should the apparatus of legal enforceability be available to this particular agreement? Where a commercial arrangement had actually been carried out and the price paid, the Supreme Court was reluctant to deprive the parties of the benefit of this apparatus.

Other similar situations show that the courts tend to grant the parties the benefit of this legal apparatus in commercial situations. In its most recent consideration of this issue, Wells v Devani,²⁵ the Supreme Court enforced an agreement to pay an estate agent commission on his successful sale of a block of flats. The express terms of the written agreement were too vague to be enforceable because the trigger for payment of commission had not been specified. Acting with some innovation, the Court implied a term into the agreement to resolve this uncertainty and then applied the test of intention to create legal relations to the agreement including the implied term. There was also an explicit policy element: estate agent agreements were subject to statutory control and could be unenforceable without proper formalities: the Court further exercised its discretion to allow the agreement to be enforced.

Other policy-based examples can be provided. One is an express agreement by the parties to submit disputes to arbitration. This is an ouster only of enforcement by the Courts rather than enforcement generally, yet it is subject to statutory limitations. Agreements for arbitration for remedies below a fixed sum are deemed unfair by the Arbitration Act 1996.²⁶ Above this sum, an arbitration agreement may still be deemed unfair by the Unfair Terms in Consumer Contracts Regulations,²⁷ and now the Consumer Rights Act 2015. The unfairness lies in the consumer’s difficulty in obtaining effective and inexpensive enforcement of their agreement – a policy which would apply equally to smart contracts.

Finally, where parties have used contractual estoppel to restrict their contractual liability, the courts have used statutory powers to strike this down as an unreasonable exclusion clause. For instance, parties may agree between themselves that a particular state of affairs exists – such as that neither party has made any representations or relied on the other for advice – thereby removing potential liability for misrepresentation or negligent advice. The Court of Appeal has carefully differentiated the ability of parties to do this from the power of the courts to interfere on the basis of policy. It is open to the parties to agree on a state of affairs and to be bound by it, but this must be subject to statutory control which will be applied according to its policy, whatever legal formalities parties use to try and avoid it.²⁸

These are no more than broad analogies with the smart contract issues dealt with in this chapter. An intention to avoid all legal consequences is not the same as an intention to avoid the courts by recourse to arbitration; an intention to exclude liability in a contract is not the same as an intention to exclude all liability by preventing an agreement from being a contract. All the policy arguments exhibit a certain circularity: if there is a contract, statutory controls apply and show that a contract exists; if there is not a contract, then the agreement is outside the scope of these controls and cannot show that a contract exists. Nevertheless, it is clear from these examples that there are constraints on limiting judicial oversight, that those constraints are circumscribed by policy considerations, and that attempts artificially to stay outside their perimeter are often unsuccessful.

The conclusion on this point is that an express statement in the prose section of a Ricardian smart contract that it is not intended to create legal relations will not automatically prevent a legal contract from being recognised. Whether it will do so ultimately comes down to fundamental questions of contract law policy. Just as DLT and smart contracts challenge the existing financial order, they also pose significant challenges to the legal order. Contract law is a centrally available means of enforcing agreements between parties, without which commercial relations would be either more costly or simply ineffective. The smart contract ecosystem proposes an alternative – enforcement by external parties made redundant through automatic execution. Assumption of the benefits and restrictions of contract law as a whole is meant to be voluntary, as shown by the need for an intention to create legal relations, so why should parties not be able to ignore it completely? The answer may be that they can. But when there is an imbalance in negotiating powers or one party is acting fraudulently, or the arrangement is tainted by illegality, it is hard to see the Courts stepping back and pronouncing themselves powerless.

Before the creation of DLT and smart contracts, the issues in this section would have been purely theoretical. It would have been nonsensical to enter into a commercial transaction and simultaneously remove all hope of legal enforcement. Smart contracts offer an alternative: a commercial transaction that enforces itself. Whether the law still has a role to play is a question that courts will at some point have to address.

Interpretation

For current purposes, what is important is that the smart contract, as programmed, will be performed on the satisfaction of a given condition or set of conditions. This means that the space between the formation and the performance of smart contracts is vanishingly small. Given that most conventional contract claims are about performance, this represents a major difference in the adjudicative requirements of each type of contract. Smart contracts are less like exchanged promises than they are like promised exchanges. The expectations of smart contracting parties are more likely to be frustrated by the wrong thing happening rather than by nothing happening at all. For those smart agreements that are deemed to be enforceable, therefore, the next legal question that will arise most often is not whether performance can be enforced but whether the outcome that has already occurred is a just one. It is almost as if smart contracts need a back-to-front legal contractual analysis, in which enforcement yields to correction.

Smart contracts do not only make interpretation harder – they also call into question the very concept of interpretation, as it is currently understood. As discussed above, interpretation is the process of divining the meaning that the parties intended from the words that they used. Meaning is used here in a specific way. It does not refer to all and any objective meaning that may be taken from any passage of prose. Only the part of the meaning that creates legal rights and obligations is relevant and a large part of this meaning corresponds to the list of actions that the text imposes on each party. Specifically, the process of contractual interpretation determines the actions that each party will undertake. Legal rights and obligations are created that correspond to these actions. In other words, the parties are legally obliged to do what they promise they are going to do. As the Supreme Court put it, the task is to “ascertain the objective meaning of the language which the parties have used to express their agreement”.²⁹ It is the meaning of ‘their agreement’, what they have promised to do, which is the focus.

Contrast this with an agreement concluded by conduct: it can be as simple as the purchase of an item in a shop, an exchange of the item for cash. There is effectively no room for interpretation as to the key promises entered into by each party. The promise of the buyer is to hand over the amount of cash which he actually hands over; the promise of the seller is to hand over the item which she actually hands over. The contract attaches to the actions of the parties rather than to their words. The actions necessarily coincide with the obligations that they undertake.

Smart contracts created entirely in code behave more like conduct than words. The words of the code are, in themselves, actions. They are performative utterances, like the words ‘I do’ in a marriage ceremony. They actually have an effect on the real world, not through interpretation of their meaning, but directly. In the same way, code, when it is part of a distributed ledger, acts directly on the world through its execution without any medium of interpretation. To work out what a piece of code means, you do not read it, you run it. There is no room for doubt that the legal rights and obligations intended to be created correspond to the actions undertaken by the code; the code is no more than those actions set down in frozen form. The obligations coincide with the code in the same way that the obligations coincide with the conduct in a contract entered into by conduct. Interpretation appears in this context to be superfluous.

This chain of reasoning is part of the sentiment encapsulated in the slogan ‘the code is the contract’. Often heard in the smart contract community, this refers to a stance as much political as legal, in which all enforcement by the courts, not just the doctrine of interpretation, is rejected Rendered into a legal argument, it has some force when limited to the potential superfluity of interpretation but is unconvincing as an overall attempt to oust legal oversight. It ignores vitiating factors in agreements, such as fraud and illegality, and it ignores statutory and general policy controls on voluntary agreements. Even restricted to interpretation, it ignores the fact that most agreements will contain both code and prose. They may be expressed as Ricardian contracts or they may take effect within the context of an existing commercial relationship, with numerous other documents, emails and actions forming part of the factual-matrix within which to interpret the agreement. Additionally, a piece of code requires a platform on which to run. This platform includes software intrinsic to the particular blockchain, extending from interfaces seen by the user through to the plumbing that underlies the system. And it extends to other software that the platform interacts with, such as third-party information providers and cloud-based storage. It is impossible to model and to predict all of these interactions, not least because many depend on real-time constraints. Characterising code as freestanding, self-executing pieces of frozen conduct ignores these interactions and dependencies.

Despite these difficulties, ‘the code is the contract’ ethos illustrates how smart contracts can circumvent both interpretation and enforcement as forms of writing that act on the real world via DLT. It is a slogan that should serve as a warning to the legal community. Legal practitioners and courts will have to determine how, and whether, legal doctrines such as interpretation are relevant to smart contracts.

In those instances in which judicial interpretation does become relevant to smart contracts, (where, for instance, the code’s operation is said by one of the parties not to have done what it was intended to do), it will be one of the thorniest problems for the legal treatment of smart contracts.³⁰ It also has implications for parties’ freedom of contract. As established above, the content of the code will dictate what outcome the computer achieves. The content of the code, however, as with the written form of a conventional agreement, might not mirror the substance of the parties’ agreement. Whilst this is a common problem for conventional contracts, it is even more complicated where smart contracts are concerned. When an agreement is put into computer code, an extra layer of interpretative difficulty is introduced: the person coding the contract might not be one of the parties to it, and so might misunderstand the instructions. Even if she does understand them, she might make an error transposing them into code. This means that the code will not execute in accordance with the parties’ agreement, and this is where a court will need to decide how to resolve the dispute.

Conventional contracts produce fiendishly difficult interpretation problems because of the many ways in which human language can be used and understood. But these multiple possible meanings do not exist for artificial intelligence. As Susskind says, computers are ‘non-thinking, high-performing’ agents.³¹ From the perspective of the computer performing a smart contract, therefore, there is no room for interpretation, and the instructions presented to it have a single meaning. The potential meanings to both its authors and interested third parties, however, are several. The forensic process of interpretation in this sphere is therefore likely to be much more complicated than it is in the conventional context. The broad linguistic symmetry of conventional contracting, in which the authors of the agreement, along with any third parties, use the same basic lexicon,³² is absent in this context: computer code is qualitatively different to human language. A human reading of code, therefore, will be of limited assistance in determining the intended effect of language directed towards an artificial intelligence. Whilst human-to-human interaction is open to conflicting interpretations on both sides, human-tomachine interaction will only have multiple meanings to those choosing the language to be used, and not to the recipient of that language. Whilst a computer will do what it is told, however, this does not of course mean that it will do what the parties intended. And as Lewison LJ has made clear, the task of the court is ‘not … to ascertain ‘what the parties intended to agree’ but what the instrument means.’³³

Since there is no such thing as a reasonable computer, there is no point in approaching the interpretative exercise in relation to smart contracts by asking what a reasonable machine, or a reasonable user of human language would make of the language used. The task is made more difficult because, despite the growing numbers of individuals proficient in computer code, it remains the case that most people would not know what such code would mean to the machine for which it was intended. Outside of the specialist field, this is not (yet) a subject of general knowledge.³⁴

Technical interpretation problems are not in themselves a novel issue. The common law has, for instance, developed a means of dealing with contracts whose terms have an industry-specific contextual meaning, and with those written in a human language unfamiliar to the court: it simply admits expert translation evidence:

A judge is supposed to know the law, the English language and such facts as are common knowledge. If he refers to authorities or dictionaries or other works dealing with these matters he can safely do so because his general knowledge enables him to check and appreciate them. But if without assistance he attempts to handle highly technical matters he may easily go astray. Some fairly simple technical matters can nowadays be considered to be common knowledge, and I would not attempt to draw the line—it may alter from time to time. In this case some of the terms are simple enough but some are certainly not. So what is a court to do if on the face of a record there are technical terms which cannot be understood without expert assistance? There may be cases where a very little assistance is all that is necessary, and I think it would be unfortunate if such a strict rule were laid down that the mere presence of some technicality is enough to prevent a court from proceeding further in the absence of evidence to explain it.³⁵

The same approach cannot, however, be transposed for use in relation to interpreting smart contracts (or smart elements of prose contracts) because code does not use a lexicon that is necessarily common to both parties. Whilst certainly the machine itself, and any humans familiar with coding, will understand the language used,³⁶ those who agreed the substance of the contract may well not be able to follow it at all, were they ever even to see it.³⁷ Interpreting the code through reference simply by referring to a code lexicon, could easily fail to address the issue of what the contracting parties agreed to (particularly if neither party is herself familiar with code because, say, a third party code wrote the text). The code lexicon would be a guide only to the coder’s intention, but does not get to the root of the interpretative issue:

When the language used in an instrument gives rise to difficulties of construction, the process of interpretation does not require one to formulate some alternative form of words which approximates as closely as possible to that of the parties. It is to decide what a reasonable person would have understood the parties to have meant by using the language which they did.³⁸

This highlights the tension between English law’s objective approach to contractual interpretation³⁹ and its regard for the intentions of the contracting parties. The objective approach reduces the threat of uncertainty,⁴⁰ and provides a means of dealing with a court’s obvious inability to read individuals’ minds. The benefit of such an objective approach stems from its universality; it promotes certainty because it provides a means external to the parties of deciding what their words mean but, whilst being external, remains accessible to them so that they have the opportunity to gauge how their words will be interpreted. Again, however, this cannot simply be carried across to the smart contract sphere because of the linguistic asymmetry just described.

Coders, however, can bridge this gap with their ability to understand both human and machine language. Enlisting the services of such an expert in order to represent to the court what the machine in question had been required by the smart contract code to do is on one level little different to employing the services of a human language translator, as is standard practice where contracts are written in a foreign language.⁴¹ The difference as far as code is concerned lies in the court’s actions following that translation.

In principle, where a document has been translated, its proper interpretation is a matter for the court, and not a proper subject of expert evidence.⁴²

As explained above, however, understanding machine language is not simply a question of translating directly the terms used. The syntax and logical architecture of code is such that, without knowing the context of its initial design objectives, a literal translation of code into English is unlikely to be amenable to effective interpretation by anyone unfamiliar with the conceptual organisation of machine instructions. This presents yet another challenge to current forensic practice:

Although expert evidence may be necessary to explain technical terms to the court, it is not the function of an expert to interpret the contract. That remains the function of the judge.⁴³

But a judge unfamiliar with code might not find it easy to fulfill this particular function. To illustrate the different cognitive responses of humans and machines to language, take as a very basic example the following instructions:

‘Go to the shop and buy a newspaper. If there any eggs, get a dozen.’

The most likely human response to this instruction is to buy a newspaper and, in the event that the shop has eggs, to buy a dozen eggs as well. A computer, on the other hand, presented with this instruction,⁴⁴ would buy a newspaper and, in the event that eggs are also available, will buy 12 newspapers rather than one. In response to this instruction, it will not buy a dozen eggs because at no point has it been told to purchase eggs; the only object of the ‘buy’ mandate is a newspaper. Were a court to consider these instructions, and know that they have been issued to a human agent, there is certainly scope for considering more than one intended outcome⁴⁵ (either the purchase of one newspaper plus one dozen eggs or the purchase of a dozen newspapers) as being reasonable. Whilst the purchasing of a dozen newspapers by a human agent does not seem immediately reasonable to most adults with a standard social experience, there might be something in the context of the parties’ relationship, history or knowledge which renders it so on a particular set of facts.⁴⁶ The point is that there is a valid question to be asked about the meaning conveyed by these words to human intelligence, but the question of interpretation simply does not arise when considering a computer’s response.

Clearly, where computer code is concerned, therefore, it is not so much the meaning or use of individual words which is likely to give rise to interpretative difficulties,⁴⁷ but the way in which those words are combined to form instructions. In order to be forensically effective, therefore, expert code evidence would have to do more than explain the meaning of individual terms: it would have to go further by explaining what effect certain combinations and juxtapositions of words will have on the artificial intelligence to which they are addressed. The extent to which any court engaging in such an exercise is able successfully to align its interpretation of a smart contract with the agreement actually made by the parties will therefore determine the scope of those parties’ freedom of contract. Whilst this is true even of conventional interpretation exercises, the additional layer of potential misalignment in smart contracting is bound to present greater challenges to the objective of giving effect to parties’ intentions.

Concluding Remarks

The issues dealt with above do not exhaust the forensic difficulties posed by smart contracts. Even where a court has deemed a smart contract to be the proper subject of judicial intervention (because, for instance, the requirements for contract formation have been met and a court is persuaded that the parties had the requisite intention to create legal relations), there remains the significant question of what the remedial response to the dispute should be. The particular difficulty here is that the objective of Nick Szabo’s smart contract was to create “immutable unstoppable and irrefutable computer code” which can “self-enforce”.⁴⁸ This has interesting implications for the ability of the court to fashion an appropriate remedy, particularly in situations in which ongoing performance is a feature of the contract. Where the obligations under the contract are of the one-off, discrete variety,⁴⁹ and have produced an outcome with which at least one of the parties is disappointed, the situation can be remedied by the granting of a conventional remedy, external to the digital world, such as conventional compensatory damages or restitution.⁵⁰ Where, however, the agreement is one under which obligations are continuous, something needs to be done to the contract itself in order to ensure that future performance conforms to expectations. Where, for instance, a court determines that the coding of a smart contract does not match the parties’ manifest agreement, this looks like a job for rectification. Rectification is not, however, possible in any real sense because a smart contract, being immutable, cannot be rectified. A court-ordered variation of such an outcome⁵¹ will therefore require the creation of a new smart contract to reverse or modify the effect of the first.⁵² This looks more like novation than it does rectification, and perhaps points to a future in which the former remedy plays a greater role in resolving contractual disputes than it has done in the past. Historically, and for reasons which are obvious in relation to conventional contracts,⁵³ novation has been used primarily to substitute new for existing contracting parties. In the digital age, its remit may well expand so as to facilitate the modification of content currently dealt with by rectification.

These are big questions and require fuller analysis than is possible here. The fact that they need to be asked, however, lends weight to the argument advanced in this chapter that the ability of smart contracts to meet commercial expectations will depend on the extent to which the common law is prepared to adapt some of its long-established methods and responses to an age in which promises yield to performance.