Smart contracts: can code ever be law?

We live in an age of disruption – and the legal industry is not immune. “Smart contracts” have been receiving particular attention, with their potential to bring about both efficiencies and legal issues.

So what are smart contracts and what can they achieve? In this article we take a closer look at these questions, propose some answers, and raise some new issues for consideration. 

There is a rumour that smart contracts will revolutionise the legal industry and put lawyers out of jobs. Is that true?

Perhaps – one day. Smart contracts will undoubtedly disrupt the legal industry – which is as ripe for disruption as any other industry. 

OK. So what is a smart contract?

The original – and perhaps most famous – definition is from Nick Szabo, a computer scientist known for his research on digital currency, in 1995:

A set of promises specified in digital form, including protocols which the parties perform on those promises.

A useful – and more comprehensive – definition is from RSK, a smart contract platform:

Smart contracts are contracts whose terms are encoded in computer language instead of legal language.  Smart contracts can be executed… so that the terms of the contracts are automatically enforced by a protocol that all nodes in the network follow.  A smart contract can be fully autonomous if all the objects referred (such as currency, payments,  obligations, property titles, assets, licenses) have a digital representation in the platform.

Automated performance is at the heart of a smart contract. In practice, it is a computer program, containing certain inputs and executing a set of instructions in order to come to one of many predetermined outcomes. The following elements are present:

• Guaranteed implementation and outcome from certain inputs.
• In a computer code and digitalised format.
• Irrevocable manner of execution and storage. 

The potential of smart contracts encoding and automatically performing complex agreements, assisting with identity verification and reducing cumbersome documentation is an exciting prospect for many industries – especially when they are executed on a blockchain, to combine performance with an immutable record of that performance.  

At present, much of the focus around smart contracts is in relation to financial instruments such as shares, bonds or derivatives contracts – and how they will help automate and simplify systems relating to the trading of such financial instruments. For example:

• The Corda platform (designed by R3 – a consortium of various financial institutions) is designed to record, manage and synchronise legal agreements between only the proper parties to those agreements.
• ISDA has taken significant steps in automating its standard form contracts in the derivatives market, and developing a governance framework around those automated contracts. 

Other potential areas for smart contracts deployment include: 

• supply chain management, and in particular, combining blockchain, smart contracts and identification technology (e.g. RFID) to ensure that inputs are tracked throughout the entire supply chain – including in relation to authentication and payments; 
• real estate transactions and land registration;
• payment of insurance claims, and automation of certain policies (e.g. life insurance); 
• transfer of assets under certain specified circumstances;
• provision of licences;
• management of intellectual property rights; and
• automatic ordering of goods and services, including in a machine-to-machine context. 

All very exciting. What progress has been made in the smart contracts ecosystem? 

We are still in the early stages of developing wholly independent smart contracts without any natural language. 

We see smart contracts evolving in four distinct stages:

1. A natural language contract, with words on pages, in a format we all know and love, but with certain functions encoded in digital form. Areas that are clearly delineated into black and white functions (such as payments) are areas that lend themselves to automation. 
2. A natural language contract, with other functions encoded in digital form, not just “black and white” functions – e.g. performance of certain subject matter obligations under the contract (beyond payments). This would be a natural and incremental progression from stage 1. 
3. A contract in code supplemented by natural language – e.g. a natural language systems procurement contract may have certain schedules sitting under it that are entirely automated (such as Service Levels and Service Credits-related schedules).
4. A contract entirely in code that dispenses with the natural language contract. This contract would be a piece of code that is legally recognised and enforceable, on a standalone basis. 

Currently, smart contracts mostly sit between steps 1 and 2. We are a long way away from pieces of code sitting entirely independently as a contract, without any reference to a natural language document. 

At present, smart contracts carry out what they are programmed to do. They do not think independently or provide any reasoned analysis, and do not address “grey areas” or contain the flexibility that parties will frequently expect from certain kinds of contracts. 

For example – in a typical procurement agreement, the supplier may offer the customer the benefit of an indemnity for defective products. That is a difficult clause to encode: the indemnity would operate when a certain event happens, but the scope of the indemnity (and the amount that is payable) will likely be subject to the individual facts in question, and may also be subject to court interpretation. 

In addition, smart contracts are only as good as the data input that they receive. If the data input is inaccurate at any stage, this could have a cascading effect as the smart contract progresses. This is particularly important when the use case involves a substantial smart contract ecosystem, with multiple input stages and stakeholders – such as a logistics supply chain that involves different commercial organisations and governmental entities (e.g. customs authorities). 

Legal systems in different jurisdictions have a long history of statutes and case law, that combine to give certainty to parties in different areas. At the same time, there is also recognition that some flexibility is required in interpretation – both by courts and contracting parties. That flexibility is a key feature of ensuring that commercial agreements operate as intended, and is (at present) not something that is offered by smart contracts, which by their nature are “black and white”. While computer coding tends to be unambiguous, traditional legal contracts are frequently drafted with some “flex room” built in. Expressions such as “reasonable efforts” and “material adverse change” have a long history of legal interpretation behind them, and in many cases helps parties resolve issues by not determining in advance exactly what the obligation involves. A trade-off here may be appropriate for some situations, but not for many others. 

What is stopping smart contracts from operating entirely independently and in an automated manner, without human intervention?

A number of factors, which may or may not be resolved in the near future. 

Let’s look at one of the most basic questions facing any contract: enforceability. A contract can be defined as:

An agreement between two or more parties, characterised by mutual promises or obligations, which is enforceable and given legal effect by the surrounding framework of laws in which the contract sits.

In common law jurisdictions, a binding contract requires the following elements:

• offer and acceptance;
• consideration – i.e. reciprocity/exchange of value between the parties;
• intention to create legal relations; and
• the agreement is either complete (i.e. not lacking any essential terms) or certain (i.e. terms are not vague or ambiguous). 

Let’s have a look at the smart contract example below:

Assuming that we are dealing with a jurisdiction that acknowledges the enforceability of contracts formed electronically, we can consider whether the above smart contract leads to an enforceable agreement. 

• Consideration – at step 6, there is an obligation for payment of an amount, and in turn the Supplier has certain performance obligations. It is likely that there is an exchange of value between the parties.
• Offer and acceptance – steps 2, 4 and 5 deal with the process of how an invitation to treat, an offer to sell, and a communication of acceptance is made. Overall, it is likely that there is an offer and acceptance between the parties. 
• Intention to create legal relations – if the entire process is automated with no human action, and a party is not aware of the transactions going through a system, are they then bound by the relevant transaction? The Customer’s invitation to treat was “automatically created and sent” to the Supplier; and steps 3 and 4 by the Supplier could be automated as well – given the system scans for stock levels and confirms that the Customer is a previous customer and within the predetermined parameters for entering into a contract. 

However, if the computer logic has already been encoded and both parties have transparency as to what rules have been put in place – at that point, they can be bound by the transactions taking place subsequent to that logic. Common law courts have been willing to apply similar logic in relation to contractual disputes over time – particularly where both parties have had a chance to review the terms. How this will apply to smart contracts will depend on whether the parties have had a chance to diligence the smart contract in detail.

• Having said that, smart contracts that purely digitise a process, but which is not accompanied by the relevant legal terms, may not satisfy the requirement of a legally binding contract. Similarly, a “follow on” contract that is brought about by the performance of an earlier contract may not be legally enforceable, where the above-mentioned requirement of intention (i.e. both parties knowing and agreeing that a contract will be created if certain parameters are met) is not met.  

This will be a potential problem in the Internet of Things sphere, where machine-to-machine commerce may create direct contracts without any human intervention (e.g. an oven that orders its own baking foil, or a fridge that orders new milk). Certainty will be a factual question, on a case-by-case basis. We believe that smart contracts can be certain, particularly where the parties have had a reasonable chance to diligence the smart contracts in play. 

So a smart contract can be enforceable – but what if we need to amend it, or what if smart contracts go wrong? 

Good question! This is a tricky real-world implementation problem that many smart contracts systems encounter. 

Fundamentally, many regard smart contracts as irrevocable: once the smart contract’s criteria are met and performance has commenced, the subsequent performance of the encoded outcomes in a smart contract cannot typically be stopped (particularly where the process is being driven by blockchain technologies). This is commonly known as the “inexorability” problem.

Irrevocability becomes a problem when the smart contract does not behave in the way that the contractual parties intended, or does not reflect the agreement between the parties. There have been many examples of this. A notable example arose in June 2016 – when The DAO’s (a digital decentralised autonomous organisation and an investor-directed VC fund) smart contract for decentralised crowdsourced investing, leaked more than half of its value within two days through a mix of its computer code being exploited and the market price of Ether (the cryptocurrency that it holds to invest) falling in value as a result of market panic. As explained by Gideon Greenspan, founder and CEO of Coin Sciences:

Ironically, the individual or group which drained The DAO did so by exploiting subtle errors in this withdrawal mechanism. Like all smart contracts in Ethereum, The DAO is just a piece of computer code, which is “immutably” (i.e. permanently and irreversibly) embedded in the blockchain and executed by every node in response to incoming transactions. And like any self-respecting smart contract, The DAO provides full transparency by making its source code easily accessible online. This means that anybody can independently verify its functionality but also, crucially, look for vulnerabilities. And yet, the immutable nature of blockchains prevents any such problems from being fixed.

The DAO had been a strong advocate of “code is law” – i.e. whatever the code says, is the intended and agreed outcome, and nothing except the code can change the rules governing the transaction’s execution. That was precisely what happened in the above event – the smart contract was executed in accordance with its terms – but the consequences of this that was clearly not intended by any of the contractual parties involved. Given the smart contract was executed as it was coded, could the above be considered a “hack” or criminal activity – since The DAO and its participants had agreed that “code is law”, so in effect this is all part of the performance of the contract in question? 

In the above event, Ethereum (the smart contracts platform on which The DAO’s smart contract was built) created a hard fork that returned all the Ether (the digital currency used by investors) taken from the DAO to a refund smart contract, after a majority of Ether holders voted for his proposal. This created significant controversy in the Ethereum community, with some continuing to argue for a hard “code is law” stance. 

The wider point is this – smart contracts can and do go wrong, and we need to find ways to reflect the parties’ agreement when that happens – after all, writing large amounts of flawless code is extremely difficult at the best of times, and that is without considering “bad actors” in the ecosystem. 

Besides ensuring that smart contracts are coded and verified appropriately at the beginning – one specific way of addressing this risk is to ensure that contractual parties agree a process for how a smart contract can be overridden by a “new version” of that smart contract, and then implementing that in code. For example – a replacement smart contract could sit alongside the original smart contract, with additional code to ensure that any input into the original smart contract would automatically flow through to the replacement smart contract.

While the “code is law” ideal is held by many smart contract advocates, we are nowhere near that ideal at present and it is unclear whether it will ever be practical. Governance processes have to be implemented to ensure that this risk is addressed. In line with the above paragraph – third party vendors have started offering solutions and platforms that offer these governance processes or a defined dispute resolution process for smart contracts. It remains to be seen how well they operate in practice over time.

How does a smart contract interrelate with real world data?

One of the most challenging areas for the development and evolution of smart contracts is, when a smart contract references a real life event as a potential milestone for activation – how does a smart contract know whether such events have happened? This is known as an “oracle” problem.

Matt Levine of Bloomberg sums up this issue succinctly: 

“My immutable unforgeable cryptographically secure blockchain record proving that I have 10,000 pounds of aluminium in a warehouse is not much use to a bank if I then smuggle the aluminium out of the warehouse through the back door.”

The extent of this challenge depends on the nature of the real life event or information that the commercial contract requires.  For example:

• If a smart contract is reliant on a currency conversion rate at a particular time – it is likely that the smart contract can reference an agreed online source of that information.
• By contrast – if a smart contract is dependent on a single source of information, then its ability to operate will depend on whether that source is available as an input into the smart contract. For example, in a logistics environment, whether payment is executed for the delivery of a product would depend on whether that product was delivered. If there is only one source for determining whether that has occurred, the smart contract’s operation would then depend on that source of information being able to be “fed into” the smart contract. This would be particularly difficult in certain contexts, such as jurisdictions where the information is only available through a governmental authority, but that authority has not yet made such information available to the public or electronically.
• There are also more “legalistic” issues. For example, where a force majeure event will lead to a termination of the smart contract – how will the smart contract know whether the event has occurred, particularly given that (similar to our earlier point regarding an indemnity) force majeure event definitions are frequently wide in scope and vague?

While it may be possible to break down some of these challenges into more binary oracle tests, it will be a challenge for smart contracts to address more difficult subjective determination events in order to reach automation, when smart contracts (and, more generally, computer coding) are frequently dependent on a black and white determination (rather than an interpretation of an event that does not entirely fit in within the provision’s scope). 

How would a smart contract ecosystem work?

An interesting part of any private smart contract system is how it can address relationships and governance between the parties. 

The following could represent a potential setup between the various stakeholders in question:

You will note that there are various agreements, stakeholders and governance mechanisms in play.  In particular:

• JV/Consortium Agreement – this is needed between the founding members, to establish the entity or structure that will manage the smart contract platform. 
• Participating Agreement – every participant of the smart contract system will be required to sign onto this. This will include Operating Rules and Platform Agreement in relation to the use of the smart contract platform.
• Operating Rules and Platform Agreement – users of the platform will need to be “on-boarded” by agreeing to the appropriate terms.
• Governance board – similar to a board of directors, this will be required to govern the platform in relation to key decisions.