Smart contracts – what are they, and what should you look out for?

On 25 November 2021 the Law Commission published some advice for the UK government on smart contracts.[1]  It found no need to reform the current statutory framework, but considered that the common law on contracts could be developed in certain respects.  In light of the advice, this article examines what a smart contract is, the problems associated with smart contracts, and what parties can do to mitigate the related risks.

Background

In its advice, the Law Commission concluded that the current legal framework in England and Wales is “clearly able to facilitate and support the use of smart contracts”, without the need for statutory law reform.  It confirmed that current legal principles can apply in the same way as they do to traditional contracts, albeit with “an incremental and principled development of the common law in specific contexts”.

The Law Commission saw no need to declare smart contracts as a “special category of contracts” to which normal rules of interpretation are disapplied.[2]  As such, smart legal contracts (referred to below as “smart contracts” for short) are legally binding contracts, just like traditional legal contracts.  The distinctive characteristic of smart contracts is “automaticity”, i.e. that performance of the contract is wholly or partly carried out automatically, without the need for human involvement.

What is a smart contract?

There are two main features:

• some or all of the obligations are defined in and/or performed automatically by a program; and
• the contract is legally enforceable.[3] 

As with code, smart contracts tend to follow a conditional logic with specific and objective inputs, e.g. if “X”, then “Y”.  It is also worth noting that smart contracts are often deployed using distributed ledger technology (DLT), although not always.

What are smart contracts intended to achieve?

It is expected that smart contracts will increase efficiency and certainty in business and reduce the need for trust between contracting parties.  Instead, the trust resides in the code.

Smart contracts are increasingly being considered as a means of automating performance or specific processes within traditional contracts.  They are suited for agreements that do not need third-party validation, and where the terms can be objectively measured (e.g. where a triggering event, like a weather event, can be measured digitally, such as by weather information published by a trusted source).  Current examples include decentralised finance, monitoring of service level agreements, real-estate transactions, parametric insurance, aviation refuelling and managing supply chains.

Range of automation

While smart contracts take a variety of forms, the use of automation in performing an obligation is not new.  For example, payment obligations under a traditional contract are commonly automated by using automated bank payments, such as direct debits or standing orders. 

For the Law Commission, automation should be considered on a spectrum: smart contracts involving the use of standard automation (where the automation is simply a tool and can be reversed easily) sit at one end of the scale, and highly automated or solely-code smart contracts deployed via DLT sit at the other end.  On that spectrum, a smart contract can take one of three broad forms:

• natural-language contract – where some or all of the obligations are performed automatically by the code (which is commonplace and does not raise any novel issues in the context of contract formation or interpretation);
• hybrid contract – where some obligations are defined in natural language and others are defined in code; or
• solely-code contract – where all terms are defined in, and performed automatically by, code.

Where a smart contract is drafted mainly or solely in code and is deployed via DLT, it takes the contract “out of the realm of legal familiarity”, and so novel issues can arise.  Those may well be rare in practice for now, as commercial contracts are typically too nuanced to be reduced solely to code – although solely-code contracts may become more frequent as the technology increases in sophistication.[4]  While the Law Commission does not define smart contracts solely by reference to DLT deployment (which would be “unnecessarily restrictive”[5]), it recognises that DLT systems have distinctive features that justify a considered analysis.

What is DLT, and how are smart contracts deployed using it?

DLT enables the operation of a distributed ledger, which is a digital store of information distributed among a network of computers, each being a “node”.

Unlike traditional databases, DLT is not maintained by a central administrator (such as a bank).  Instead, participants approve and eventually synchronise additions to the ledger via a “consensus mechanism”, which is set by the software and will generally require some or all participants to determine the validity of a proposed data entry.  Once data are added to the ledger, they cannot be amended for practical purposes and so are considered “immutable”.

DLT systems may be “permissioned” or “permissionless” and private or public.  A permissioned DLT system generally requires authorisation to perform a particular activity.  Such permissioned systems tend to be private (i.e. only accessible for use by a limited group), whereas permissionless systems tend to be public.  Various degrees and types of permissioning may apply to a DLT system.

Smart contracts can be deployed via DLT so that contractual obligations expressed in code are performed automatically by the nodes.  So performance of the contract is “guaranteed”, in the sense that human intervention is not required.[6]  In this way, DLT creates trust between participants: the ledger’s immutability means that participants can trust in its veracity and transact in relative confidence.

There are several platforms, such as the bitcoin blockchain and the Ethereum blockchain,[7] that offer an environment to run smart contracts.  The Ethereum network is often said to be a more sophisticated platform for smart-contract applications: it uses DLT that records data, and then enables both transactions and programs to be recorded on the ledger.  The programs are performed automatically by the nodes on the network when the conditions for performance are satisfied.[8]

Potential problems

Problems can arise from highly automated smart contracts, i.e. hybrid or solely-code smart contracts.  The Law Commission has identified a non-exhaustive list of problems associated with such smart contracts, which may require novel legal responses due to the degree of automation.

Identity

As with traditional contracts, a smart contract will typically be preceded by natural-language negotiations.  In principle, though, parties can reach an agreement on a smart-contract platform by deploying and interacting with code, without engaging in natural-language communications.[9]  Since parties can use pseudonyms to transact on a smart-contract platform, some parties might conclude a smart contract without knowing the counterparty’s real identity.  While there is no legal requirement for parties to know each other’s real identity, this might pose challenges further down the line, e.g. if there is a dispute and/or jurisdiction is an issue.  In practice, it may be difficult for a party to seek and enforce a remedy against a counterparty whose identity is unknown.

So it would be advisable to use a smart-contract platform that integrates identity verification mechanisms, such as a permissioned DLT system or a platform subject to “know your client” anti-money-laundering requirements.  For a public or permissionless DLT system, verification may be harder, although it might be possible for a court to order a platform operator to provide data linking a transaction to a particular party. 

Interpretation

Issues may arise in a hybrid contract if natural language and coded terms conflict.  The Law Commission points out that such conflicts could be resolved by applying the principles of contractual interpretation.  In a solely-code agreement, code might execute to give a certain result, but the nature of the legal arrangement is not clear from a code or from the result.  While a court would seek to resolve that as a matter of interpretation, there may be a risk that the agreement may be found to be uncertain or incomplete

When interpreting coded terms, the Law Commission states that the most appropriate way to ascertain the “meaning” of the terms is to ask "what a person with knowledge and understanding of code would understand the coded term to mean" (a "reasonable coder" test).[10]

The Law Commission suggests that parties might create a natural-language aid to interpreting coded terms (such as a business process document or term sheet).  While evidence of parties’ prior negotiations as to the meaning of contractual terms is not generally admissible, if such a document could be considered an antecedent agreement, it might be relied on in interpreting the contract.  The parties could also choose to incorporate such natural-language aid, e.g. by incorporating it into the coded agreement by reference.

The Law Commission explains that it is generally accepted “good coding practice” that programs should include natural-language comments to describe “the purpose of the code and any algorithms used to accomplish the purpose”.[11]  Such comments are not “executable” by the computer; instead, they assist a human reader and can be useful in code maintenance.  In a legal context, such comments could be used to define or express contractual terms, or as an aid to interpretation.  Accordingly, where such comments form part of any code, it is advisable that the parties clearly set out how comments are to be taken into account when interpreting the contract.

Where comments in the code constitute contractual terms, they will be relevant to the interpretation of the contract as a whole, since they form part of the contract.  Conversely, where coded comments do not constitute contractual terms, the Law Commission considers that such comments could still be admissible as a useful aid to interpreting the coded terms.  In this context, the Law Commission likens such comments to headings in a traditional contract; i.e. unless otherwise stated, headings are generally taken into account in construing the meaning of a particular clause, but they cannot override clear language or create an ambiguity where, but for the heading, none would otherwise exist.[12]

Legal relations

If the agreement is made as a result of interaction on a DLT system, the agreement may be inferred from the parties’ conduct rather than as an express agreement.  The Law Commission advises parties “who do intend such transactions to create legal relations” to make this clear in natural language.

Formality requirements and deeds

For a “simple” smart contract, where it requires a signature, a digital signature is likely to suffice, as it is generally capable of satisfying any statutory requirement for a signature.  On the other hand, the notion of a smart deed poses significant challenges, since deeds are subject to various formality requirements (e.g. witnessing and attestation).  It is, in theory, possible for such requirements to be satisfied; for example, a witness could be physically present when a signatory digitally signs the coded terms.  Yet the Law Commission is not sure that the current law supports the creation of deeds that are wholly or partly defined in code – in particular, the requirement that signature and attestation must form part of the same physical document.

Breach and termination

In principle, there is no reason why a smart contract cannot be terminated for breach, and the Law Commission sees no difficulty in applying the existing principles of awarding damages for breach of contract where the terms of a natural-language contract are performed automatically by code. 

As a practical matter, though, the party electing to terminate may not have the power to terminate performance of the code, especially if the code is recorded on an immutable distributed ledger.  So in some cases it may be desirable to integrate a form of “kill switch” or “self-destruct mechanism” into the code, which terminates the performance of the contract if necessary.  The Law Commission recommends thinking about “how best to structure this functionality so as to avoid any associated risk of abuse.”[13]

In addition, where obligations are defined in code, it may be more difficult to establish a breach of contract or the triggering of a termination right, because this is likely to require the parties first to establish the meaning of those terms.  The Law Commission still considers that any difficulties that may arise in this context would mainly relate to the interpretation of coded terms, rather than applying the principles of breach. 

Parties who choose to automate the triggering of termination may face additional challenges.  If a trigger event occurs, the computer will execute a coded termination provision where a human may well have chosen not to do so (e.g. where a delivery of 100 items is short by one), and the termination could lead to a dispute around the underlying reasons for the defective performance, a complex assessment of damages and an adverse effect on downstream contracts.[14]  So any switch, whether automated or not, should be carefully devised.[15]

Other remedies

In the Law Commission’s view, usual English legal principles will continue to apply to smart contracts in the same way as they do to traditional contracts.  The challenges posed by smart contracts in the realm of legal remedies are nearly all matters of practicality resulting from the immutability of the DLT that many smart contracts deploy, rather than of legal principle.

For example, in an action for rectification, a court may face practical difficulties in implementing it where coded terms are deployed on a permissionless and immutable blockchain.  In such a case, the Law Commission suggests that a court could identify the error that needs to be rectified and ask the parties to agree on a revised piece of code.

Void contracts could also pose challenges for similar reasons of irreversability.  A restitutionary remedy (e.g. for unjust enrichment), or at least the equivalent outcome, is particularly important.  For a void contract, the Law Commission considers that “practical justice” could be achieved if a court were to order the parties to enter into an “equal and opposite” second transaction on the ledger, to reverse the effects of the first.  So, while the remedy is not rescission in the strict legal sense, in practical terms the result would be the same and that may well be sufficient in the majority of cases (although a record of the void transaction would be kept on the ledger).[16]

Jurisdiction and applicable law

Where there is no express choice of law, it may be difficult to determine the applicable law, particularly where a smart contract engages multiple different legal systems.  Unsurprisingly, it is recommended that parties designate the governing law.

Making an express choice of jurisdiction is equally advisable:

• When determining jurisdiction to hear a cross-border dispute, a number of factors may be relevant, including the defendant’s physical location and the place of formation of the contract.  Such factors can pose challenges.  For example, given the pseudonymous nature of many DLT systems, a party may not know the real identity of, and so the location of, the counterparty.  There may also be no natural-language interaction, and elements of the contract may be dispersed across a wide range of jurisdictions, making the place of formation hard to determine.
• Applicable law is also a factor in determining jurisdiction.  The Law Commission mentions that, in theory, parties may want to choose that their contract be governed solely by the protocol of a particular platform.  Yet the Law Commission does not consider that this is a choice open to the parties under the Rome I Regulation.  A better mechanism would be to incorporate the platform’s protocol rules as to terms of the smart contract.[17] 
• Jurisdiction rules can also often be based on a legally significant connection, e.g. the place of breach and the place of performance. Smart contracts may present “unique challenges” when seeking to identify the geographical location of breaches, actions and enrichments, particularly where the obligations concern a digital asset, without a clear real-world location.

Consumers

Any business-to-consumer smart contract must be consistent with consumer protection laws, e.g. under the Consumer Rights Act 2015.  For example, under section 68 of that Act, the written contract terms must be transparent, i.e. expressed in plain and intelligible language, and legible.  From the consumer’s perspective, code is unlikely to be readable, comprehensible or informative; in the absence a natural-language explanation, such coded terms will be prone to a finding of unfairness.  So traders who wish to offer consumer-facing smart contracts that contain coded terms would be “well advised to provide clear and informative pre-contractual literature to the consumer, explaining those terms and how they operate”.[18]

The automated performance of a smart contract and the difficulties in terminating or stopping such performance may also make it difficult for the consumer to exercise their statutory right to cancel the contract.  The Law Commission suggests that traders should design B2C smart contracts so that the consumer has the practical means to exercise that right. 

Data sources

Smart contracts may involve the use of “oracles”, i.e. external data sources that transmit information to a computer program.  Examples include weather, interest-rate or air-flight data.  Such data, once transmitted to the program, may trigger events under a smart contract, such as automatic payments.

The Law Commission cites the “oracle problem”, which is the problem of ensuring that such external data sources “provide accurate, reliable and timely data to the smart contract so that it executes in a way intended by the parties”.[19]  In a smart-contract context, the reliance on oracles may shift trust to oracles or arbitrators brought in to resolve disputes, rather than entirely removing the need for trust.

So parties should carefully consider how “oracle problem” risks can be addressed and/or appropriately allocated via the contractual relationship between the parties and the oracle supplier.   Parties should also look to provide for what happens if an oracle malfunctions or data inputs are inaccurate.[20]

The Law Commission recognises that oracles may require specific regulation, commenting that, as technology and use cases develop, it will be important to keep the law under review, and to consider whether regulatory intervention is necessary to address novel issues.[21]

Checklist of tips for mitigating risks

In addition to the points above, the Law Commission helpfully provides a non-exhaustive list of issues that parties could consider (and perhaps provide for) in a smart contract, as summarised below.[22]

1. Planning – Parties should consider engaging in rigorous planning before concluding a smart contract, e.g. to understand the business requirements and contract objectives.
2. Form – Parties should carefully consider the form that the contract will take (e.g. the level of automaticity and amount of code), and whether the form will vary between individual obligations.
3. Code – Parties should confirm the role of the code, e.g. whether it will both define contractual obligations and perform them, or only perform them.
4. Conflict of terms – Parties should consider including an express conflict provision in the contract to set out the relationship between any natural language and coded terms (e.g. the hierarchy in the event of a conflict).
5. Risk – Parties should address and/or allocate risk in relation to:

• a malfunctioning oracle or inaccurate data inputs;
• external events beyond the parties’ control that may affect performance of the code, such as system upgrades or security breaches;
• bugs and coding errors in the code; and
• any potential mistakes that may arise due to the parties’ beliefs or assumptions about how the code will perform.

6. Comments – Parties should stipulate whether non-executable comments in code will constitute contractual terms or whether they are merely aids to interpretation.
7. Explanations – Where the contract contains coded terms, parties should provide a natural-language explanation of those terms, and to clarify that it forms part of the contract.
8. Legal relations – Parties who intend their transaction on a smart-contract platform to create legal relations should make that clear in natural language, either in a separate agreement or by way of non-executable comments in the code.
9. Termination – Parties could consider integrating a form of “kill switch” or “self-destruct mechanism” into the code, which terminates the contract if necessary.  Any such switch would need to be carefully devised, e.g. to reduce any risks of abuse by either party.
10. Suspension – Parties could consider including a mechanism in the code to suspend the smart contract in certain circumstances (e.g. pending the outcome of a dispute).
11. ‍Dispute resolution – Parties would be wise to include law/jurisdiction clauses in the smart contract. This could be included in a separate natural-language agreement or by way of non-executable comments in the code (although it must be made clear that those comments constitute contractual terms).

Comment

While smart contracts are still in their infancy, they still have the potential to change the way that certain markets operate.  Their use is likely to have extensive implications in various legal fields, and parties should be alive to the potential pitfalls of their mechanics and enforcement.  As the use and prevalence of smart contracts increases, the Law Commission expects that the market will develop established practices and model clauses that parties can use when negotiating and drafting smart contracts.[23]

While smart contracts have potential for various applications, their drawbacks should be recognised.  For example, the inclusion of deliberately ambiguous terms poses significant challenges: provisions involving terms such as “reasonable endeavours”, “good faith” or “to the extent possible” cannot be executed as code and so cannot, at least currently, be performed automatically in a smart-contract context.  As such, the use of smart contracts (at least in the near term) is unlikely to become universal, particularly in more complex commercial transactions.

When considering whether to conclude a smart contract, parties should, first and foremost, carefully consider what obligations they wish to automate.  The interaction between the agreed legal terms and any technical or automated implementation of those terms will be crucial: misalignment may well throw up more problems than it aims to solve.

‍