Smart Contracts - South Africa - Global Law Firm - Norton Rose Fulbright

9/10/23, 4:00 PM Smart Contracts | South Africa | Global law firm | Norton Rose Fulbright
Smart Contracts
Global | Publication | November 2019
Introduction
What is a smart contract?
Formation: The spectrum of smart contracts in practice
Code as Contract
Interpretation
Concluding Remarks
Introduction
This chapter from the forthcoming book The Contents of Commercial Contracts: Terms Affecting Freedoms was co-written
by Dr Adam Sanitt, Head of Disputes Knowledge, Innovation and Business Support, Norton Rose Fulbright and Professor
Sarah Green, University of Bristol, Law Commissioner for England. Reproduced by kind permission of the editors, Professor
Paul Davies and Dr Magda Raczynska of University College London.
https://www.nortonrosefulbright.com/en-za/knowledge/publications/1bcdc200/smart-contracts 1/14
The technology that makes smart contracts possible3 was developed with a view to enabling transactions to be made
end-to-end without the intervention of third parties, intermediaries, adjudicators or courts. In this sense, it achieves in
principle complete freedom of interaction. Whether this is the same thing as freedom of contract, however, remains to be
seen. It is not yet clear, for example, which smart contracts will be legally enforceable, either because the parties do not
want them to be, and/or because the courts do not recognise them as being so. What seems inevitable at this stage in the
development of smart contract technology is that conventional contract law in its current form is unlikely to be the most
effective way of adjudicating smart contract disputes. One reason for this is that securing performance will be far less of a
problem under smart contracts than it is in relation to conventional contracts: the automated nature of the former means
that actions are far more likely to be executed than those promised in the traditional way, albeit that their results might not
accord with the parties’ expectations. Any issues are therefore far more likely to arise (or at least to be brought to a court’s
attention) after a transaction has occurred. Automated execution means that parties are free to determine the contents of
their agreements, and that machines will abide by those agreed instructions. The way in which smart contracts operate,
therefore, means that any adjudication of them is likely to need to emphasise restorative rather than enforcement
remedies. The extent to which the law chooses to do this will effectively determine how free smart technology users are to
make legally recognised contracts.
In order to make clear how and why smart contracts differ so markedly from conventional contracts, it is worth setting out
a brief description of the relevant technology before turning to its legal analysis.
What is a smart contract?
Smart contracts are self-executing transactions, written in computer code and performed in an automated way. They have
been made possible by a particular series of technological developments that have happened over the past decade. These
developments have enabled decentralisation and consensus to replace intermediaries in transactions between
contracting parties. In other words, contracting parties can now deal directly with one another without banks, without
offline registries and, potentially, without lawyers.
Decentralisation and Distributed Consensus
Deentralisation and distributed consensus are the components which distinguish smart transactions from those which
use intermediaries and electronic bank money, such as Paypal, WorldPay and BACS. These components also explain why
smart contracts are often described as “trustless”, meaning that transacting parties need not trust each other in the real
world, so long as they trust the payment protocol (which, for reasons which will soon become apparent, they Pobably
should).
Decentralisation is probably easiest to explain in the context of Bitcoin and its Blockchain (Bitcoin being the
cryptocurrency and Blockchain the distributed ledger), although there are other platforms, such as Ethereum, on which
smart contracts could be made. Decentralisation is achieved through Distributed Ledger Technology (or DLT). This means
that everyone who wants to contract using a particular piece of software has, as an integral part of that software, a copy of
a ledger. This ledger is a record of every transaction made using that protocol, and each computer operating the software
(known as a node) has a copy of the entire thing: from the beginning (the “Genesis Block”) to today’s latest block.
Blockchain, which was created to underpin Bitcoin, was the first distributed ledger, but there are now distributed ledgers
of several different forms. Common to every one, however, is the idea that all participants have access to the full history of
transactions made using that protocol. This is a novel way of dealing with the age-old double spend problem. Historically,
the challenge of how to prevent double spending has been met in two ways: the first is by using physical tokens, whose
corporeal form physically prevents their being spent more than once, and the second is by employing an independent
third party, such as a bank, to keep a record of transactions and their effects on the subsequent spending power of the
parties involved. DLT achieves the same thing by sharing information with every user and by ensuring that the information
so shared is perfectly synchronised. This way, “coins” cannot be spent twice because everyone would know that this is
what was being attempted, and the consensus necessary for validation and recording would not be reached. Security is
thus achieved through complete transparency, and distributed ledgers have no need for any centralised record-keeping,
nor for any third party intermediary to verify the integrity of transactions. In other words, “total validation replaces central
control”.4
Such transparency is achieved through what is known as distributed consensus protocol, and this is characterised by two
features:
All computers on the network (referred to as nodes) must agree on which transaction data is ultimately recorded on
the ledger
The transaction data must have been generated by an honest node5
The question remains how any of this can be achieved. One method, used by Bitcoin, is known as proof-of-work, and this
allows nodes to reach a consensus on which transactions to record and in which order to do so. (The order is of course
all-important, as it is with any spending pattern, since what you have already spent determines how much you can spend
in the future.) Proof-of-work is the means by which nodes persuade other nodes that the block of transactions that they
wish to add to the chain is legitimate and should be trusted. The work involved here is cryptography; the solving of a
mathematical puzzle, and this puzzle is of a very specific type: the optimal way of solving it is to work through very large
numbers of trial and error iterations. In other words, lawyers might say that it is a difficult case, but not a hard one. It is
clear what needs to be done, but it takes an immense amount of computational power6 to work through the many
repetitions of the same calculation, each time trying a different input. The puzzle is known as a hash puzzle and success
requires finding the input necessary for a function to produce a specified output. The hash function itself, which is the crux
of this whole process, could be described in non-mathematical terms as a function which takes an input and produces an
output which will look nothing whatsoever like the input.7 In fact, it is practically impossible to discover the original input
simply by looking at the output, unless you know the hash function. Diedrich has provided the following illustration of how
hashes work.8
There are different hash algorithms. One hash algorithm that was once popular was called MD5. For example, this
text:
MD5’s designer Ron Rivest has stated “md5 and sha1 are both clearly broken (in terms of collision resistance)”. So
MD5 should be avoided when creating new protocols, or implementing protocols with better options. SHA256 and
SHA512 are better options as they have been more resilient to attacks (as of 2009).
has the MD5 hash:
ed7f56281b8d079ff101009105f75b44
…The hash ed7f56281b8d079ff101009105f75b44 can be used as a unique id for the above text, for two reasons:
If any punctuation or word was changed, you’d get a different hash for it.
You will not for your life be able to find another text that results into exactly this hash.9
Crucially, the same hash function, applied to identical inputs, will always produce the same output. Applying the same
hash function, however, to an input which is different from the original in only a miniscule detail will nonetheless result in a
completely different output. This explains why the only way to solve such puzzles is through repeated trial and error: there
are no shortcuts or clues provided by previous work and the results of previous attempts are not in any way cumulatively
helpful. So, Sherlock Holmes could not take the approach he took to the Dancing Men.
Instead, nodes who wish to add a block to the chain first take a set of transactions that have been broadcast10 across the
network. They then add to this something called a blockhash. A blockhash is the output generated when the hash function
is applied to the whole of the previous block in the chain. This blockhash serves therefore as a unique identifier of all the
data in that previous block, and so is what links the blocks (hence the term chain) and at the same time makes the
protocol so secure: embedding this unique summary of the previous block’s data in the following block, and therefore in
all future blocks,11 makes the blockchain practically tamperproof. If any node wants to alter or modify the content of any
given block, it would also have to rehash all of the blocks which follow it, and compete to persuade all nodes (who would
be working on the basis that the original date were correct) that the new reality was the right one. This is so difficult,
particularly in terms of computational power, as to be well-nigh impossible in the current environment.
So, to return to the proposing node, which has taken the set of transactions it wishes to verify, and added the blockhash.12
The node then starts the real work: it also adds a value as the mystery input, which is known as a “nonce” in cryptography.
It then hashes all of this together (which means applying a specific and consistent hash function, which in the case of
Bitcoin is called SHA256) and keeps doing this, using a different nonce each time, until it gets an output with the “correct”
number of leading zeros.13
At the heart of this scheme is the fact that a nonce is hard to find but easy to verify. While it routinely takes trillions of
trial-and-error calculations to find it, it requires but one calculation to verify it: to test that a nonce is in fact resulting
into a hash with the required number of leading zeros when added to the block data that it was found for.14
This is known as “trapdoor” maths because of its one-way structure; it’s very difficult to find the answer but, once you have
the answer, it’s very easy to verify that it’s the right one. A simple analogy can be made with the combination to a
briefcase lock. Anyone wishing to open the briefcase without knowing the combination will have to try (probably) very
many attempted combinations to find the one which opens the case. Once she has found it, however, it is very easy for
someone else to verify that she has found the correct combination: the verifier simply needs to put that combination into
the briefcase dial and see if it opens. The result is a binary one – pass or fail. Similarly, once a node has found what it
believes to be the right nonce, the other nodes verify that it’s correct by simply applying it to the publicly-available data. If
this produces the same output (the one with the required number of leading zeros), verification is complete. Once this
happens, the proposed block gets added to the chain and the transactions in it get confirmed.15
This, however, is not the only thing which happens when the block gets verified. Another of DLT’s revolutionary qualities is
its alignment of self-interest with altruism. Verifying blocks is hard grind and very expensive in computational terms, and
yet it is essential to the continuation and security of the system. So, when a node successfully adds a block to the chain, it
gets rewarded with bitcoin. In the Bitcoin protocol, the verification process is known as mining, and is simultaneously the
means by which new coin is minted.16 This is a system, therefore, in which self-interest works in favour of the collective
interest, and the two are mutually reinforcing. Not all DLT systems use proof-of-work, and not all reward nodes with
cryptocurrency, but some sort of consensus is required to maintain the ledger. This consensus may be limited to approval
by an entity or group of entities, known as notaries, nominated by the parties to a transaction, with the DLT system
providing only a secure messaging protocol to communicate that consensus. A more distributed approach is achieved by
DLT systems that dispense with a blockchain and instead require transactions to be approved by groups of later
transactions forming a web carefully designed to avoid circularity (known as a directed acyclic graph, or DAG). Other
variants keep the blockchain but opt for consensus protocols other than proof-of-work. To the extent that DLT systems
employ distributed consensus as the means of achieving decentralisation, they are all able to facilitate direct contracting
between parties without needing to involve intermediaries.
In practical terms, smart contracts differ from conventional contracts in the following ways:
• The entire lifecycle of a smart contract, from formulation to execution, occurs online
• That lifecycle need not at any point involve any entity other than the contracting parties (since, for instance, payment
can occur directly from bitcoin wallet to bitcoin wallet)
• Performance is automated and is carried out by the machine, following its programmed instructions
• Smart contracts are immutably recorded and programmed on the distributed ledger and cannot be altered. If
“rectification” is required, a new contract must be written which reverses or modifies the effects of the previous
contract
• A smart contract can only perform in a situation in which there is an “algorithmically determinable solution”. In other
words, there is no room in a smart contract for discretion, reasonableness or judgment: potential outcomes will be
binary in form
Smart contracts, therefore, will only be useful for transactions of a certain type. An obvious example of the type of
transaction to which smart contracts would be well-suited is the transfer of title to assets. Such transactions often take the
form of requiring title to be transferred on the receipt of a certain amount of funds into a particular account, perhaps with
the added requirement of verifying the absence of any charges over the asset.17 According to the logic of machines, this is
simply an action to be performed on the satisfaction of a given condition or set of conditions: ideal for a self-executing
algorithm. Machines are arguably better placed than humans to perform such one-dimensional tasks, since, properly
programmed, they are simply unable to refuse to act, to omit a condition or to fail to perform. Smart contracts offer,
therefore, the potential for reducing transactions costs, defective performance and informational asymmetry between
parties. (The potential for defective performance does not, of course, disappear; it shifts its locus to the coder responsible
for programming the machine, but that is an issue for another time and place.)
Formation: The spectrum of smart contracts in practice
A lawyer and a coder will not necessarily have the same conception of a smart contract. The term “smart contract” was
coined by Nick Szabo, and was defined by him 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”18
This use of the c word would probably not satisfy a lawyer. At the very least however, there will be a subset of those
transactions referred to by users as smart contracts which will also satisfy the legal criteria of enforceable contracts, such
as those which adhere to the legal rules of formation.
There may be more to a smart contract than an independent chunk of self-executing code. At one end of the spectrum, a
conventional natural language contract may include a short section of code that implements a single clause. This is similar
in effect to the inclusion by reference in a contract of a formula or a specific manufacturing design. The Courts have
interpreted these references strictly – requiring them to be followed precisely while simultaneously complying with all
other obligations in the contract, even ones that are apparently contradictory:
“Where a contract contains terms which require an item (i) which is to be produced in accordance with a prescribed
design, and (ii) which, when provided, will comply with prescribed criteria, and literal conformity with the prescribed
design will inevitably result in the product falling short of one or more of the prescribed criteria, it by no means follows
that the two terms are mutually inconsistent”19
The effect appears to be that a counterparty cannot satisfy its obligations merely by executing a piece of code even where
that code is explicitly agreed in the contract. Other contractual terms may be used to show that the counterparty had to
do more. The code provides convenience but not necessarily certainty. The harshness of this approach is illustrated in
Hojgaard v EON, from which the extract above is taken. In a contract to build an offshore wind farm, both parties agreed to
use an international standard for the design of wind turbines. Unknown to them, one formula in the standard contained a
constant with a misplaced decimal point. When the defect came to light, the builder was held liable for breach of
warranties contained elsewhere in the documentation – its exact compliance with the design specification was not
sufficient. Applied to smart contracts, this suggests that a piece of code included in a natural language contract will not be
interpreted in isolation and executing the code may not be sufficient to comply with the contract.
Further along the spectrum is the combination of self-executing code and natural language contract known as the
‘Ricardian contract’20. This consists of a piece of code contained in a DLT which contains a hashed reference to a natural
language contract. As described above, a hash is a cryptographically secure method of creating a reference to a particular
document. Anybody with the natural language document can easily check that it corresponds to the hash in the code. And
changing even a single comma in the document would lead to it producing a completely different hash. So this
mechanism inextricably links the code and the written document into a single agreement. A Ricardian contract could be
used simply to implement the single formula in code considered above. In practice, it is generally employed to supplement
a contract that is primarily smart, by adding a few natural language provisions. Popular options for natural language
clauses ‘bolted on’ to a smart contract in this way include governing law and jurisdiction clauses and dispute resolution
mechanisms.
Furthest along the spectrum is a smart contract that consists only of code and expressly excludes any other language and
all contractual oversight. This is achieved through an apparently paradoxical method. The smart contract includes a
natural language provision stating expressly that it is not a legally enforceable contract: an explicit denial of an intention to
create legal relations. This type of smart contract is for parties who wish to rely entirely on the DLT to carry out their
intentions and to remove any possibility of the legal system stepping in to reverse their immutable transactions. The
motivation for this may be ideological – parties might be transacting on a DLT in order to remove themselves from the
sphere of influence of a particular legal system or to facilitate cross-border commerce when there is no single legal
system to which they will agree to submit. Although it may seem farfetched to lawyers and legal academics, this ideology
is common in the communities from which DLT emerged. Indeed, Bitcoin is often portrayed as a means of payment that is
beyond the reach of legal oversight. Whilst this has led in the past to negative publicity, centred on the technology’s
involvement in criminal activity, it is a fact that many legal systems are expensive, inaccessible or corrupt, and many fiat
currencies subject to bouts of inflation. There are, therefore, legitimate reasons why people seek to exclude the apparatus
of national law. The concept of an intention to create legal relations in the context of smart contracting is examined further
below.
Code as Contract
The technology which makes smart contracts possible, and perhaps more significantly the ethos underlying that
technology, gives rise to a fundamental question: to what extent can and should the law govern smart, peer-to-peer
interaction? The original Blockchain protocol was, after all, created with a view to eschewing conventional third party
intervention and regulation, explicitly substituting a model by which all users participate in complete self-governance.
Although it is neither realistic nor practical to suggest that total internal governance should prevail, given the now
extensive uses made of DLT, a question nonetheless remains about the extent to which those engaging in smart
transactions could expect to have their interactions regulated by the protocol, rather than by external agencies such as
courts, arbitrators and lawyers. Internal regulation and resolution is certainly possible as a result of DLT technology: this
could take the form of coded responses to certain conditions, or a requirement for multi-signature approval for the transfer
of funds. In the latter situation, a third party would need to verify that, for instance, payment conditions had been met
before releasing funds to either party. Such an arrangement could perform the role played in conventional transactions by
escrow or trust arrangements.
In forensic terms, this amounts to a question of whether the parties have demonstrated the necessary intention to create
legal relations. Such an intention is, of course, a prerequisite for an agreement to be the source of legal rights and
obligations and to be enforceable by the Courts. Most problems concerning an intention to create legal relations arise
from an agreement that features a level of informality or vagueness which precludes the Court from applying the
machinery of contract law to it, disappointing one of the parties to the agreement who cannot enforce it. Smart contracts
feature the converse situation: an agreement which is precise and intended to be carried out on commercial terms, but
which the parties nevertheless do not wish to be enforceable through the Courts. The self-executing nature of smart
contracts mean that this is not a contradictory position, but it is one nonetheless that the Courts have not previously
addressed.
Take a Ricardian contract, expressed partly in code and partly in prose, where the wording of the prose section includes a
statement that the parties do not intend the agreement to create legal relations.21 The intuitive starting point is that this
statement is inconsistent with an intention to create legal relations and so no contract is formed. That starting point is not
necessarily correct. The Courts will look at the entirety of the agreement to determine the objective intention of the parties
and they will apply a strong presumption that a commercial arrangement is intended to be legally binding:
“Whether there is a binding contract between the parties and, if so, upon what terms depends upon what they have agreed.
It depends not upon their subjective state of mind, but upon a consideration of what was communicated between them by
words or conduct, and whether that leads objectively to a conclusion that they intended to create legal relations and had
agreed upon all the terms which they regarded or the law requires as essential for the formation of legally binding
relations.”22
Applying this principle, the Supreme Court held that a statement that an agreement was ‘subject to contract’ did not
prevent it from forming a contract when the subsequent conduct of the parties showed that they intended to treat the
terms as binding. In particular, the fact that the operative terms of the agreement were actually carried out by the parties
was a “very relevant factor”23 pointing towards enforceability. The analogy between a ‘subject to contract’ statement and
conduct carrying out the terms of the agreement and a ‘no intention to create legal relations’ statement and self-executing
code that has or will carry out the agreement is a close one. It suggests that the courts, looking at the entirety of the
relationship between the parties, could impose a legally binding contract on a Ricardian smart contract despite an
express statement of lack of intention to create legal relations.
The analogy is not, however, an exact one. ‘Subject to contract’ implies that the parties consider that at some future point
a contract may come into existence and the relevance of conduct is to determine whether that point has been reached. A
straightforward denial of intention to create legal relations makes it harder to imply that intention from later conduct. In
RTS Flexible Systems v Molkerei Alois Muller,24 this was a policy decision for the Court: should the apparatus of legal
enforceability be available to this particular agreement? Where a commercial arrangement had actually been carried out
and the price paid, the Supreme Court was reluctant to deprive the parties of the benefit of this apparatus.
Other similar situations show that the courts tend to grant the parties the benefit of this legal apparatus in commercial
situations. In its most recent consideration of this issue, Wells v Devani,25 the Supreme Court enforced an agreement to
pay an estate agent commission on his successful sale of a block of flats. The express terms of the written agreement
were too vague to be enforceable because the trigger for payment of commission had not been specified. Acting with
some innovation, the Court implied a term into the agreement to resolve this uncertainty and then applied the test of
intention to create legal relations to the agreement including the implied term. There was also an explicit policy element:
estate agent agreements were subject to statutory control and could be unenforceable without proper formalities: the
Court further exercised its discretion to allow the agreement to be enforced.
Other policy-based examples can be provided. One is an express agreement by the parties to submit disputes to
arbitration. This is an ouster only of enforcement by the Courts rather than enforcement generally, yet it is subject to
statutory limitations. Agreements for arbitration for remedies below a fixed sum are deemed unfair by the Arbitration Act
1996.26 Above this sum, an arbitration agreement may still be deemed unfair by the Unfair Terms in Consumer Contracts
Regulations,27 and now the Consumer Rights Act 2015. The unfairness lies in the consumer’s difficulty in obtaining
effective and inexpensive enforcement of their agreement – a policy which would apply equally to smart contracts.
Finally, where parties have used contractual estoppel to restrict their contractual liability, the courts have used statutory
powers to strike this down as an unreasonable exclusion clause. For instance, parties may agree between themselves that
a particular state of affairs exists – such as that neither party has made any representations or relied on the other for
advice – thereby removing potential liability for misrepresentation or negligent advice. The Court of Appeal has carefully
differentiated the ability of parties to do this from the power of the courts to interfere on the basis of policy. It is open to
the parties to agree on a state of affairs and to be bound by it, but this must be subject to statutory control which will be
applied according to its policy, whatever legal formalities parties use to try and avoid it.28
These are no more than broad analogies with the smart contract issues dealt with in this chapter. An intention to avoid all
legal consequences is not the same as an intention to avoid the courts by recourse to arbitration; an intention to exclude
liability in a contract is not the same as an intention to exclude all liability by preventing an agreement from being a
contract. All the policy arguments exhibit a certain circularity: if there is a contract, statutory controls apply and show that
a contract exists; if there is not a contract, then the agreement is outside the scope of these controls and cannot show
that a contract exists. Nevertheless, it is clear from these examples that there are constraints on limiting judicial oversight,
that those constraints are circumscribed by policy considerations, and that attempts artificially to stay outside their
perimeter are often unsuccessful.
The conclusion on this point is that an express statement in the prose section of a Ricardian smart contract that it is not
intended to create legal relations will not automatically prevent a legal contract from being recognised. Whether it will do
so ultimately comes down to fundamental questions of contract law policy. Just as DLT and smart contracts challenge the
existing financial order, they also pose significant challenges to the legal order. Contract law is a centrally available means
of enforcing agreements between parties, without which commercial relations would be either more costly or simply
ineffective. The smart contract ecosystem proposes an alternative – enforcement by external parties made redundant
through automatic execution. Assumption of the benefits and restrictions of contract law as a whole is meant to be
voluntary, as shown by the need for an intention to create legal relations, so why should parties not be able to ignore it
completely? The answer may be that they can. But when there is an imbalance in negotiating powers or one party is
acting fraudulently, or the arrangement is tainted by illegality, it is hard to see the Courts stepping back and pronouncing
themselves powerless.
Before the creation of DLT and smart contracts, the issues in this section would have been purely theoretical. It would
have been nonsensical to enter into a commercial transaction and simultaneously remove all hope of legal enforcement.
Smart contracts offer an alternative: a commercial transaction that enforces itself. Whether the law still has a role to play is
a question that courts will at some point have to address.
Interpretation
For current purposes, what is important is that the smart contract, as programmed, will be performed on the satisfaction
of a given condition or set of conditions. This means that the space between the formation and the performance of smart
contracts is vanishingly small. Given that most conventional contract claims are about performance, this represents a
major difference in the adjudicative requirements of each type of contract. Smart contracts are less like exchanged
promises than they are like promised exchanges. The expectations of smart contracting parties are more likely to be
frustrated by the wrong thing happening rather than by nothing happening at all. For those smart agreements that are
deemed to be enforceable, therefore, the next legal question that will arise most often is not whether performance can be
enforced but whether the outcome that has already occurred is a just one. It is almost as if smart contracts need a back-
to-front legal contractual analysis, in which enforcement yields to correction.
Smart contracts do not only make interpretation harder – they also call into question the very concept of interpretation, as
it is currently understood. As discussed above, interpretation is the process of divining the meaning that the parties
intended from the words that they used. Meaning is used here in a specific way. It does not refer to all and any objective
meaning that may be taken from any passage of prose. Only the part of the meaning that creates legal rights and
obligations is relevant and a large part of this meaning corresponds to the list of actions that the text imposes on each
party. Specifically, the process of contractual interpretation determines the actions that each party will undertake. Legal
rights and obligations are created that correspond to these actions. In other words, the parties are legally obliged to do
what they promise they are going to do. As the Supreme Court put it, the task is to “ascertain the objective meaning of the
language which the parties have used to express their agreement”.29 It is the meaning of ‘their agreement’, what they have
promised to do, which is the focus.
Contrast this with an agreement concluded by conduct: it can be as simple as the purchase of an item in a shop, an
exchange of the item for cash. There is effectively no room for interpretation as to the key promises entered into by each
party. The promise of the buyer is to hand over the amount of cash which he actually hands over; the promise of the seller
is to hand over the item which she actually hands over. The contract attaches to the actions of the parties rather than to
their words. The actions necessarily coincide with the obligations that they undertake.
Smart contracts created entirely in code behave more like conduct than words. The words of the code are, in themselves,
actions. They are performative utterances, like the words ‘I do’ in a marriage ceremony. They actually have an effect on the
real world, not through interpretation of their meaning, but directly. In the same way, code, when it is part of a distributed
ledger, acts directly on the world through its execution without any medium of interpretation. To work out what a piece of
code means, you do not read it, you run it. There is no room for doubt that the legal rights and obligations intended to be
created correspond to the actions undertaken by the code; the code is no more than those actions set down in frozen
form. The obligations coincide with the code in the same way that the obligations coincide with the conduct in a contract
entered into by conduct. Interpretation appears in this context to be superfluous.
This chain of reasoning is part of the sentiment encapsulated in the slogan ‘the code is the contract’. Often heard in the
smart contract community, this refers to a stance as much political as legal, in which all enforcement by the courts, not
just the doctrine of interpretation, is rejected Rendered into a legal argument, it has some force when limited to the
potential superfluity of interpretation but is unconvincing as an overall attempt to oust legal oversight. It ignores vitiating
factors in agreements, such as fraud and illegality, and it ignores statutory and general policy controls on voluntary
agreements. Even restricted to interpretation, it ignores the fact that most agreements will contain both code and prose.
They may be expressed as Ricardian contracts or they may take effect within the context of an existing commercial
relationship, with numerous other documents, emails and actions forming part of the factual-matrix within which to
interpret the agreement. Additionally, a piece of code requires a platform on which to run. This platform includes software
intrinsic to the particular blockchain, extending from interfaces seen by the user through to the plumbing that underlies
the system. And it extends to other software that the platform interacts with, such as third-party information providers and
cloud-based storage. It is impossible to model and to predict all of these interactions, not least because many depend on
real-time constraints. Characterising code as freestanding, self-executing pieces of frozen conduct ignores these
interactions and dependencies.
Despite these difficulties, ‘the code is the contract’ ethos illustrates how smart contracts can circumvent both
interpretation and enforcement as forms of writing that act on the real world via DLT. It is a slogan that should serve as a
warning to the legal community. Legal practitioners and courts will have to determine how, and whether, legal doctrines
such as interpretation are relevant to smart contracts.
In those instances in which judicial interpretation does become relevant to smart contracts, (where, for instance, the
code’s operation is said by one of the parties not to have done what it was intended to do), it will be one of the thorniest
problems for the legal treatment of smart contracts.30 It also has implications for parties’ freedom of contract. As
established above, the content of the code will dictate what outcome the computer achieves. The content of the code,
however, as with the written form of a conventional agreement, might not mirror the substance of the parties’ agreement.
Whilst this is a common problem for conventional contracts, it is even more complicated where smart contracts are
concerned. When an agreement is put into computer code, an extra layer of interpretative difficulty is introduced: the
person coding the contract might not be one of the parties to it, and so might misunderstand the instructions. Even if she
does understand them, she might make an error transposing them into code. This means that the code will not execute in
accordance with the parties’ agreement, and this is where a court will need to decide how to resolve the dispute.
Conventional contracts produce fiendishly difficult interpretation problems because of the many ways in which human
language can be used and understood. But these multiple possible meanings do not exist for artificial intelligence. As
Susskind says, computers are ‘non-thinking, high-performing’ agents.31 From the perspective of the computer performing
a smart contract, therefore, there is no room for interpretation, and the instructions presented to it have a single meaning.
The potential meanings to both its authors and interested third parties, however, are several. The forensic process of
interpretation in this sphere is therefore likely to be much more complicated than it is in the conventional context. The
broad linguistic symmetry of conventional contracting, in which the authors of the agreement, along with any third parties,
use the same basic lexicon,32 is absent in this context: computer code is qualitatively different to human language. A
human reading of code, therefore, will be of limited assistance in determining the intended effect of language directed
towards an artificial intelligence. Whilst human-to-human interaction is open to conflicting interpretations on both sides,
human-tomachine interaction will only have multiple meanings to those choosing the language to be used, and not to the
recipient of that language. Whilst a computer will do what it is told, however, this does not of course mean that it will do
what the parties intended. And as Lewison LJ has made clear, the task of the court is ‘not … to ascertain ‘what the parties
intended to agree’ but what the instrument means.’33
Since there is no such thing as a reasonable computer, there is no point in approaching the interpretative exercise in
relation to smart contracts by asking what a reasonable machine, or a reasonable user of human language would make of
the language used. The task is made more difficult because, despite the growing numbers of individuals proficient in
computer code, it remains the case that most people would not know what such code would mean to the machine for
which it was intended. Outside of the specialist field, this is not (yet) a subject of general knowledge.34
Technical interpretation problems are not in themselves a novel issue. The common law has, for instance, developed a
means of dealing with contracts whose terms have an industry-specific contextual meaning, and with those written in a
human language unfamiliar to the court: it simply admits expert translation evidence:
A judge is supposed to know the law, the English language and such facts as are common knowledge. If he refers to
authorities or dictionaries or other works dealing with these matters he can safely do so because his general
knowledge enables him to check and appreciate them. But if without assistance he attempts to handle highly
technical matters he may easily go astray. Some fairly simple technical matters can nowadays be considered to be
common knowledge, and I would not attempt to draw the line—it may alter from time to time. In this case some of the
terms are simple enough but some are certainly not. So what is a court to do if on the face of a record there are
technical terms which cannot be understood without expert assistance? There may be cases where a very little
assistance is all that is necessary, and I think it would be unfortunate if such a strict rule were laid down that the
mere presence of some technicality is enough to prevent a court from proceeding further in the absence of evidence
to explain it.35
The same approach cannot, however, be transposed for use in relation to interpreting smart contracts (or smart elements
of prose contracts) because code does not use a lexicon that is necessarily common to both parties. Whilst certainly the
machine itself, and any humans familiar with coding, will understand the language used,36 those who agreed the
substance of the contract may well not be able to follow it at all, were they ever even to see it.37 Interpreting the code
through reference simply by referring to a code lexicon, could easily fail to address the issue of what the contracting
parties agreed to (particularly if neither party is herself familiar with code because, say, a third party code wrote the text).
The code lexicon would be a guide only to the coder’s intention, but does not get to the root of the interpretative issue:
When the language used in an instrument gives rise to difficulties of construction, the process of interpretation does
not require one to formulate some alternative form of words which approximates as closely as possible to that of the
parties. It is to decide what a reasonable person would have understood the parties to have meant by using the
language which they did.38
This highlights the tension between English law’s objective approach to contractual interpretation39 and its regard for the
intentions of the contracting parties. The objective approach reduces the threat of uncertainty,40 and provides a means of
dealing with a court’s obvious inability to read individuals’ minds. The benefit of such an objective approach stems from
its universality; it promotes certainty because it provides a means external to the parties of deciding what their words
mean but, whilst being external, remains accessible to them so that they have the opportunity to gauge how their words
will be interpreted. Again, however, this cannot simply be carried across to the smart contract sphere because of the
linguistic asymmetry just described.
Coders, however, can bridge this gap with their ability to understand both human and machine language. Enlisting the
services of such an expert in order to represent to the court what the machine in question had been required by the smart
contract code to do is on one level little different to employing the services of a human language translator, as is standard
practice where contracts are written in a foreign language.41 The difference as far as code is concerned lies in the court’s
actions following that translation.
In principle, where a document has been translated, its proper interpretation is a matter for the court, and not a
proper subject of expert evidence.42
As explained above, however, understanding machine language is not simply a question of translating directly the terms
used. The syntax and logical architecture of code is such that, without knowing the context of its initial design objectives,
a literal translation of code into English is unlikely to be amenable to effective interpretation by anyone unfamiliar with the
conceptual organisation of machine instructions. This presents yet another challenge to current forensic practice:
Although expert evidence may be necessary to explain technical terms to the court, it is not the function of an expert to
interpret the contract. That remains the function of the judge.43
But a judge unfamiliar with code might not find it easy to fulfill this particular function. To illustrate the different cognitive
responses of humans and machines to language, take as a very basic example the following instructions:
‘Go to the shop and buy a newspaper. If there any eggs, get a dozen.’
The most likely human response to this instruction is to buy a newspaper and, in the event that the shop has eggs, to buy
a dozen eggs as well. A computer, on the other hand, presented with this instruction,44 would buy a newspaper and, in the
event that eggs are also available, will buy 12 newspapers rather than one. In response to this instruction, it will not buy a
dozen eggs because at no point has it been told to purchase eggs; the only object of the ‘buy’ mandate is a newspaper.
Were a court to consider these instructions, and know that they have been issued to a human agent, there is certainly
scope for considering more than one intended outcome45 (either the purchase of one newspaper plus one dozen eggs or
the purchase of a dozen newspapers) as being reasonable. Whilst the purchasing of a dozen newspapers by a human
agent does not seem immediately reasonable to most adults with a standard social experience, there might be something
in the context of the parties’ relationship, history or knowledge which renders it so on a particular set of facts.46 The point
is that there is a valid question to be asked about the meaning conveyed by these words to human intelligence, but the
question of interpretation simply does not arise when considering a computer’s response.
Clearly, where computer code is concerned, therefore, it is not so much the meaning or use of individual words which is
likely to give rise to interpretative difficulties,47 but the way in which those words are combined to form instructions. In
order to be forensically effective, therefore, expert code evidence would have to do more than explain the meaning of
individual terms: it would have to go further by explaining what effect certain combinations and juxtapositions of words
will have on the artificial intelligence to which they are addressed. The extent to which any court engaging in such an
exercise is able successfully to align its interpretation of a smart contract with the agreement actually made by the parties
will therefore determine the scope of those parties’ freedom of contract. Whilst this is true even of conventional
interpretation exercises, the additional layer of potential misalignment in smart contracting is bound to present greater
challenges to the objective of giving effect to parties’ intentions.
Concluding Remarks
The issues dealt with above do not exhaust the forensic difficulties posed by smart contracts. Even where a court has
deemed a smart contract to be the proper subject of judicial intervention (because, for instance, the requirements for
contract formation have been met and a court is persuaded that the parties had the requisite intention to create legal
relations), there remains the significant question of what the remedial response to the dispute should be. The particular
difficulty here is that the objective of Nick Szabo’s smart contract was to create “immutable unstoppable and irrefutable
computer code” which can “self-enforce”.48 This has interesting implications for the ability of the court to fashion an
appropriate remedy, particularly in situations in which ongoing performance is a feature of the contract. Where the
obligations under the contract are of the one-off, discrete variety,49 and have produced an outcome with which at least
one of the parties is disappointed, the situation can be remedied by the granting of a conventional remedy, external to the
digital world, such as conventional compensatory damages or restitution.50 Where, however, the agreement is one under
which obligations are continuous, something needs to be done to the contract itself in order to ensure that future
performance conforms to expectations. Where, for instance, a court determines that the coding of a smart contract does
not match the parties’ manifest agreement, this looks like a job for rectification. Rectification is not, however, possible in
any real sense because a smart contract, being immutable, cannot be rectified. A court-ordered variation of such an
outcome51 will therefore require the creation of a new smart contract to reverse or modify the effect of the first.52 This
looks more like novation than it does rectification, and perhaps points to a future in which the former remedy plays a
greater role in resolving contractual disputes than it has done in the past. Historically, and for reasons which are obvious
in relation to conventional contracts,53 novation has been used primarily to substitute new for existing contracting parties.
In the digital age, its remit may well expand so as to facilitate the modification of content currently dealt with by
rectification.
These are big questions and require fuller analysis than is possible here. The fact that they need to be asked, however,
lends weight to the argument advanced in this chapter that the ability of smart contracts to meet commercial expectations
will depend on the extent to which the common law is prepared to adapt some of its long-established methods and
responses to an age in which promises yield to performance.
Footnotes
1 University of Bristol
2 Norton Rose Fulbright LLP
3 Which is distributed ledger technology or DLT, explained below.
4 H Diedrich, Ethereuem (Wildfire Publishing, 2016), 113.
5 For a more detailed and technical description of this, see A Narayanan, J Bonneau, E Felten, A Miller and S Goldfeder, Bitcoin and Cryptocurrency
Technologies: A Comprehensive Introduction (Princeton University Press, Princeton,2016), 28-50.
6 Around $300 million dollars a year on Bitcoin alone, which is comparable to the annual electricity bill for the
whole of Ireland. See H Diedrich, Ethereum (Wildfire Publishing, 2016), 150.
7 In the Bitcoin protocol, the hash function takes an input of any length and always produces an output of a fixed
length.
8 For present purposes, the substantive content of the text being hashed is irrelevant.
9 H Diedrich, Ethereuem, 106-7. Although, as Diedrich makes clear, it is theoretically, if not practically, possible to find another text which results into exactly
this hash. This practical impossibility is considered to provide sufficient security.
10 This means, for example, that Alice has purported to transfer a certain amount of bitcoin to Bob by entering the details of his public key (which functions
rather like an email address) and issuing instructions for the network to transfer that amount from her stock of bitcoin to his. It would be foolhardy, however,
for any payee to trust the integrity of any transaction at this stage because it has not yet been validated or added to the block chain.
11
And, by definition, the previous block will be similarly linked to all the blocks preceding it.
12
“Adding” here takes the form of concatenation of data strings.
13
The “correct” number is dictated by the protocol and it doesn’t matter what it is – it is just a test for the nodes to prove the work they have done.
14 Diedrich, 149.
15 To a certain extent anyway. There is a possibility of forking.
16 There is, however, only a finite number of bitcoin available: 21 million.
17 Mischcon de Reya and HM Land Registry have very recently (April 2019) trialled the UK’s first end-to-end residential property transactions.
18 http://szabo.best.vwh.net/smart.contracts.html
19 Hojgaard v EON [2017] UKSC 59, para. 44, per Lord Neuberger
20 I. Grigg. The Ricardian Contract. In Proceedings of the First IEEE International Workshop on Electronic Contracting, pages 25-31. IEEE, 2004
21 Where the smart contract does not contain an express denial of an intention to create legal relations, the Courts could still consider whether a lack of
intention is implied by the conduct of the parties. Here, the presumption that commercial parties intend to create legal relations while weigh heavily. Only if
the transaction takes place in a market where lack of intention to create legal relations is a sustained and universal principle might this implication be
satisfied. It is possible that one day DLT will constitute such a market.
22 RTS Flexible Systems v Molkerei Alois Muller [2010] UKSC 14
23 Ibid., para. 54
24 Above, fn 20.
25 [2019] UKSC 4
26 Arbitration Act 1996, s.91
27 As occurred in Mylcrist Builders v Buck [2009] 2 All ER (Comm) 259
28
See First Tower Trustees v CDS [2018] EWCA Civ 1396, considering the anti-exclusion provisions of s.3 of the Misrepresentation Act 1967 in relation to such
a clause, commonly labelled a ‘basis clause’: “Section 3 of the 1967 Act must be interpreted so as to give effect to its evident policy.” Per Leggatt LJ, para. 51
29
Wood v Capita [2017] UKSC 24, para. 13, per Lord Hodge
30
For a fuller analysis, see S Green, ‘Smart Contracts, Interpretation and Rectification’, (2018) Lloyds Maritime and Commercial Law Quarterly 24
31
R Susskind and D Susskind, The Future of the Professions: How Technology Will Transform the Work of Human Experts (OUP, 2015), 276.
32
That is not to suggest that this is the only source of linguistic gulfs in the law of contract. Both standard form and industry-specific agreements can,
particularly as against consumers, employ language which is drastically different from that with which the intended audience is familiar. It is certainly
arguable that the courts require a bespoke interpretative approach in those circumstances as well.
33
Cherry Tree Ltd v Landmain Ltd [2013] Ch 305 at [99] (emphasis added).
34
Although, with coding now a subject widely taught in schools, it is a problem which might disappear in a few decades’ time.
35
Lord Reid in Baldwin & Francis Ltd v Patents Appeal Tribunal [1959] AC 663, 684.
36
Although, with highly complex code, even proficient coders might, without practical testing of the code, have their own different predictions of precisely
what it will achieve in practice.
37
And in practice, they often will not ask to see it. See also Leggatt, supra n 30, 462.
38
Lord Hoffmann in Chartbrook Ltd v Persimmon Homes Ltd [2009] AC 1101 at [21].
39
J Steyn, “Contract Law: fulfilling the reasonable expectations of honest men” (1997) 113 LQR 433, 433-434.
40 See, eg, Lord Hodge JSC in Wood v Capita Insurance Services Ltd [2017] 2 WLR. 1095 at [15]: “One of the
attractions of English law as a legal system of choice in commercial matters is its stability and continuity, particularly
in contractual interpretation” and R Buxton, ‘‘‘Construction’ and Rectification after Chartbrook’ (2010) CLJ 253, 261.
41 See Sir K Lewison, The Interpretation of Contracts (Sweet & Maxwell, 6th edn) Main Work, 5-06.
42 Lewison, ibid, 5-06.
43 Lewison, ibid, 5-06.
44 This is, of course, a translation of a machine instruction into human language. The point is merely to illustrate how the same given instruction will have
one meaning to a machine, and more than one meaning to humans.
45 In the event that eggs are available. If there are no eggs, both humans (most probably) and computers (definitely) would buy just a newspaper.
46 Say, for instance, there has been a salmonella scandal in relation to eggs and there has been an exclusive report in the local newspaper, urging people
not to buy them. If the parties to this contract owned a holiday resort, it would make sense for them to distribute those newspapers to their residents.
47 Although it may well be that several technical terms, with meanings specific to context, are used.
48 L D Wall, ‘“Smart Contracts” in a Complex World’ (Federal Reserve Bank of Atlanta, 2016)
https://www.frbatlanta.org:443/cenfis/publications/notesfromthevault/1607
49 As explained above, automated execution means that parties to smart contracts are very unlikely to need to bring claims for non-performance (except
where any pre-performance conditions have been fulfilled and/or where one party has in some way prevented the code from executing), but are more likely
to dispute the outcome of executed performance.
50 Or even specific performance. Whilst smart contracts will be performed as coded, their execution will still rely on the satisfaction of certain conditions or
requirements. There remains scope, therefore, for the fulfilment of these conditions to be mandated, thereby achieving specific performance of the contract.
51 Presuming the parties wish to continue with automated performance and/or where the obligations in question can only be performed in this manner.
52 Such variation can of course occur simply as a result of the parties’ mutual decision-making.
53
Since a conventional prose contract can be rectified, there is no need to create a new one in order to its modify content.
Contact
Adam Sanitt
Head of Disputes Knowledge,
Innovation and Business
Support, Europe, Middle East
and Asia
Email
London
T: +44 20 7444 2269
Practice areas:
Tech sector FinTech
Industry:
Financial institutions
© Norton Rose Fulbright LLP 2023

Smart Contracts - South Africa - Global Law Firm - Norton Rose Fulbright

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Smart Contracts - South Africa - Global Law Firm - Norton Rose Fulbright

Uploaded by

Copyright:

Available Formats

9/10/23, 4:00 PM Smart Contracts | South Africa | Global law firm | Norton Rose Fulbright

Global | Publication | November 2019

What is a smart contract?

Formation: The spectrum of smart contracts in practice

Decentralisation and Distributed Consensus

The transaction data must have been generated by an honest node5

has the MD5 hash:

2 Norton Rose Fulbright LLP

3 Which is distributed ledger technology or DLT, explained below.

4 H Diedrich, Ethereuem (Wildfire Publishing, 2016), 113.

15 To a certain extent anyway. There is a possibility of forking.

16 There is, however, only a finite number of bitcoin available: 21 million.

22 RTS Flexible Systems v Molkerei Alois Muller [2010] UKSC 14

26 Arbitration Act 1996, s.91

27 As occurred in Mylcrist Builders v Buck [2009] 2 All ER (Comm) 259

42 Lewison, ibid, 5-06.

43 Lewison, ibid, 5-06.

© Norton Rose Fulbright LLP 2023

You might also like