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:
- 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 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
- 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 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. 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:
- 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.
- 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.
- 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).
- 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:
- 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. 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.
- Having said that, it is also important to note 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 (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:
- 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 – and this would be particularly difficult in certain contexts, such as jurisdictions where the information is only available through a governmental authority, but that authority is not yet making the 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 generally wide 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 – 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.
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.
- Governing law and dispute resolution mechanisms, including when smart contracts are “not so smart” – see above discussion of DAO example. 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. 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:
- 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:
- A user requests a withdrawal from the smart contract.
- The smart contract will check if that user’s balance is sufficient.
- If so, the smart contract will activate and send the requested amount to the user’s address.
- The smart contract will also activate to verify that the payment was successful.
- 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:
- Ethereum (available to public).
- Neo (available to public).
- Private proprietary systems, available to consortium and/or paying members, e.g. Corda (focused on financial services) and Oracle (focused on supply chain management).
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:
- 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 below, we believe that smart contracts will be legally enforceable; 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 programming can 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 will frequent be checked by multiple jurisdictions’ custom authorities, and so they 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. 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 increase trust in the field.
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:
- Contract drafting and coding: smart contracts cannot be drafted in a vacuum. Computer coders will continue to require guidance as to how to code contracts, 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 guys and the lawyers to ensure that the smart contract faithfully and accurately reflects the intentions of the parties. Code, just like written prose, can be ambiguous. At the moment, smart contracts will still have to operate in conjunction with “traditional” contractual terms.
- Contract interpretation: 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.
- 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 records tamper proof, auditable and understandable?
- How are cybersecurity risks addressed?
- 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 and judgment 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.
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:
- 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 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: