Should I be thinking about Smart Contracts?

There was a time when contracts were written with a quill and ink on parchment paper.  Then came the typewriter, then the word processor and by the time we emerge into 2022 we are executing documents virtually and electronically.  We’ve come a long way.

Are we now on the verge of a quantum leap in how we contract and manage those contracts?  Well, possibly.

Some commentators are hailing ‘smart contracts’ as the coming revolution. 

The Law Commission produced an impressively detailed report and advice to the Government in late 2021 looking at some of the key issues.   So, let’s take a quick canter through some of the points raised and see what conclusions we can draw.

What is a ‘smart contract’?

Technically here we are talking about smart legal contracts, but for the sake of brevity I’ll just use the term “smart contracts” in this article.

A smart contract is a legally binding contract in which some or all of the obligations are defined in and/or performed automatically by computer code. As they are drafted in code, they necessarily follow logic and work with specific inputs and outputs, such as “if X occurs, then execute step Y”.

There is a wide potential range of smart contracts, from a natural language contract with one or two elements of performance automated by code to a contract written entirely in and performed by code, with a whole range of hybrids in between.

As it will feature in a number of the points below, it is also worth explaining what an “oracle” is.  An oracle is an external source of information (for example, a database that stores interest rate information) that can be automatically fed into a smart contract to determine whether or not a contract obligation has been triggered or breached.  More on this later.

Do they already exist?

They do!

At present they are typically used to perform fairly rudimentary tasks.  For example, we will all be familiar with contracts whereby payment is taken by automatic direct debit – this is itself a basic application of the smart contract premise.

As part of its investigation the Law Commission asked the market for examples of existing smart contracts, and perhaps the two best examples given were as follows:

1. Monitoring of service level agreements – where a contract has an agreed set of performance levels and a defined service credit mechanism, a smart contract can use an oracle (in this case a service monitoring tool) to collect data and, where a performance level has been breached, automatically assign a service credit to the customer, all without human intervention.

2. Parametric insurance policies – the Law Commission report uses the example of a solar energy contract where the insurer promises to pay a specific sum to a policy holder upon occurrence of a specific event (without demonstration of loss). In this case the insurers automatically pay out where the levels of energy generation are sub-optimal due to bad weather, in this case pulling information from a third party “oracle” collecting weather data.

What are the benefits of smart contracts?

So, we now know what they are and that they already exist.  But what benefits can they bestow?

The biggest sell (and the one that has got most people excited) is the efficiency argument.  Given the automation, smart contracts should be able to reduce human error, reduce the amount of time required to manage a contract and, importantly, to increase the speed and accuracy of contract performance.  This is indeed the contractual Shangri La!

Second, theoretically the use of smart contracts should reduce the need for, and the cost of, enforcement and remedial actions.  If (and we will come back to “if”) a smart contract is properly coded it is simply unable to refuse to act or fail to perform as long as the pre-programmed contractual conditions for the action or performance are met.  This will be music to the ears of customers (and suppliers) around the world.

But is it all good news?

In short, no.

Not logical? - perhaps the biggest pitfall from our present viewpoint is an issue of logic.  Smart contracts are wonderful when there is a simple “if X happens, do Y”, but where obligations are not based on conditional logic they are difficult (impossible?) to translate into code.  Consider the contractual obligation that requires the exercise of reasonableness or discretion of one of the contract parties – how can this be automated?

Code breaking - the next biggest issue is around confidence in the code used to “draft” smart contracts.  What if the code fails?  According to experts, the same computer code does not always produce identical results. Whilst not common, computer code can run in a different way, producing different results, when run on a different computer, or indeed on the same computer but at a different time.  This is anathema to the concept of contract certainty.

The problem with oracles - we discussed above the benefit of using oracles.  However, how do you ensure the data received from oracles (especially third party oracles) is accurate and up to date?  What if it isn’t – whose responsibility is that? 

Lost in translation - what is the translation process from natural language to code and when in the negotiations it is done?  Which ultimately takes precedence?  Who checks it – third party code verifier/auditor?

Precedence concerns - if some contract terms are in natural language and some in code, what is the precedence in the event of a dispute?  Will that depend on the type of clause being disputed?

In writing? – one of the issues the Law Commission report looks at in some detail is whether computer code would satisfy the definition of “in writing” as set out in the Interpretation Act 1978 which defines it as including “typing, printing, lithography, photography and other modes of representing or reproducing words in a visible form”.  There is certainly some room for argument here.

The issue of interpretation – is computer code subject to the usual rules around interpretation of clauses?  Who is qualified to interpret it? Is there room for the concept of a “reasonable computer programmer”? Are their differences between a human interpretation (understanding the nuances of a situation) and a computer interpretation (that it is to say, a very literal interpretation).  Is there room in the future for a new breed of coding lawyers?  If not, there is certainly going to be a need for close collaboration between coders and lawyers.

Can we reach any conclusions?

It really is early days still (with the spectre of fully coded contracts some way in the future), so there is a big element here of eager anticipation as to how this will unfurl.

From a lawyer’s standpoint, perhaps the biggest issue is that many contracts (consider a typical 200-300 page outsourcing contract sprinkled with “reasonable endeavours”) will be too complex or contain too much subtlety to be helpfully translated into code.

That said, the march towards automation will undoubtedly continue at pace and more and more smart contracts are going to find their way onto the page (or should that be screen?) notwithstanding.

The Law Commission report concluded firmly that our current legal framework is able to flex with the proliferation of smart contracts and, as such, it has discouraged the creation of a new legal and regulatory regime.  Instead, it preferred the use of the current common law system to develop the law in this area as and when needed.  To my mind that seems like a sensible conclusion.

For now, its watch this space!