Smart contracts: can code ever be law?

June 3, 2018

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.
These agreements and mechanism will need to address a number of areas, including:
  • Allocation of liability, risk and responsibility for errors. This includes reference to any third party vendors that are responsible for building and maintaining the relevant platform, in addition to the stakeholders and participants. 
  • Public and private access to data in the system.
  • Data privacy and cybersecurity – particularly with cross-border systems and transactions, and including requirements in relation to:

– cross border transfer;

– data localisation requirements;
– data anonymisation/pseudonymisation;
– “right to be forgotten” and how that relates to the (usually) “immutable” nature of blockchain data; and
– cybersecurity and insurance requirements 
– e.g. how the different agreements/systems are to be secured and insured. 

Applicability of above issues would depend on the blockchain solution’s design, include where nodes are located, data access permission/restrictions on nodes, and whether data is stored “off chain”. 

Consideration of these issues would therefore need to be implemented from an early stage, in a “privacy-by-design” manner.

  • Payments – e.g. how/when payments will be made. 
  • Governing law and dispute resolution mechanisms, including when smart contracts are “not so smart” (see above discussion of The DAO). Will code errors be reversible? What is the extent of human intervention? 
  • Interaction with regulatory requirements. 
  • Disclosure and auditability of the underlying coding and ongoing transactions. 
  • Licensing terms of the smart contract platform. Many smart contract platform/code at present have a mix of open source licences contained within them. This is not a settled area – for example, Ethereum’s position is not entirely clear:

“… the Ethereum software collection is distributed under several licenses, partly to reflect the different thinking of the minds behind different pieces of software and partly to reflect the need to adapt to real-world issues and opportunities and lay out a strategy to provide the best possible future for the Ethereum community.”

We have talked about a lot of theoretical and sample applications of smart contracts. How about some real world examples?

As mentioned above, smart contracts are closely related to blockchain. A simple diagram of how a blockchain works is below*

There are a number of blockchain platforms at present that are designed to host smart contracts. While the design of these platforms differ, essentially:

  • An asset or currency is transferred into a program (in practice, the program will reference the real world location of the asset or currency, e.g. bank account). 
  • The program is coded in a coding language that is accepted by the relevant blockchain platform. It will also contain validation conditions for when a transaction will be, and what happens when the transaction is, accepted or rejected. 
  • When the smart contract is activated the program will run, and the validation will occur determining whether the asset is transferred, a refund occurs, or a mix of these conditions.
  • Whenever the smart contract is activated, every node on the blockchain platform will store and replicate the most recent state of the smart contract, in addition to the transactions. This is the “immutability” element that is key to blockchain platforms.

For example, a transaction in relation to payments to a fund, and withdrawals from that fund for end users, may involve the following steps:

  1. A user requests a withdrawal from the smart contract. 
  2. The smart contract will check if that user’s balance is sufficient.
  3. If so, the smart contract will activate and send the requested amount to the user’s address.
  4. The smart contract will also activate to verify that the payment was successful.
  5. If so, the amount will be deducted from the user’s balance.

Running a transaction on a smart contract platform requires “transaction fees” among other things, so the nodes executing the contract can be rewarded (given being a “node” involves expending resources, e.g. electricity and processing power). 

Smart contract platforms include:

  • Those that are widely available to the public – e.g. Ethereum and Neo. 
  • Private proprietary systems, available to consortium and/or paying members only – e.g. Corda (focused on financial services) and various platforms being developed for supply chain management (e.g. by IT companies such as Oracle and IBM, frequently in collaboration with industry players). 

What developments in smart contract systems should we look for in the near future?

As smart contracts increase in number and sophistication, a few things will be worth looking out for:

  • Linking multiple smart contracts together: to create a smart contract ecosystem. At that point, we may see smart contracts progress to steps 3 and 4 as outlined above, which will lead to better and more useful smart contracts, given that in practice a transaction (and contract) usually involves multiple stages. 
  • Increasing recognition by court systems of smart contracts: at present, we are not aware of any substantial court decisions or statutes addressing smart contracts specifically. As mentioned, we believe that smart contracts can be legally enforceable, subject to relevant laws and requirements. We expect that as smart contracts usage (and potential disputes) increase, court decisions will give increasing clarity to how smart contracts are viewed, and their coding and drafting can then be tailored accordingly.
  • Increasing recognition by regulators of smart contracts: similarly, we expect regulators to pay increasing attention to how smart contracts can operate in a variety of contexts: this will be particularly important in use cases that affect multiple jurisdictions. For example, in use cases for supply chain management, shipping documents are frequently reviewed/edited by multiple jurisdictions’ custom authorities, who will all need to be familiar with and buy into the use of smart contracts. 
  • Increasing talent in the field: a constraint on smart contracts development at present is that talent has not yet met the demand in the field. Both these activities require substantial talent. As smart contracts increase in popularity and talent is developed via training (both in quantity and quality), we expect the number of both developers (for developing smart contracts) and verifiers/auditors (for verification of smart contracts, whether prior to signing or for dispute resolution) to increase, leading to increased trust in the field.  

We also expect such talent to be developed via a mix of cybersecurity, IT and lawyer personnel.

So where does all of that leave lawyers? Can code ever be law?

Lawyers will still have jobs – and not only that, lawyers can add value to smart contracts in a number of interesting ways: 

  • Contract drafting, coding and verification: smart contracts cannot be drafted in a vacuum. Computer coders will continue to require guidance as to how to code smart contracts (and verify smart contracts prepared by others), in order for them to be legally compliant and to reflect the relevant parties’ commercial agreement. It is particularly important that the coders who are putting these together work very closely with the business managers and the lawyers to ensure that the smart contract faithfully and accurately reflects the intentions of the parties.  
  • Contract interpretation and governance: when a contract goes wrong and doesn’t reflect what the parties want, can it really be said that “code is law”? More likely, there will need to be some kind of mechanism involved for interpreting the smart contract. While code generally has to be in a “yes or no” format, reality has more shades of grey and often presents complicated scenarios. Lawyers will continue to play a significant role in their interpretation and governance.
  • Structuring transactions in a world of smart contracts: lawyers need to be on the lookout for contractual issues that may arise due to the automated nature of smart contracts. For example, when different jurisdictions are involved, how does the smart contract determine which jurisdiction applies? How does a smart contract decide whether a force majeure event has happened? Certain contractual provisions which require subjective determination may need to be carved out and reserved for human determination. Like traditional contracts, smart contracts must be drafted with sufficient flexibility, while a smart contract system on a blockchain may mean that records-related challenges can be overcome, immutability may not be such a good thing in certain contexts. Good lawyers will identify were a smart contract can benefit from some flex room.
  • Interaction with regulators. Regulators will likely welcome input in a number of areas in relation to the real world use of smart contracts, particularly in those industries that involve close regulatory oversight (e.g. financial services industry) and in the following areas:  

– What risk management and governance measures are in place? For example, given smart contacts rely on a decentralised network of nodes (in a blockchain solution) – how are the nodes controlled and what is the relationship between the nodes (and their owners)?

– How does the solution map against any existing applicable regulations?

– Does the solution pose any systemic risk? Does it appropriately manage counterparty risk and bilateral arrangements?  

– How will disasters be managed, e.g. “flash crashes”? Will there be any “kill switch” functionality?   

– Are tamper proof, auditable and understandable?

– How are data privacy and cybersecurity risks addressed? Can an immutable, blockchain-based solution dovetail appropriately with data privacy laws, e.g. the GDPR? 

– Being human! As we have seen human skills continue to be important in relation to lawyers’ work with different stakeholders, whether at the front end transactional stage or at the back end dispute resolution stage. While lawyers will have to attain different skills, the need for human input, judgment and discretion will remain in the foreseeable future. 

We have already taken steps to utilise and develop smart contracts (including via our Ashurst Advance team), and are looking forward to continuing to help develop the ecosystem through our work with clients, regulators and greenfield thought leadership. 

Hoi Tak Leung is a Counsel in Ashurst LLP’s Digital Economy team, based in Hong Kong and working across APAC. He focuses on commercial contracts; TMT/IP/data-focused corporate transactions and regulatory advice; and emerging technologies, including in blockchain and fintech. 

With thanks to: 

  • Mark Edwards (Partner, London), David Futter (Partner, London) and Tae Royle (Head of Digital Legal Services, Brisbane) for their “Breaking Blockchain” seminar, which contributed substantially to this article. 
  • James Leung (Trainee Lawyer, Hong Kong) for his contribution to this article. 

This article first appeared on the Ashurst’s website 

For a refresher on how blockchain works, please read Ashurts Blockchain 101.