This page uses so called "cookies" to improve its service (i.e. "tracking"). Learn more and opt out of tracking
I agree

Smart legal contracts Advice to Government - Presented to Parliament by the Lord Chancellor and Secretary of State for Justice by Command of Her Majesty, November 2021

Title
Smart legal contracts Advice to Government - Presented to Parliament by the Lord Chancellor and Secretary of State for Justice by Command of Her Majesty, November 2021
Additional Information
Permission Text
© Crown copyright 2021
This publication is licensed under the terms of the Open Government Licence v3.0 except
where otherwise stated. To view this licence, visit nationalarchives.gov.uk/doc/open-
government-licence/version/3
Table of Contents
Content

Smart legal contracts Advice to Government

Presented to Parliament by the Lord Chancellor and Secretary of State for Justice by Command of Her Majesty



[...]
84

 

Conclusion on the appropriate test for interpreting coded terms

4.48 In our view, interpretation of a coded term should be determined by asking what the term would mean to a reasonable person with knowledge and understanding of code
85
– that is, a “reasonable coder”. The answer to this question will be determined by reference to what the code, in that person’s reasoned opinion, appeared to instruct the computer to do.279 In our view, this is the most appropriate way to ascertain the “meaning” of the coded terms of a smart legal contract.
4.49 In the call for evidence, we framed the test as knowledge and understanding of “the relevant code”. By “relevant code” or “knowledge of code” we mean knowledge of the relevant programming language in question. The interpretative enquiry is then what the specific code in question means to a reasonable person with knowledge of that particular programming language (that is, to a “reasonable coder”).
4.50 The “reasonable coder” test is premised on the fact that where code is a source of contractual rights and obligations, those rights and obligations accrue in the human-readable source code, rather than in machine code or a lower level of code that cannot be read by a human person. Where, however, the contractual terms accrue in the machine code or in a lower level of code that cannot be read by a human person, the reasonable coder test is unlikely to be suitable to ascertain the “meaning” of those terms. Since such code is unintelligible even to an expert coder, its “meaning” will
have to be discovered by running it. In other words, the code simply “means” what it does when it is executed.
4.51 Whether the terms of a smart legal contract are defined by the source code, or by a lower level of code that cannot be read by a human person, raises an issue of interpretation. In most cases, we anticipate that where code is a source of contractual terms, those terms will be defined by the source code.280 As the Digital Law Association said, where terms of a smart legal contract are defined by code, “it would almost certainly be the case that parties agree to the terms as they exist at the level of the source code”. Even though we strongly agree with this, parties may wish to consider specifying that their terms reside in the source code to remove any potential uncertainty.

Benefits of the “reasonable coder” test


4.52 The “reasonable coder” test has the benefit of providing an insight into what the parties intended the code to do, regardless of the computer’s ultimate performance. In focussing on the objective appearance of what the parties agreed to, such a test is more consistent with the existing approach to contractual interpretation than one that asks what the code meant to a functioning computer. The nature of computer code is such that its meaning to the machine to which it is addressed can be at odds with what the human authors of it believed it to mean. Observing the performance of the code, rather than asking what it was intended to do, is therefore of little relevance to the forensic question of what the parties actually agreed to.
86
4.53 We acknowledge that adopting a “reasonable coder” test entails a nuanced development of the existing principles of contractual interpretation. For the reasons given above, however, we think that such a development is necessary and justified in order to take account of the unique nature of contracts written in coded terms. Using professional knowledge and judgement as a benchmark for assessing human action is, in any event, not a practice unfamiliar to the law in this jurisdiction. In interpreting conventional contracts, courts are familiar with obtaining expert evidence in order to gain an understanding of technical terms.281
4.54 Ultimately, the exercise is still one of contractual construction. The ordinary rules of interpretation will suffice apart from the suggested incremental development to the test for interpreting coded terms – that is, asking what the coded terms mean to a reasonable coder. In addition, adopting a reasonable coder test does not mean that expert coders are required to provide an opinion on a matter of law; this ultimately remains within the exclusive purview of the courts.

Importance of context in the interpretative exercise


4.55 Interpretation is not determined in the abstract by reference to a set of semantic and syntactic rules. It is a more concrete enquiry, which looks not only at the literal meaning of words, but also at the context in which the speaker used those words. Since a computer will run code as instructed, limiting interpretation of code simply to observing the performance of that code would not give the court the opportunity to consider the context in which a coder used it. As DLA Piper UK put it, asking what a coded term “means” to a functioning computer would be to “discount context from the interpretation of coded terms”, which would “not be appropriate”. In contrast, interpreting coded terms according to what a reasonable person with knowledge and understanding of code would understand the terms to mean enables the court to consider the broader context.
4.56 A recent Supreme Court case, Commissioners for Her Majesty’s Revenue and Customs v Tooth (“Tooth”),282 confirmed the importance of context in the interpretative exercise, even where the document in question was to be read by a computer. This case concerned the interpretation of a tax return submitted by a taxpayer, Mr Tooth to Her Majesty’s Revenue and Customs (“HMRC”). An issue in the case was whether Mr Tooth’s tax return contained an “inaccuracy”. Mr Tooth had incorrectly entered an employment loss as partnership loss in one of the boxes on the tax return form.283 However, Mr Tooth explained this entry in a “white space” disclosure box included in the form to allow for written explanations.284 Tax returns are read by HMRC’s computers in the first instance.285 Importantly, the computer could read the entries in the form, but not the information provided by the tax payer in the white space disclosure box. HMRC argued that, because Mr Tooth’s tax return was read by a computer, it should be interpreted on an entry by entry basis, without regard to the
87
information provided in the white space disclosure box. It followed that Mr Tooth’s tax return contained an inaccuracy. In contrast, Mr Tooth argued that each entry should be interpreted in the context of the tax return as a whole, including the white space disclosure box. On this approach, the tax return did not contain an inaccuracy.
4.57 The Court strongly rejected HMRC’s argument.286 It held that “it almost goes without saying” that the meaning of words is to be determined by a “contextual approach, that is, by appraising the critical passage in the light of its context as part of the document read as a whole”.287 HMRC’s core argument was that, since the tax return was read by a computer (at least initially) contextual interpretation was not appropriate.288 The Court said this was “a very unattractive argument”.289 It went on to say that: A document written in the English language (or any language other than computer language) does not have a different meaning depending upon whether it is read by a human being or by a computer. A choice by the recipient of such a document to have it machine-read cannot alter its meaning.290
4.58 This decision demonstrates that interpretation of a natural language document is always a contextual exercise, where the court looks at the words in the context of the document as a whole, and in light of the factual background. Importantly, though, Tooth is confined on its facts to natural language documents read by computers. The Court expressly carves out from its decision documents which are written in “computer language”. The result of this carve out is that a document written in “computer language” (that is, in code) may “have a different meaning depending upon whether it is read by a human being or by a computer”.291
4.59 We agree with this statement by the Court. If code is “read” by a computer, the meaning of the code could simply be what it does when it is executed. If code is read by a human being, the meaning of the code could be what a reasonable coder says the code appeared to instruct the computer to do. These two “meanings” may not always coincide. However, what we are concerned with is which meaning of code should be adopted. The argument put forward in this chapter is that the meaning of code should be what a reasonable coder says the code appeared to instruct the computer to do. That is, the meaning one comes to if the code is read by a human being. This approach has the benefit of providing an insight into what the parties intended the code to do, regardless of the computer’s ultimate performance. By focussing on the objective appearance of what the parties agreed to, such a test is
more consistent with the existing approach to contractual interpretation, the importance of which has recently been confirmed by the Supreme Court.
88

An example of how the “reasonable coder” test could be applied in practice


4.60 Suppose Alice and Bob conclude a solely code smart legal contract that is programmed to transfer 10 Ether from Bob to Alice every week until 1 January 2022. However, due to an unforeseen upgrade to the programming language,292 the code transfers only five Ether to Alice in week three. The contract does not make any provision for the consequences of upgrades. Alice argues that Bob was unconditionally obliged to transfer 10 Ether to her each week until 1 January 2022. Bob disagrees; he says that he was only obliged to transfer 10 Ether to Alice each week in the event that the platform was operating normally, or that he was only required to transfer what the program actually transferred. In this case, a dispute could arise as to the scope of Bob’s obligation, and the “meaning” of the coded terms. Alice argues that performance of the code did not accord with what the coded terms “meant” on their proper interpretation (which, according to her, was for Bob to unconditionally transfer 10 Ether) and, that performance of those terms amounts to a breach of contract by Bob. In the event of such a dispute, a reasonable coder would be asked which of these interpretations can be drawn from the content of the code.
4.61 Adopting this method of interpretation will illustrate any divergence between what the code appeared to instruct the computer to do (what we submit is its “meaning”), and what it did in fact do. It facilitates an argument that performance of the code was not in accordance with what the coded terms “meant” on their proper interpretation. In contrast, adopting a method of interpretation based on what the coded terms “mean” to a functioning computer would leave no scope for Alice to argue that performance of the coded terms was not in accordance with what those terms “meant”; the code would mean whatever the code performed.
[...]

279See T Schrepel, European Commission, Smart Contracts and the Digital Single Market Through the Lens of a "Law + Technology" Approach (September 2021) p 36 for a similar view, and where the point is made that in interpreting a smart legal contract, the court will likely call upon experts to translate the smart legal contract into natural language. Reference is also made to artificial intelligence (“AI”) systems assisting with interpreting smart legal contracts. Such AI systems could “supplement the experts capable of translating the code of smart contracts into natural language”.
280This approach is supported by the UKJT Legal Statement at [145].
281See, for example, Baldwin & Francis Ltd v Patents Appeal Tribunal [1959] AC 663, 684, by Lord Reid.
282[2021] UKSC 17, [2021] 1 WLR 2811 (“HMRC v Tooth”).
283HMRC v Tooth at [3].
284HMRC v Tooth at [9].
285HMRC v Tooth at [35].
286HMRC v Tooth at [49] to [52] by Lord Briggs and Lord Sales.
287HMRC v Tooth at [49] by Lord Briggs and Lord Sales.
288HMRC v Tooth at [49].
289HMRC v Tooth at [50] by Lord Briggs and Lord Sales.
290HMRC v Tooth at [50] by Lord Briggs and Lord Sales.
291HMRC v Tooth at [50] by Lord Briggs and Lord Sales.
292Transpact said that an upgrade to a programming language may unintentionally cause the same computer program to run differently.

Referring Principles
A project of CENTRAL, University of Cologne.