Asia Law Network Blog

Smart contracts – can code ever be law?

Reading Time: 16 minutes

We live in an age of disruption – and the legal industry is not immune. “Smart contracts” has been receiving particular attention, with its potential to bring about both efficiencies in legal work… and also new kinds of legal challenges.

What are smart contracts and what can they achieve? 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 contact. 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. In other words, the following elements are present:

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 people in different industries. Smart contracts on a blockchain combines performance with an immutable record of what has actually being performed.

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

Other potential areas for smart contracts include:

All very exciting. But what progress has been made on 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 as evolving in four distinct stages, as follows:

  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, as outlined above, 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 – for example, 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 – for example, a natural language systems procurement contract may have certain schedules sitting under it being 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 – e.g. a supply chain.

The 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 is “black and white”.  While computer coding tends to be unambiguous, traditional legal contracts are frequently drafted with some “flex room” in them, e.g. 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 – its 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:

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.

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.  This will particularly be the case where we are dealing with a smart contract where both parties have had a chance to review the terms (including the computer logic).  This of course depends on whether the parties have had a chance to diligence the smart contract in detail, relating to our earlier referenced issue regarding verification talent in the area.

This will be a potential problem in the Internet of Things sphere where machine-to-machine commerce may create direct contracts (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 in smart contract platform environments where parties have had a reasonable chance to diligence the smart contracts in play. We expect the talent in the verification field to increase as the smart contract system develops so verifiers may be a mix of cybersecurity, IT and lawyer personnel.

It looks like the above smart contract is enforceable. But what if we need to amend it?

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

Fundamentally, many regard smart contracts as irrevocable – so that 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. That is driven by the blockchain technologies that host the smart contract and 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, a 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:

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. Here, however, was clearly an event that was not intended by any of the contractual parties involved yet could it be considered a “hack” or criminal activity, considering the above event was a direct result of the computer code involved, and “code is law” as agreed by the DAO’s participants?

Writing large amounts of code with no flaws is extremely difficult – so in practice, we need to find ways to reflect the parties’ agreement when smart contracts go wrong. One way of addressing this risk is to ensure that the 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 would 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 “code is law” is an ideal that is held to 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. 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:

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:

These agreements and mechanism will need to address a number of areas, including:

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.

“… 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. Our simple diagram of how a blockchain works is below; for our easy-to-read breakdown of how blockchain works, please see our Blockchain 101.

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

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; this is to rewards the nodes for executing the smart contracts (given that there are resources requirements for being a node).

Smart contract platforms include:

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

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

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

Lawyers still have jobs!

We have seen, in this paper, a few areas where lawyers can continue to add value to smart contracts:

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.

Need legal advice?

If you are in need of legal advice, you can speak to a Hong Kong lawyer with a Quick Consult. For a transparent, flat fee, you can expect a call back within 1-2 days to get your questions answered.


This article is written by Hoi Tak Leung from Ashurst and was first published on Ashurst’s website.

With thanks to:


This article does not constitute legal advice or a legal opinion on any matter discussed and, accordingly, it should not be relied upon. It should not be regarded as a comprehensive statement of the law and practice in this area. If you require any advice or information, please speak to a practicing lawyer in your jurisdiction. No individual who is a member, partner, shareholder or consultant of, in or to any constituent part of Interstellar Group Pte. Ltd. accepts or assumes responsibility, or has any liability, to any person in respect of this article.


You may be interested in these articles:

Keep reading related posts