Distributed Ledger Technology (DLT), commonly known as blockchain
technology, is driving a new wave of innovation across many industries. Blockchain
is often billed as a technology able to revolutionise how businesses operate,
by improving reliability, security and speed due to the decentralisation of
transaction approval processes. However, there remain a number of regulatory,
technical, legal and practical challenges to the widespread commercial
implementation of this technology, which need to be overcome.
One of these challenges is to understand how so-called ‘smart contracts’
may be treated under the law as it stands today and to what extent it is
necessary for the law to evolve in order to keep pace with the digitisation of
business practices. This is a wide-ranging and important task which is now under
review by the Law Commission (as can be seen in its Annual Report for
2017/2018). What is apparent is that significant complexities and practical
difficulties could arise when applying existing legal principles in the context
of smart contracts – including basic English law concepts relating to contract
formation, interpretation and enforcement.
What are smart contracts and why are they exciting?
Blockchain – the basics
Blockchain was born out of Satoshi Nakamoto’s work on the
cryptocurrency Bitcoin and the technology used to prove ownership of that
digital asset. The application of this technology, however, goes well beyond
cryptocurrencies.
In simple terms, blockchain is a way of recording and verifying
data in a decentralised way. This is done through a distributed ledger of
transactions (ie a bookkeeping record that is visible simultaneously to all
users and updated in real time), which is maintained by its users rather than
by a single centralised authority. Each transaction is recorded by all members
of the network so that the network contains a continuous and complete record
(the chain) of all transactions performed. These transactions are grouped into
blocks. A block is only added to the chain if members in the blockchain network
reach consensus that it is the next ‘valid’ block to be added to the chain.
Smart contracts – a software tool for automating business
practices
A key practical application of blockchain technology is ‘smart
contracting’. The advent and adoption of smart contracts pre-dates blockchain
technology. However, their use as an application of this burgeoning technology
is giving smart contracting a renewed appeal.
The term ‘smart contract’ was coined by Nick Szabo in 1994 as ‘a computerized transaction protocol that
executes the terms of a contract. The general objectives of smart contract
design are to satisfy common contractual conditions (such as payment terms,
liens, confidentiality, and even enforcement), minimize exceptions both malicious
and accidental, and minimize the need for trusted intermediaries. Related
economic goals include lowering fraud loss, arbitration and enforcement costs,
and other transaction costs’.
In short, this term refers to a piece of computer code that is
capable of monitoring, executing and enforcing a digital action between two or
more parties. Put another way, it is a computer programme which executes a
command, such as ‘if A, then do B’.
Use cases for smart contracts
Smart contracts can automate many different kinds of processes and
operations. While the most obvious are payments and digital actions conditional
on payments, the possibilities for smart contracting to become pervasive – including
in relation to complex commercial arrangements – are exciting. Indeed, the
potential efficiency gains from digitally automating an action previously
completed manually are obvious. Potential use cases are relevant to most, if
not all, industry sectors. Some of the most often-cited use cases for
blockchain include supply chain tracking, provenance verification, IP licensing,
financial and commodity trading, real estate title registration and identity
verification. However, the scope for blockchain to disrupt business practices
applies more broadly to processes ranging from data control, authentication and
title transfer to improved regulatory or contractual controls, increased
transparency and security of data.
The
Australian National Blockchain
The potential benefits of smart contracting are difficult to
dispute and have been heralded for some time. However, to date, existing
blockchain infrastructure (ie the underlying digital platform on which
blockchain applications can run) has been designed primarily with
cryptocurrencies in mind. The ‘cyberpunk’ objectives of developing fully
distributed and permissionless ecosystems (which led to the advent of this new
technology) cannot readily be reconciled with the way in which large companies
and regulators operate. For this reason, our firm, Herbert Smith Freehills, has
teamed up with IBM, CSIRO’s Data 61 and King & Wood Mallesons to launch a
new digital infrastructure using a private blockchain, which has been designed
to account for the practical realities of operating in a regulated world in
which parties’ contracts need to comply with applicable laws and be enforceable
before national courts or tribunals in the event of disputes.
The ‘Australian National Blockchain’ will be Australia’s first
large-scale, enterprise grade and industry-agnostic digital platform and will
provide businesses with the ability to automate aspects of their business
practice in a legally-valid and compliant, pragmatic way.
The legal effects of smart contracting under English law
Contract formation
The term ‘smart
contract’ is a confusing one; it has often been remarked that a smart contract
is not, in fact, either smart or a contract (in the traditionally recognised sense).
As mentioned above, a smart contract is a computer programme that can execute an
‘if A, then B’ command. While the A and B in this example could themselves be an embedded series of digital
actions, it is clear that a command of this nature – if written directly into
code – may not necessarily be what English law would call a ‘contract’.
On the contrary,
treating a smart contract as if it automatically has the effect of a
traditional ‘natural language’ contract under English law would be foolhardy.
The qualitative differences between computer code and natural language raise potential
hurdles for parties seeking to rely on a smart contract to create binding legal
relations.
The technological innovations associated with blockchain
technology, which result in the practical immutability of published
transactions, create legal uncertainty about how courts and tribunals will
interpret and enforce parties’ agreements written in code. This is especially
the case when parties seek to rely on the smart contract language (ie the
computer code) directly, rather than agreeing a traditional, valid and binding
natural language contract of which one or more clauses are subsequently
translated into code and published to the blockchain.
Indeed, to have a legally enforceable contract which gives rise to
new rights and duties between its parties, the following five elements need to
be present: (i) offer; (ii) acceptance; (iii) consideration; (iv) intention to
create legal relations; and (iv) certainty of terms. Quite plainly, a
standalone ‘smart contract’ to the effect that ‘If the FTSE 100 is below 7,500 at 1pm London time on Tuesday, transfer [a
digital asset] from Charlie to Rachel’ lacks
several of those elements.
Offer and
Acceptance
Insofar as the applicable blockchain infrastructure requires all
parties to a transaction to approve it using their respective private keys, the
very publication of the smart contract to the blockchain may evidence that an
offer has been made and accepted. However, it might be more difficult to
identify which party made the offer and which party(ies) accepted it.
Similarly, it might also be difficult to identify when the acceptance took
place (and therefore when a valid contractual obligation came into effect). For
example, acceptance could be said to occur at the time when the final party to
the transaction approved it by means of entering its private key or only when
the transaction is approved through the consensus mechanism and published to
the blockchain (in encrypted form) as part of a valid block. A third option,
depending on the way in which the applicable blockchain platform is designed,
might be to treat transactions as ‘final’ only when the block in which they
feature has been linked to a certain number of subsequent blocks.
A similar issue in this context would be to identify where
acceptance took place. The answer to that question would be relevant to the
question of jurisdiction (ie failing an express agreement between the parties,
which courts would be the right place to bring a claim).
Consideration
As to consideration, English courts do not question the adequacy
of consideration, but there must be some exchange of value. Where a smart
contract reflects a digital action which turns on an event which is outside the
parties’ direct control, it may be unclear what consideration is being given by
the recipient. It is therefore important that any smart contracts of this
nature sit within a broader interlinked network of smart contracts or link back
to a broader (natural language) agreement in which bilateral consideration can
be identified.
Intention to create legal relations
A valid contract under English law requires intention to create
legal relations. The parties’ ‘intentions’
are gauged by reference to an objective analysis of the contractual
documentation itself including, for instance, by reference to any contractual
recitals. However, of itself, the smart contract may not evidence any intention
to create a binding legal obligation (particularly where it does not identify
any applicable law or dispute resolution forum). Parties could instead try to
rely on the presumption of intention between commercial parties. However, this
could more easily be rebutted in the context of a standalone smart contract,
particularly as the smart contract would probably not be drafted directly by
lawyers.
Certainty of terms
Two aspects of smart contracting could represent a hurdle for
‘certainty of terms’. First, smart contracts may be designed (particularly when
further developments are made in the field of artificial intelligence) to
evolve autonomously and in a way which the parties (and courts or tribunals)
may not be able to anticipate at the time of contracting.
Second, natural language terms which are often used in practice to
avoid absolute obligations while maintaining adequate certainty (such as concepts
of ‘reasonableness’, ‘unconscionability’ or ‘negligence’) cannot be written in
computer code.
The potential issues raised above could theoretically be solved as
part of the coding process (eg evidencing an intention to create legal
relations by including non-functional notes in the software coding, which would
have a similar effect to recitals and confirm the parties’ intentions to be
bound). However, this requires parties to engage in a legally-compliant and
lawyer-led approach to the design of the blockchain ecosystem and the drafting
of smart contracts. This is the approach that Herbert Smith Freehills has taken
in designing the technical infrastructure for the Australian National
Blockchain and the ‘smart legal contracts’ (as opposed to ‘smart contracts’)
which it is intended will operate on it.
Contract interpretation
If the FTSE 100 example above was correctly coded into a smart
contract and published to a blockchain platform, then the programme may execute
according to the parties’ wishes. However, if the data source which was
intended to confirm to the computer programme the index level at the relevant
time failed or no longer existed, or if the digital asset to be transferred was
not available in Charlie’s wallet at 1pm on Tuesday, then Rachel might get
limited support from the English courts or an arbitral tribunal applying
English law. The smart contract may not be enforceable as a matter of law
should things not happen as planned. Assuming, however, that a smart contract
has been written in a way that clearly evidences the requisite conditions for
contract formation, how would a court or tribunal proceed to interpret the
parties’ agreement?
However clearly parties think they have articulated their intentions
at the time of contracting, natural language contracts very often generate
difficult questions of interpretation when a given clause or provision comes to
be implemented.
This may be because the parties had different understandings and
intentions at the time of contracting which did not get flushed out in the
negotiation process (or were deliberately left somewhat ambiguous), or because
circumstances have changed in such a way that the words (when re-read) no
longer carry the same meaning as they initially did to one or other party. In a
scenario where the parties to a ‘traditional contract’ disagree on the meaning of
the words used, they can refer the question to a neutral decision maker
(generally the courts or an arbitral tribunal). But where the parties have written
an obligation or contractual provision into a smart contract, the software will
execute in the only way the computer can understand it. In short, computers do
not interpret computer code, they merely execute it. That is not to say,
however, that the computer will always execute in the way the parties expected
or intended.
How would courts or arbitral tribunals apply Lord Neuberger’s
seven steps for contractual interpretation set out in his judgment in Arnold v Britton [2015] UKSC 36 (at
[17]-[23]) when the ‘language’ which the parties have used is computer code?
To identify the ‘natural meaning’ of the words used in the
computer code would be of no assistance, as the syntax and literal translation
of code into English would be largely meaningless. In addition, judges or
arbitrators may not themselves have the skillset to read and understand the
coding written by the parties. This raises the question of whether parties
would need to adduce expert evidence on even the most basic issues of
contractual interpretation or, alternatively, if courts and arbitral
institutions may need to have on hand for any smart contract-related dispute a
standing ‘expert’ who can support the judges or appointed arbitrators. Careful
consideration would need to be given to the role of such a ‘standing expert’ to
avoid detracting from the ultimate decision-makers’ judicial powers. This also
emphasises the need for lawyers to develop a greater understanding of coding
logic and languages, and a number of law firms (including ours) are
implementing courses to further develop these skillsets internally. It will
take a long time, however, for these skills to become pervasive among legal
practitioners (let alone among members of the bench).
It is also unclear how the court would identity the intentions of
the parties in a case of this nature. In Arnold
v Britton, Lord Neuberger refers
to ‘identifying what the parties meant
through the eyes of a reasonable reader’. However, in the context of smart
contracts, the reasonable reader of a piece of code (subject to having evidence
of an error or mis-translation in the code) would likely read it in a way that
identifies how the computer would execute it. Again, that would not much assist
the court, particularly if the principles for contract interpretation remain
that the court or tribunal should not depart from the meaning of the words used
if they are unambiguous.
A viable solution at this stage would be for parties to ensure
that they sign a valid and binding agreement in natural language which
expressly takes primacy over the translation of any of its provisions into
smart contracts in relation to issues of interpretation. This may not prevent parties,
however, arguing that the smart contract in question represented an amendment
or collateral agreement which had the effect of changing the way in which the
natural language contract should be read.
Remedies where the smart contracts fail
to operate as expected
Rectification
Instead of parties seeking to argue that a court or tribunal
should interpret a smart contract to mean something different to the way in
which it was executed by the computer, they may stand a better chance of
implementing the parties’ true intentions by seeking to ‘rectify’ the smart
contract coding. In cases of mutual mistake, this would involve one of the
parties evidencing that the ‘coder’ who translated the parties’ ‘common intentions’ got it wrong.
Where parties have written their agreement directly into code, the
court will look at the evidence available to it, including that of prior
negotiations, to determine whether the agreement between the parties is
properly re?ected in the code of the smart contract. Interesting questions
arise regarding the interplay between contractual interpretation and
rectification where the smart contract is a translation of a natural language
agreement between the parties.
In a claim for rectification, the parties’ subjective intentions will
need to be ascertained. However, if the smart contract translates a written
agreement, the error would be in the translation of how the written agreement
required the parties to act. Interpreting that written agreement would be an
exercise in contractual interpretation, ie ascertaining the objective
intentions of the parties in accordance with the principles set out in Arnold v Britton.
A further difference of substance with the operation of
traditional contracts arises here. Unless the parties have included a ‘pause’
command – which suspends the operation of the smart contract in the event of a
dispute – the smart contract will execute regardless of whether the result reflects
or is wildly at odds with the parties’ intentions. The computer executing the
code will not apply any reasonableness or common sense threshold in executing
the code. As such, instead of the usual scenario where a party who complains of
the mistake refuses to perform the contract pending an agreed amendment or a
determination from a court or tribunal, claims for rectification will often
need to be accompanied by a claim for breach, restitution or specific
performance (i.e. to undo or counteract the operation of the ‘erroneous’ smart
contract). Declaratory relief in this scenario would likely be inadequate,
particularly given the immutability of the smart contract once published to the
blockchain.
Frustration, fraud and invalidity
Similar questions may arise where a command of the smart contract reflects
an agreement between the parties which, by virtue of a change in circumstances
in the non-digital world or by virtue of applicable law, becomes voidable, frustrated
or invalid. Again, in the absence of any ‘pause’ command expressly built into
the software code which can be triggered by the parties to suspend the
operation of the smart contract, it is unclear how (from a practical
perspective) the smart contract could be rescinded. In such circumstances it
may be necessary for a court or tribunal to order that the parties take such
steps as is necessary to undo or counteract the execution of the smart
contract. This may involve the more frequent use of equitable remedies such as
accounts of profits, equitable compensation, equitable liens and asset tracing.
Conclusion: is English law ready for a transition to smart
contracting?
Current principles under English law regarding contract formation,
validity, interpretation or suspension are ill-suited to be directly applied to
a contract drafted entirely in computer code. Clearly, there are also practical
issues regarding the ability of lawyers, judges and arbitrators to understand,
opine on and/or seek to counteract or correct software execution. That being
said, the English courts have historically taken a pragmatic approach to the
use of new technologies or business practices and the law has developed to
accommodate for them in order to ensure that justice is served. It remains to
be seen whether a similar approach can or will be taken in relation to smart
contracts.
In the meantime,
parties can mitigate the risk that the intentions behind their ‘smart contracts’
might be mistranslated into code or misconstrued by judicial or regulatory
authorities by reverse engineering blockchain infrastructure and smart
contracting design from existing legal principles and legislative requirements.
Parties could achieve this by agreeing a ‘traditional’ natural language
contract which sits outside the blockchain and relevant provisions of which are
translated into code and published to the blockchain (as a means of
implementation, but without any contractual effect). Alternatively, parties can
look to develop ‘smart legal contracts’, which are held within the blockchain
ecosystem but for which the operative code of the ‘smart contracting’
applications is not a part of the binding legal mechanics of the agreement.
These approaches will also ensure that parties can more readily seek support
from traditional judicial authorities (be it courts or arbitral tribunals) to
enforce their contractual agreements when the smart contract itself may not
execute as planned.
Rachel
Lidgate is a Partner and solicitor advocate in Herbert Smith Freehills’ dispute
resolution division in London.
Charlie
Morgan is an associate and solicitor advocate in Herbert Smith Freehills’
dispute resolution division in London.
