Hoi Tak Leung, our Associate Editor for Hong Kong and China, takes a fresh look at smart contracts and when or whether they are enforceable.
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:
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:
Other potential areas for smart contracts deployment include:
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:
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:
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 - 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.
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:
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:
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. 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:
For example, a transaction in relation to payments to a fund, and withdrawals from that fund for end users, may involve the following steps:
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:
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:
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:
- 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:
This article first appeared on the Ashurst’s website
For a refresher on how blockchain works, please read Ashurts Blockchain 101. https://www.ashurst.com/en/news-and-insights/insights/blockchain-101/