Smart legal contracts: the emperor's new clothes or the elephant in the room?

To date, I've side-stepped smart legal contracts on this blog (though I did co-author a piece on our website back in 2017). Partly, this was because I could not decide whether, legally, they were a thing or not. I’ve been unsuccessfully bidding on online auctions since the early 2000s, but I’ve never thought of the automated process as involving any smart legal contracts. In my mind the legal relationship with the online auction house was set out in the plain-English terms and conditions that I’d accepted without reading. It was only, at most, parts of the bidding process that were automated according to limits I had set. The performance of the contract; not the contract itself. And, in any case, if there were anything new, the common law had proved to be remarkably good at adapting to technology. The Law Commission agrees that this type of smart legal contract does not give rise to legal difficulties. For even smarter smart legal contracts, the position is less straightforward. It’s not all about performance, but even so, in most cases the common law can cope.

Take B2C2 v Quoine, where the Singapore Court of Appeal faced a dispute about trading cryptocurrencies automatically on Quoine’s exchange platform. There were natural language terms and conditions governing the use of the platform. But to analyse how each of the individual trading contracts (which were entered into automatically via the operation of a series of algorithms) were formed the court referred to an English tax case: Software Solutions Partners. There, an insurance broker wanting to obtain a policy on behalf of its customers would input the customers’ details onto software which would provide policies matching those details from insurers with which SSP had an arrangement. The court in SSP drew an analogy from Lord Denning’s 1970s decision in Thornton v Shoe Lane Parking. He had said:

“The customer pays his money and gets a ticket….It can be translated into offer and acceptance in this way: the offer is made when the proprietor of the machine holds it out as being ready to receive the money. The acceptance takes place when the customer puts his money into the slot.”

Similarly, the court in SSP said the insurer was holding out the SSP software as the automatic medium for contract formation. Once the broker, like the customer in Thornton putting his money into the machine, had input the necessary data into the electronic process, no further human intervention was necessary for the formation of a binding contract between broker and insurer.

So too in Quoine the individual trading contracts were held to have been entered into pursuant to the parties’ respective deterministic algorithms (ie ones where the same input always results in the same output). The parties did not know beforehand whether any trade would be entered into or, if so, how much of a given cryptocurrency would be bought/sold and at what price. That did not prevent the formation of a contract at the point when an offer made by one program was accepted by the other.

These three cases are a neat example of how English contract law can keep up without legal reform. But, as the Law Commission’s report shows, there are certain areas where the law might need some help. 

With that in mind, I’ve picked out some of the interesting observations that the Law Commission made. The only actual problem areas are conflict of laws and deeds. Everything else works.

Conflict of laws

In most commercial agreements parties expressly choose how disputes are to be resolved and under what governing law. But is it correct to talk about expressing a choice of law or forum wholly in code since neither are things that make operational sense within a piece of code itself? What you can do is express the choice as a natural language comment within the code (good coding practice encourages natural language comments; but this is generally about the operation of the code not legal or other intentions). Or you could make an algorithmic determination: eg IF the IP addresses of all participants are assigned to the U.S., THEN the governing law shall be New York law ELSE the governing law shall be English law.

The difficulties around choosing a governing law and forum for disputes in entirely coded contracts bring the default rules that apply in the absence of any choice to the fora. These rules tend to focus on the identity and location of the parties and, in the case of contracts, the place of formation or performance of the contract. These are all things that are difficult to ascertain when dealing with smart legal contracts, especially if they are part of a distributed network.

For simple smart legal contracts, coders could consider choosing the UK Jurisdictional Taskforce’s Digital Dispute Resolution Rules (2021) in the comments, which brings with it a choice of English law. But are coders even aware of these rules or the significance of choosing them?

The Law Commission has suggested that reform will be necessary and has promised to make recommendations in due course. Ideally you’d have international cooperation to make this truly effective.

Formation

The Law Commission felt that although there were arguments that a smart legal contract could be made by way of deed there was not sufficient certainty to give parties confidence. Recommendations for reform will be included as part of the Law Commission’s proposed wider review of the requirements for the execution of deeds in due course.

The other areas of contract formation were workable:

• The cases of Quoine, SSP and Thornton show how offer, acceptance and agreement can operate.
• The English Court of Appeal in Golden Ocean held that a guarantee was “signed” by an email containing just the first name of the sender and which referred to, but did not contain, the guarantee. By similar reasoning, where parties sign a natural language document which refers to and explains the effect of the coded terms, the parties could be taken to have authenticated the coded terms. Equally a private key and digital signature could be used in a manner which shows the parties’ intention to authenticate a coded transaction.
• When it comes to things being in writing the Interpretation Act 1978 states that “‘Writing’ includes typing, printing, lithography, photography and other modes of representing or reproducing words in a visible form, and expressions referring to writing are construed accordingly.” This would generally extend to human readable source code. If the statutory requirement for something to be in writing was contained within a piece of consumer regulation, then it may well not. For binary object or machine code it is harder to see it as a mode of representing or reproducing words in a visible form.
• The Law Commission asked whether anyone expressly described interactions in code as having no intention to create legal relations. There was limited evidence of this according to the consultees. It does raise an interesting question. Do we want, or even need, smart contracts to be legally binding? Nik Yeo asked last month at an excellent event for the London Solicitors Litigation Association, “What if a vending machine had a notice on it saying, ‘The operator of this machine does not intend to enter into legal relations with any user.’?” Most people would probably still use it. If the machine didn’t work, they’d just ask someone in the building if they had a key or, failing that, they’d no doubt kick it! What they are unlikely to do is to sue the operator. Is it anarchistic to imagine that those trading in code do not want the comfort of legal remedies? As a risk adverse litigator, it might make me feel queasy, and much will depend on what is being traded, but I can see there may be a place for it.

Interpretation

Is code even susceptible to interpretation? By this I mean won’t the same piece of code always give rise to the same output (or at least a predictable output)? Well, if the code is deterministic (ie same input same output) then it should. But this may not reflect the parties’ intentions. As an example of courts not going for the pure computer-says-no approach to interpretation, the Law Commission referred to the tax case of HMRC v Tooth where HMRC argued that a self-assessment form entailed “deliberate inaccuracy” since the explanation for the treatment of an employment-related loss was wrongly inserted into a box on the electronic form reserved for partnership matters. The UK Supreme Court rejected the argument that interpretation of the tax return should ignore the comments box simply because the form was machine read in the first instance. A tax return is not a contract, but the analogy is clear enough.

The Law Commission proposes that a court should ask what the term in question would mean to a reasonable person with knowledge and understanding of the code – the “reasonable coder”. So, if the instruction was, “Go to the shop and buy a newspaper and if there are any eggs, get a dozen.” the reasonable coder might explain that the code contained an instruction to buy 12 newspapers if the shop sells eggs.

The interpretation of code could be helped by comments in the code operating rather like recitals or by reference to official user guides which the English court has long since said may form part of the factual matrix.

“Human” aspects to causes of action

This heading was not used by the Law Commission (though they covered the issues) but is inspired by how Nik Yeo suggested classifying the topic at the talk I mentioned. An example is the knowledge element to unilateral mistake. In Quoine the court had to decide what should happen when a deterministic computer program traded at 250 times the value of a cryptocurrency because of a built-in function designed to deal with a thin market. This transpired virtually because a change to passwords meant the computer could not access the markets. The majority of the Singapore Court of Appeal held that you should frame the question accordingly: “when programming the algorithm, was the programmer doing so with actual or constructive knowledge of the fact that the relevant offer would only ever be accepted by a party operating under a mistake and was the programmer acting to take advantage of such a mistake?” On the facts this was not made out. Lord Mance, the only judge to dissent, proposed tweaking the rules of equitable mistake (which are part of Singaporean but not English law) saying that the requirement of knowledge would be satisfied by evidence that the parties actually knew that there had been a fundamental mistake as soon as the computerised transaction came to their attention; even if that knowledge only arises afterwards.

Clothed elephant or naked emperor?

There are then tricky areas; but, I suggest not as many as some would have you believe and, so far, the incremental evolution of the common law has kept pace. However just because the law can provide answer doesn’t mean it will be the answer you want. Why would you not at least have hybrid arrangement with natural language provisions for complex high-value transactions? Anyone should, in theory, be able to read a contract in their native language. Would the parties in Quoine have entered into a natural language contract spelling out the consequences of there being a thin market? Maybe. At least it would have been a fully in formed decision. For the moment I'm not convinced we will see mainstream complex smart legal contracts that are wholly in code, and I anticipate that their deployment is likely to be confined to relatively simple legal transactions like buy/sell trades (albeit subject to complex pre-conditions).