The Law Commission's report on smart legal contracts published in November 2021, concluded that the law of England and Wales is "sufficiently robust and adaptable" to support and facilitate smart contracts.
In fact, closer reading of the report reveals that there are potential issues, particularly in relation to deeds and some types of smart contract – notably hybrid smart contracts (where contractual terms are in a combination of natural language and code), and contracts executed solely in code.
While the Law Commission considers that these issues cannot currently be resolved with respect to deeds, some of the potential issues around smart contracts discussed in the report are best managed by dealing with them in the negotiating and drafting/coding stage, effectively minimising the risk of a dispute by heading issues off at the pass. Isn't that what all good contracts should do?
As the Law Commission points out though in its checklist in the summary of its report, the issues peculiar to smart contracts are not always those to which the parties (and their lawyers) are used to paying particular attention. So what are the special considerations?
What form will the contract take?
The parties need to take a decision on the form of the contract and whether it will vary between obligations. It may be:
- A natural language contract with automatic performance by code – in this type of smart contract, the code does not define contractual obligations but is used to perform obligations. The code itself falls outside the scope of the legally binding part of the agreement. This is the most commonly used type of smart contract at present, partly because it does not raise any new issues around contract formation or interpretation.
- A hybrid contract – some contractual obligations are defined in natural language and others are defined in code. Some or all the obligations are preformed automatically by the code. The same contractual terms can be written in both natural language and code, and the natural language terms can be incorporated in an accompanying natural language agreement or in natural language comments included in the code.
- Contract recorded solely in code – all the contractual terms are defined in and performed automatically by the code and there is no natural language version of the agreement or any part of it. This type of smart contract is likely to be rare in practice. The Law Commission's view is that commercial contracts are typically too nuanced to be reduced solely to code.
Given that the Law Commission's suggestions for dealing with risks particular to smart contracts often involve setting things out in natural language, parties to commercial contracts are unlikely to select the final option at present. However, they should then make clear the role of the code in their smart contract and specify whether or not it is intended to define contractual obligations as well as perform them.
Assuming that the parties select one of the first two types of contract, they will need to consider the relationship between natural language terms and coded terms. This is particularly important if the same terms are expressed in both. It should be made clear which take precedence in the event of conflict.
Technical considerations
Those used to negotiating and concluding technology contracts will be well aware of the need to conduct due diligence on code and provide for potential issues. Others may be less used to considering and allocating risk around malfunctioning oracle or inaccurate data inputs, bugs and coding errors, and the need for upgrades. While smart contracts on distributed ledgers are error free and accurate according to their coding, if the coding is flawed, it might lead to mistakes in performance or in expectations around the way the code will perform.
Cybersecurity is another issue which will be particularly important. While many smart contracts use distributed ledger technology which has the benefit of being very secure, it's not a requirement and cybersecurity should be given particular consideration if the contract is not recorded on a DLT.
Contractual issues
If a smart contract does sit on a DLT, one of the benefits is that it is 'trustless' – there is no need to trust a party to carry out an obligation. Not all DLTs are open permission though. Permissioned ledgers are private. The system is only accessible by a limited number of participants and authorisation is required to perform particular activities. Permissioned ledgers may be appropriate for certain types of smart contract but it will then be very important to ensure that the parties are clear about who is permissioned to do what, and this information should be recorded, preferably external to the code as well as or instead of in the code.
In addition, the parties should consider providing a natural language explanation of the way the code works and make that a part of the contract. It's also important to make the role of non-executable comments clear, especially whether they are contractual terms.
The Law Commission recommends that the parties to a smart contract state their intention to create legal relations in clear natural language, either in a separate agreement or as part of the code. Similarly with choice of law and choice of court clauses (see here for more).
It's important that as well as spelling out what it takes to enter into the contract, the parties consider how to terminate it or suspend it pending the outcome of a dispute. There should be an appropriate mechanism to stop the code performing automatically. The way this is set up and who can trigger either termination or suspension needs careful thought – here again, permissioned ledgers may be the answer but the permissions need to be agreed and recorded.
What about consumer smart contracts?
Under the Consumer Rights Act, consumer-facing written terms must be transparent. This entails that they are expressed in plain and intelligible language and are legible. While code can constitute 'writing' for the purposes of contract formation, coded terms in a B2C smart contract are unlikely to be transparent to the average consumer. This means that a natural language explanation should be provided to ensure terms are transparent, and also to avoid the risk of the contract being considered to be unfair.
Any natural language explanation should set out the terms of the contract including any pre-contractual information required under the Consumer Contracts Regulations. It should also explain the coded elements of the contract and what they do.
Consumers have rights to particular remedies under consumer protection law. Traders need to be careful these rights are not breached by the contract performing automatically when it should be halted. For example, where the consumer has a right to treat the contract at an end, they must have the means of doing so.
What's the point?
It's arguable that until people become more familiar with smart contracts, even though they may work from a legal perspective, they may not be suitable for consumers in many situations. However, the security, reliability, speed and immutability of smart contracts means their potential commercial applications are widespread. As discussed here, financial services is a sector which benefits particularly, but smart contracts are also useful for supply chain management, in government, insurance, property transactions and escrow, to name but a few.
The Law Commission's view that English law can accommodate the majority of smart contracts is welcome but in the adoption phase, there may be a steep learning curve. Careful consideration of when, how and how far to automate is needed for each new use case.
