Smart Contracts: (How) Do They Fit Under Existing Legal Frameworks?

Jelena Madir
A. Introduction
The term “smart contract” has entered the public consciousness following the rise to
mainstream awareness of distributed ledger technology (DLT). The first thing many people
think of when they hear the term “smart contract” is a contract that is somehow transposed
into computer code and runs without any human intervention. This misses the mark by a
wide margin. Instead, smart contracts are better thought of as “conditional transactions”
because they refer to the logic written in code that has “IF this, THEN that” conditions. For
example, it can easily be programmed in a smart contract that “IF on 1 October 2020, Bank A
does not receive GBP 1,000 from Jack, transfer GBP 1,000 from Jack’s account to Bank A’s
account.”

Smart contracts have the potential to increase commercial efficiency, lower

transaction and legal costs, and increase transparency. They have a number of potential
applications from the automatic payment of dividends, property transfers and automation of
insurance claims to streamlining of clinical trials and more efficient data sharing. The US
Chamber of Digital Commerce’s report illustrates 12 possible use cases of smart contracts in
different industries.1 However, smart contracts also pose a number of challenges, starting
from finding a suitable definition of a smart contract to the uncertainties around contract
formation and allocation of liability in case of errors. This Chapter will consider these
challenges and whether they can be addressed within existing legal frameworks as follows:
Sections B-D define, and describe different types of, smart contracts and automatability of
contractual clauses. Sections E-L analyse legal issues related to smart contracts – from the
existence of a valid and binding contract and capacity to enter into a contract to the allocation
of liability and governing law and dispute resolution mechanisms. Section M concludes.
B. What are smart contracts?
Nick Szabo is widely credited for inventing the idea of a smart contract long before
the emergence of DLT. In his article on smart contracts, he defines the term as “a
computerized transaction protocol that executes the terms of a contract.”2 He gives an
example of a drinks vending machine as something embodying these characteristics: if the
correct coins are inserted into the slot, tip the bottle into the trough; if there are no bottles,
return the coins. The transaction cannot be stopped in mid-flow. The money cannot be
returned when the drink is supplied. The transaction’s terms are in a sense embedded in the
hardware and in the software that runs the machine.3

1
Chamber of Digital Commerce: Smart Contracts: 12 Use Cases for Business & Beyond A Technology, Legal
& Regulatory Introduction, available at: https://digitalchamber.org/wp-content/uploads/2018/02/Smart-
Contracts-12-Use-Cases-for-Business-and-Beyond_Chamber-of-Digital-Commerce.pdf.
2
Nick Szabo: Smart Contracts (1994), available at:
http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo
.best.vwh.net/smart.contracts.html.
3
Nick Szabo: Smart Contracts: Building Blocks for Digital Markets (1996), available at:
http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo
.best.vwh.net/smart_contracts_2.html.

Electronic copy available at: https://ssrn.com/abstract=3301463

 While smart contracts can exist entirely independently of DLT, with the advent of
DLT, smart contracts can now be applied more efficiently between market participants
around the world. Unlike in the case of a vending machine, a smart contract can be effected
without the physical presence of a person. Instead, parties can agree remotely on the
computer code of the smart contract, programme it on the distributed ledger and then allow
the ledger to execute automatically when the triggering event happens. This has the potential
to reduce friction when transferring value between entities and opens the door to greater
automation of transactions.
There is not yet a widely accepted legal definition of smart contract. For some, a
“smart contract” does not refer to a contract in a legal sense, but instead to a computer code
that automates business processes without the need for recourse to the courts of law to
resolve disputes – this is the so-called “smart contract code.” For example, several states in
the United States have enacted legislation specific to smart contracts, which may not be so
smart after all, given that it risks creating a patchwork system of inconsistent definitions,
leading to further confusion. For example, in the State of Arizona, a smart contract is defined
as:
“an event-driven program, with state, that runs on a distributed, decentralized, shared
and replicated ledger and that can take custody over and instruct transfer of assets on that
ledger.”4
The State of Tennessee modified and expanded on this definition, and defined smart
contract as:
“an event-driven computer program, that executes on an electronic, distributed,
decentralized, shared, and replicated ledger that is used to automate transactions, including,
but not limited to, transactions that:
(A) Take custody over and instruct transfer of assets on that ledger;
(B) Create and distribute electronic assets;
(C) Synchronize information; or
(D) Manage identity and user access to software applications.”5
Outside the United States, in 2017, Belarus became the first country to legislate the smart
contract, defining it in the Presidential Decree as:
“a programme code intended for functioning in the distributed ledger for purposes of
automated performance and/or execution of transactions or performance of other legal
actions.”6
Interestingly, the Decree establishes a rebuttable presumption that a person who entered into
a transaction with the use of smart contract is deemed to be fully familiar with the terms of
the transaction, including those reflected in the smart contract.

4
Ariz. Rev. Stat. Ann § 44-7061(E)(2) (2017).
5
State of Tennessee, Public Chapter No. 591, Senate Bill No. 1662, 47-10-201(2) (2018).
6
Decree of the President of the Republic of Belarus No. 8 (21 December 2017), unofficial translation.

Electronic copy available at: https://ssrn.com/abstract=3301463

 Yet, for others, a “smart contract” is a legal contract that is partly or wholly
represented and/or performed by software. In other words, the contractual obligations of a
party to the contract are discharged through the automated performance of the software. In
this Chapter, references to “smart contracts” are intended as references to smart legal
contracts, rather than smart contract code.
These distinctions between smart contract code and smart legal contract can cause
confusion when smart contracts are discussed, and there is a risk that lawyers and computer
scientists simply talk at cross purposes. However, rather than viewing smart legal contracts
and smart contract code as two separate concepts, the reality is that there is a relationship
between them: for a smart legal contract to be implemented, it will need to embed one or
more pieces of code designed to execute certain tasks if predefined conditions are met – that
is, pieces of smart contract code. Smart legal contracts, therefore, are functionally made up
of pieces of smart contract code, but critically, under the umbrella of an overall relationship
that creates legally enforceable rights. As a result, every smart legal contract can be said to
contain one or more pieces of smart contract code, but not every piece of smart contract code
comprises a smart legal contract.7
Taking into account both basic concepts and emphasising the aspects of automation
and enforceability, some authors have defined smart contracts as follows:
“A smart contract is an automatable and enforceable agreement. Automatable by
computer, although some parts may require human input and control. Enforceable either by
legal enforcement of rights and obligations or via temper-proof execution of computer
code.”8
Simply put: A smart contract is an agreement whose execution is automated. This
definition has the advantage that it is broad enough to cover both smart legal contracts and
smart contract code. It captures what seems to be the fundamental essence of all conceptions
of smart contracts: the automation and self-execution (and thereby enforcement) of a pre-set
conditional action.
It is important to note, however, that smart contracts are not artificially intelligent or
capable of machine learning. They are designed to bring about a particular outcome every
time a specific set of conditions is fulfilled. As such, they are suitable for binary "if this, then
that" conditions. Once a condition is met, the smart contract will take the next step necessary
to execute the contract. For example, smart contracts would be ideal for parametric insurance,
where payment is made upon the occurrence of a triggering event. In the event that your
plane is delayed by a certain amount of time, or an earthquake reaches a particular
magnitude, you will automatically receive payment instead of having to go through a lengthy
claims process.

7
ISDA and Linklaters: Whitepaper: Smart Contracts and Distributed Ledger – A Legal Perspective (2017), at
4-5.
8
Christopher D. Clack, Vikram A. Bakshi and Lee Braine: Smart Contract Templates: foundations, design
landscape and research directions (2017), available at: https://arxiv.org/pdf/1608.00771.pdf, at 2.

Electronic copy available at: https://ssrn.com/abstract=3301463

 C. Automatability of contractual clauses
Not all of smart contract needs to be expressed in code. In fact, as the technology
stands, smart contracts are unlikely to be able to encode the subtlety and richness of contracts
written in natural language which contain legal phrases whose meaning may not be settled at
law. This is because computer code (like mathematics) is well adapted to represent terms
which are expressions of logic, but not terms which are based on the exercise of discretion
that is outside of clearly defined parameters, such as, for example, “material adverse change”,
“best endeavours”, “reasonable endeavours”, “commercially reasonable manner”, etc. These
formulations involve judgment and are a question of degree. For instance, code could be
used to represent the agreement that, if an event happened, the price will be adjusted by
subtracting the product of x and y. However, it is unlikely that code can be used to represent
that, if an event happened, the price is to be adjusted by the party in a commercially
reasonable manner.
Smart contracts are therefore particularly effective for sectors that operate using
highly standardised contractual terms without material deviation, and lend themselves well to
agreements with clear conditions and repetitive transactions. For example, in the financial
services sector, a loan agreement could be encoded so that the software automatically triggers
a monthly loan repayment when the software receives an input confirming that it is the last
day of the calendar month (i.e., without the need for human intervention or instruction) or so
that the software automatically changes the monthly repayment amount where it receives an
input confirming that there has been a reduction in the relevant reference interest rate (e.g., a
central bank interest rate) – in each case the conditions can be objectively determined.

This is illustrated in Figure 1 below: Parties A and B enter into a smart loan contract.
The software is programmed to receive inputs from trusted data sources via an oracle and to
automatically generate payment instructions based on those inputs, in accordance with the
terms of the smart contract. When the smart contract receives an input that it is the last day
of the month, it uses the interest rate input to calculate the correct monthly repayment amount
under the smart loan contract. Then, the software automatically sends an electronic
instruction to Party A’s bank to transfer this amount from Party A’s bank account to Party
B’s bank account. Party A’s bank acts on the automatically generated instruction and
transfers the payment to Party B’s account.9

9
Clifford Chance and European Bank for Reconstruction and Development: Smart Contracts – Legal
Framework and Proposed Guidelines for Lawmakers (September 2018), available at:
www.ebrd.com/documents/pdf-smart-contracts-legal-framework-and-proposed-guidelines-for-lawmakers.pdf, at
at 9-10.

Electronic copy available at: https://ssrn.com/abstract=3301463

Figure 1: Smart loan contract
Source: Clifford Chance and European Bank for Reconstruction and Development: Smart Contracts – Legal
Framework and Proposed Guidelines for Lawmakers

Another example could entail the sale of a house on the blockchain: For instance,
after the buyer and the seller have executed the sale agreement, the buyer transfers the deposit
amount to be held in escrow by the smart contract. In turn, and immediately prior to
settlement, the lender can also send the loan amount to the smart contract escrow. After the
total purchase price is sent to the smart contract escrow, the seller may finalise the transfer
and trigger the smart contract to disburse the funds to its account and transfer the tokenised
house to the buyer. The transfer is recorded on the blockchain and the state of title ownership
is updated. There are a few key critical assumptions in this example: First, the house has
been tokenised, which means that a blockchain token has been associated with the house.
Despite media headlines about house sales on the blockchain, 10 there are a number of legal
and technical challenges that need to be overcome for this to happen. Second, the transaction
does not involve anything more than a simple transfer of property, free from encumbrances,
between two parties. This is not often the case in practice.

Clearly, the potential applications for smart contracts are manifold. Although it
remains to be seen which applications will take off in practice, the sheer potential increases
the relevance of the question of how smart contracts are to be treated in legal practice and
which problems may arise in this context.
D. Different types of smart contracts
It is a common misconception that there is only one type of smart contract. In fact,
there is a spectrum of possibilities. As illustrated in Figure 2 below, the text of the contract
may or may not be drafted in computer code. There can therefore be a contract which is (in
whole or in part) written in a programming language, where the computer code forms an
10
See, e.g., The First House To Be Sold Entirely Through Blockchain (October 2017), available at:
https://www.leaprate.com/cryptocurrency/blockchain/first-house-sold-entirely-blockchain/, and UK’s first
blockchain property purchase recorded in Manchester (March 2018), available at:
https://www.buyassociation.co.uk/2018/03/19/uks-first-blockchain-property-purchase-recorded-in-manchester/.

Electronic copy available at: https://ssrn.com/abstract=3301463

integral and binding part of the contract – i.e., some or all of the parties’ rights and
obligations are expressed in a programming language, rather than a natural language. For
example, an agreement between Part A and Party B that Party A will transfer an asset to Party
B at 10:00 am, might be agreed in computer code as follows:
If T= 10:00 CET, Execute Function: AssetTransfer X (Y to Z).
T= Time
X = Asset
Y = Party A
Z = Party B11
At the other end of the spectrum, a smart contract could be drafted entirely in natural
language, but include an agreement between the parties to use specific software to perform
and/or enforce (the whole or pars of) the contract. For example, a company and an insurer
may agree to use the insurer’s automated claims-handling software. The software would
review and determine claims made by the company might even automatically instruct
payments to be made in respect of determined claims.12

Figure 2: Smart contract models based on the level of integration of the computer code
Source: Chamber of Digital Commerce: Smart Contracts: 12 Use Cases for Business & Beyond A Technology,
Legal & Regulatory Introduction

E. Existence of a valid and binding contract

Smart contracts are essentially a slightly new form of an old phenomenon – insofar as
the “new” features of smart contracts – e.g., their expression via computer code – fall within

11
Clifford Chance and European Bank for Reconstruction and Development, supra note 9, at 12.
12
Ibid., at 13.

Electronic copy available at: https://ssrn.com/abstract=3301463

gaps in existing laws, it may be necessary to determine how to fill these gaps. As noted in
Section II above, while certain jurisdictions have enacted legislation specific to smart
contracts, there is no consistent set of laws for smart contracts. Perhaps none is needed if
smart contracts are simply contracts being formed another way.
Under most common law jurisdictions, the following four elements need to be present
for a contract to exist in the legal sense: (i) offer and acceptance, (ii) consideration, (iii)
intention to create legal relations, and (iv) certainty of terms. Civil law jurisdictions may
prescribe other requirements. For example, under German law, parties need to have an
intention to create a legally binding relationship (expressed through and offer and
acceptance),13 and “essential terms” must be determined or sufficiently determinable.14 For
instance, in a car purchase, the “essential terms” might be the identity of the seller and the
purchaser, the obligation of the seller to transfer to the purchaser the ownership rights in a
specific car (along with the car itself) and the obligations of the purchaser to pay a specific
purchase price and to accept the transfer by the seller. Under Spanish law, there need to be
(i) consent through an offer and acceptance, (ii) object of the obligation, which must be
determined or determinable (similar to the “essential terms”), and (iii) cause of the obligation
(similar to consideration).15 French law has similar requirements.16
(i) Offer and acceptance
Under both English and US law, smart contract code used on a distributed ledger
would likely constitute an offer if other participants on the ledger are entitled to interact with
and execute on the code. Under English law, e-mail messages are considered to be capable of
constituting offers and acceptances.17 Smart contracts are typically initiated by messages
sent using PKI over the internet. It would be surprising if English courts were to draw
conceptual distinctions between such messages and email communications.18 Under US law,
“[a]n offer is an expression by one party of his assent to certain definite terms, provided that
the other party involved in the bargaining transaction will likely express his assent to the
identically same terms.”19 Smart contract code used on a distributed ledger is therefore likely
to constitute an offer if other participants on the ledger are entitled to interact with, and
execute, the code.
Acceptance requires both an agreement by the counterparty to the substantive terms of
the contract and an action by the counterparty to accept these terms within the time period
and by the procedure required by the offer.20 In the case of smart contracts, the offeree (or, in
the case of a smart contract simply posted on a public ledger, any participant in the ledger)
may indicate acceptance through signing the transaction with a private key. Signing the

13
Bürgerlichen Gesetzbuch §145 et seq.
14
Ibid., §154(1).
15
Código Civil, § 1261.
16
Code Civil, §1108.
17
See, e.g., Golden Ocean Group Ltd v Salgaocar Mining Industries Pvt Ltd and Anr, [2012] EWCA Civ 265
18
R3 and Norton Rose White Paper: Can smart contracts be legally binding contracts?, at 22.
19
Arthur L. Corbin et al.: Corbin on Contracts: 1, Lexis Nexis (1993), §11.
20
U.C.C. §2-206(1)(a)(1).

Electronic copy available at: https://ssrn.com/abstract=3301463

smart contract with a private key should constitute a valid offer and acceptance under US
law.21
Some comparisons relating to how the courts have dealt with new technologies in the
past may be of use. For example, smart contracts may evolve like “click-wrap” agreements.22
These are contracts formed entirely over the internet. A party posts terms on its website,
pursuant to which it offers to sell goods or services. To buy these goods, the purchaser is
required to indicate its consent to be bound by the terms of the offer by his conduct –
typically the act of clicking on a button stating “I agree.” Generally, US courts have held
click-wrap agreements to be enforceable, recognising that parties in a modern context do not
need to consider and negotiate every term.23 US courts are apprehensive of applying terms to
a contract, however, if the consent was limited to other aspects of the contracting process. For
example, US courts have found that clicking a “Yes” button in connection with transmitting
credit card data could not bind the purchaser to terms emailed to him after the enrolment
process was completed.24
English courts have accepted that the parties are free to stipulate what acts will
constitute acceptance.25 In the context of smart contracts, parties could therefore prescribe
what particular message requirement will constitute acceptance of a previously messaged
offer.
In Australia, the Electronic Transactions Act 1999 (the “ETA”) deals with the
formation of electronic contracts and provides some welcome clarity for the likely legal
status of smart contracts under Australian law. For example, Section 15C of the ETA
provides that a contract formed by the interaction of an automated message system and a
natural person, or the interaction of automated message systems, is “not invalid, void or
unenforceable on the sole ground that no natural person reviewed or intervened in each of
the individual actions carried out by the automated message systems or the resulting
contract.” An “automated message system” includes a computer programme, without review
or intervention by a natural person each time an action is initiated or a response generated by
the system. This would mean that, even in cases where an agreement is reached through the
interaction of two smart contracts, such an agreement will not be unenforceable purely
because no natural persons were involved.26
Finally, under French law, in B2B contexts, there are no limitations on the use of
electronic means to enter into a contract.27
(ii) Consideration
In assessing whether a smart contract is supported by consideration, an English court is

21
Miren B. Aparicio Bijuesca: The Legal Challenges Associated with Smart Contracts: Formation, Modification
and Enforcement, in US Chamber of Commerce: Smart Contracts: Is the Law Ready? (September 2018), at 15.
22
R3 and Norton Rose White Paper, supra note 18, at 27.
23
See, e.g., Hancock v. American Telephone & Telegraph Co., 701 F.3d 1248, 1251 (10th Cir. 2012) and Davis
v. HSBC Bank Nevada, N.A., 691 F.3d 1152, 1157 (9th Cir. 2012).
24
See, e.g., Schnabel v Trilegiant Corp, 697 F.3d 110, 121–22 (2d Cir. 2012).
25
See, e.g., Holwell Securities Ltd v Hughes [1974] 1 WLR 155.
26
R3 and Norton Rose White Paper, supra note 18, at 30.
27
See, e.g., French Supreme Court: Cass. 1re civ., 1st July 2015, n° 14-19.781 and Paris Court of Appeals: CA
Paris, 4 February 2016, n°13-21057.

Electronic copy available at: https://ssrn.com/abstract=3301463

likely to consider whether there has been an exchange of value, or mutual benefit and burden.
English and Australian courts will not question whether “adequate” value has been given.
Similarly, under US law, consideration is generally anything of value, even if very slight,
exchanged between the parties.28

(iii) Intention to create legal relations

Under English, US and Australian laws, the parties’ intentions are assessed by
reference to objective criteria: the status of their communication with each other is analysed
by reference to what was communicated between the parties by words or conduct, and
whether that leads objectively to a conclusion that they intended to create legal relations.29
Therefore, if the other requirements for a legally binding contract are satisfied in the case of a
smart contract, it may be difficult for a party to assert, as against the other party who acted in
reliance on it, that there was no intention to create legal relations with respect to the smart
contract.
One of the key characteristics of smart contracts, however, is that they can behave
proactively: For example, where parties have voluntarily entered into a smart contract (the
primary contract), that contract itself can enter the parties into an additional contract (the
secondary contract). For example, the bank and the borrower could agree on a framework
agreement, whereby if the borrower’s bank balance dropped below a pre-agreed threshold,
the software would automatically issue a loan request to the lender, and the loan request is
automatically accepted, provide that certain pre-programmed conditions are met. This
involves the creation of new loan transactions from time to time (rather than a mere
drawdown under the existing loan facility). Given that the parties made the initial decision to
enter into the smart contract, one could argue that they indirectly agreed to be bound by the
system in which it operates. One could also argue that if the parties intentionally coded a
smart contract to make its own decisions, they must have intended to accept those decisions
as their own. The borrower could therefore be characterised as making a conditional offer
for a loan by coding the software to automatically request the loan when the relevant
condition is met (i.e., when the borrower’s balance reaches the relevant threshold). Similarly,
the lender would make its conditional acceptance of the offer by coding the software to
automatically accept any loan request that meets the pre-programmed conditions. The smart
contract then automatically generates the loan request and acceptance communications when
these conditions are fulfilled, thereby bringing about a new loan agreement.
This raises the question of whether the software itself might be seen as a party to a
smart contract and, if so, whether it would have the legal capacity to do so. One way to think
about this question is by applying the law of agency – the software could be regarded as an
agent for the party entering into the contract. There is no authority on this specific point, but
the UK court considered a similar question in relation to a software programme in Software
Solutions Partners Ltd, R (on the application of) v HM Customs & Excise, and found that an
automated system could not be regarded as an agent, because only a person with a mind
could be an agent in law. Therefore, it could be argued that the software is a mere

28
See, e.g., Exch. Nat’l Bank of Chicago v Daniels, 768 F.2d 140, at 143 (7th Cir. 1985).
29
See, e.g., RTS Flexible Systems Ltd v Molkerei Alois Müller GmbH & Co KG [2010] UKSC 14, ¶45; Empro
Mfg. Co. v Ball-Co Mfg., Inc, 870 F.2d 423, at 425 (7th Cir. 1989); and Taylor v Johnson (1983) 151 CLR 422.

Electronic copy available at: https://ssrn.com/abstract=3301463

messenger, which does not make its “own” decisions, but executes human decisions within
the limits of pre-set parameters. If the software is to be understood as a mere messenger, the
parties’ actions when programming the software could be characterised as the issue of a
conditional offer and acceptance.
A similar concern arises under the German Civil Code, under which a declaration of
intent consists of an objective and a subjective element. The objective element requires that
the behaviour of the declaring party implies a will to bring about legal consequences a
declaration of intent is made up of an objective and a subjective element. The subjective
element consists of: (1) the will to act, (2) the awareness to make a declaration, and (3) the
will to engage in a transaction. The subjective element requires human behaviour and legal
capacity, which is not present in smart contracts.30 Under the existing legal framework,
automated software may be able to qualify as a messenger of a declaration of intent issued by
a contracting party, i.e., to submit or receive such declarations of a contracting party, given
that under German law, being a messenger does not require a legal capacity to contract.31
(iv) Certainty of terms/essential terms
Smart contracts are (partly) written in a programming language and are often
published on a distributed ledger in a “compiled” form, which can be read only by
computers.32 This begs the question of whether a smart contract can provide determinable
commitments. To avoid any difficulties around this, it is recommended that the commitments
be described in a way that is understandable to all parties. A possible downside to
agreements in natural language next to code is that there can be a discrepancy between the
two. Nonetheless, one could argue that even natural language has many nuances and can be
ambiguous. How one person interprets a clause might be different to another. Admittedly,
well-drafted contracts should limit the degree to which such different interpretation might be
possible, but the day-to-day business of the courts suggests that it is not always the case.
Replacing parts of a contract with code may cause some translation issues, but natural
language drafting itself is not free from the risk of incorrectly reflecting a contracting party’s
intention.33 For example, German courts specifically recognised that a contract will be valid
and binding even if one of the parties does not understand German well.34
However, even though the parties can agree to express specific terms of their
agreement in computer code, it is important that this expression is admissible in any judicial
and arbitrary proceedings which arise out of that agreement. An inability to admit this record
of the parties’ agreement would impair its legal effectiveness, although courts may be willing
to admit expert evidence as to the meaning of the code.
There is an additional concern that the terms agreed by the parties may be varied by
law – for example, by implication, or if a court finds terms are void or have to be rectified
because they do not reflect the true agreement between the parties. For instance, suppose that
on the date of contract formation, the time a debtor needs to be in default for the creditor to

30
R3 and Norton Rose White Paper, supra note 18, at 42.
31
Münchener Kommentar zum Bürgerlichen Gesetzbuch, 7th edition (2015), BGB §105, note 44.
32
Compiled form is a form converted from the programme written in a programming language, which is
understandable to and written by humans, into a binary language form understood only by the computer.
33
See, e.g., ISDA and Linklaters: Smart Contracts and Distributed Ledger – A Legal Perspective (2017), at 17.
34
See Bundesarbeitsgericht, 5 AZR 252/12 (B) (19 March 2014).

10

Electronic copy available at: https://ssrn.com/abstract=3301463

repossess is 30 days and that after the contract is executed, the law changes, requiring that
time period to be 90 days. The immutable nature of smart contracts would make it
impossible to include such changes in the operation of the contract. A possible solution
would be to leave certain terms of the contracts modifiable, while restricting others from
modification. Thus, in the above example, the fact that payment is necessary would be an
immutable term, while the length of time a debtor has before (s)he is in default could be
modifiable.35 Another possible solution could be a system in which the relevant jurisdiction
creates a publicly available database and API of relevant legal provisions. These would be
provisions related to the terms of the contract. The smart contract would call these terms and
would be able to update the relevant provisions in accordance with the jurisdiction’s update
of the database.36
In conclusion, it is reasonable to suppose that the usual rules relating to contract
formation will probably apply to determine the legal status of a smart contract. Whether a
particular smart contract amounts to a legally binding contract will likely depend on the type
of smart contract at issue and the factual matrix within which it operates.37
F. Capacity and authority
In the case of entering into a contract with a company, the counterparty will wish to
determine whether the party signing on behalf of the company has the authority to enter into
such contract. Naturally, this is not unique to smart contracts; however, in the context of
smart contract, parties may want to verify such authority in an electronic or automated
manner. This will be possible only if the relevant data sources (e.g., a company registry
setting out the relevant information on the company and its authorised signatories, as well as
other signature authorisation documents of the company) are accessible to the software, and if
the software is sophisticated enough to parse the data contained in such documents to be able
to establish whether a specific person is authorised to enter into a specific type of transaction
on behalf of the company.
If sufficiently intelligent, the software might be able to access and parse a board
resolution or a list of directors itself. Otherwise, the software may simply seek an input
confirming that the resolution was duly passed or that the person “signing” the smart contract
and purporting to have the authority to do so does in fact have such authority. 38
G. Form of agreement
Sometimes the law requires that an agreement be concluded in writing. The law will
typically also prescribe the conditions that must be met for an agreement that has been
concluded electronically to be considered to be in writing. By way of example, under Dutch
law, an agreement concluded electronically is deemed to be in writing if: (i) it can be
consulted by parties, (ii) the authenticity of the agreement is safeguarded to a sufficient

35
Max Raskin: The Law and Legality of Smart Contracts, 1 GEO. L. TECH. REV. 305 (2017), at 327.
36
Ibid.
37
For further analysis of whether smart contracts have a legally binding effect in the US, the UK, Australia,
Canada, Germany, France, China and South Africa, see R3 and Norton Rose White Paper: Can smart contracts
be legally binding contracts?, at 22 – 45.
38
Clifford Chance and European Bank for Reconstruction and Development, supra note 9, at 22.

11

Electronic copy available at: https://ssrn.com/abstract=3301463

degree, (iii) the moment of the creation of the agreement can be determined with sufficient
certainty, and (iv) the identity of the parties can be established with sufficient certainty.39
The first element is the most challenging one: if the agreement must be written in
such a way that the parties are able to access and save its contents in order to be able to
inform themselves later about the agreement, this can be difficult to achieve for a contract in
compiled form, which is legible only to computers. It is highly doubtful whether even the
most popular programming languages are widely enough understood to serve as a means of
reducing the agreement to “writing” in a way that ensures a meaningful “meeting of the
minds” between most contracting parties. The solution to this issue could be to ensure that a
smart contract is accompanied by an attached “natural language” written contract.40 This
should be incorporated as a design feature in the creation of any smart contracting system for
a contract that is required to be “in writing.”
The remaining three elements should be relatively straightforward: The obligation of
authenticity is easily met as smart contracts cannot be changed unilaterally. Similarly, on the
assumption that indisputable, automatic date/time stamps are used, the moment of an
agreement’s creation, or at least the smart contract portion of this, can be established with
sufficient certainty.
Finally, with respect to the identity of the parties, the question remains as to whether,
under the relevant laws, the cryptographic signature of a party qualifies as a proof of identity.
In many jurisdictions electronic signatures are already considered as equivalent to
handwritten signatures. The definition of “electronic signature” is broadly similar across
jurisdictions. For example, under the US Uniform Electronic Transactions Act (the “ETA”),
an “electronic signature” is defined as “an electronic sound, symbol, or process attached to or
logically associated with a record and executed or adopted by a person with the intent to sign
the record.”41 Under the EU Regulation No. 910/2014, “electronic signature” is defined as
“data in electronic form which is attached to or logically associated with other data in
electronic form and which is used by the signatory to sign,”42 and “qualified electronic
signature” (which is treated as equivalent to handwritten signature) is defined as “an
advanced electronic signature that is created by a qualified electronic signature creation
device, and which is based on a qualified certificate for electronic signatures.”43
A cryptographic key is likely to constitute a record of a “process” (within the meaning
of the ETA), which is logically associated with a record, or it may contain a symbol that
constitutes a signature and is merely recorded on DLT. Whether or not it also meets the
requirements of a “qualified electronic signature” under the EU Regulation will depend on
the characteristics of the DLT system in question and the way in which cryptographic keys
are used under that system.

39
Article 6:227a of the Dutch Civil Code (English language translation available at:
http://www.dutchcivillaw.com/legislation/dcctitle6655.htm).
40
See Dutch Blockchain Coalition: Smart contracts as a specific application of blockchain technology, available
at: https://www.dutchdigitaldelta.nl/uploads/pdf/Smart-Contracts-ENG-report.pdf, at 23.
41
Uniform Electronic Transactions Act, § 2(8).
42
EU Regulation No. 910/2014, Article 3(10).
43
Ibid., Article 3(12).

12

Electronic copy available at: https://ssrn.com/abstract=3301463

 Finally, as a matter of public policy, lawmakers will need to consider whether the role
of such third parties as notaries should be retained or may be automated. This will, to a large
extent, depend on the role that such third parties play in the transaction process, i.e., whether
their role is limited to identifying parties or is broader and involves warning the parties about
the implications of the contract they are entering into. Notably, real estate transactions may
require agreements to be recorded by a notary and rights to be registered in the land registry,
while lawmakers may be more confident in establishing a DLT-based land register (provided
that the register satisfies the transparency and evidentiary functions adequately and is able to
maintain public trust), they are less likely to be comfortable with removing the requirement
for the notary recording to the extent this currently also serves to warn the contracting parties
and to provide them with advice, rather than just verifying their identity.44
H. Liability
What if there is a glitch somewhere in or between the programming language and the
executable machine code and, consequently, the code does not do what it was intended to do
when executed? Arguably, the risk of a glitch somewhere in the programming already exists
in the use of any computer programme. However, one of the main challenges concerning
smart contract liability lies in the fact that there are many parties involved, but determining
the relationship between them is far from easy. Namely, there are the core group that sets up
the code design, the owners of additional servers running the distributed ledger code for
validation purposes (such as Bitcoin or Ripple validation nodes), users of the distributed
ledger (such as exchanges, lending institutions or owners of Bitcoin), and third parties
affected by the system without directly relying on the technology (e.g., clients of brokers that
hold cryptocurrency on behalf of clients).45
A number of issues and considerations arise from such complex relationships: First,
the question of who owns the distributed ledger software code is likely to be a question of
property or copyright law, and the answer may have consequences on who is responsible for
the code from a tort law perspective. Namely, if a third party is damaged by a coding error or
a security breach, it could try to direct its claim based on tort law to all nodes jointly. This is
unlikely to be successful, given that proceedings can only be initiated, and measures taken,
against a (legal) entity and not against a node or, in a broader sense, a system. A party’s
liability in the tort of negligence will typically depend on whether it owes a duty of care and
has breached that duty, whether the breach caused loss or damage, and whether it has
effectively contractually excluded liability for this type of loss or damage.46
Another issue concerns the treatment of the cooperation underlying a distributed
ledger – for example, are those cooperating in a system liable for failures, and who among all
the various nodes (if anyone) bears the legal responsibility for system hacks.47
To prompt parties to at least consider the allocation of liability, smart contract
templates should ideally contain a field indicating the contracting parties’ choice of liability

44
Clifford Chance and European Bank for Reconstruction and Development, supra note 9, at 28.
45
Dirk A. Zetzsche, Ross P. Buckley and Douglas W. Arner: The Distributed Liability of Distributed Ledgers:
Legal Risks of Blockchain, University of New South Wales Law Research Series (2017), at 21-22.
46
See, e.g., Hedley Byrne & Co Ltd v Heller & Partners Ltd [1964] AC 465 and its progeny, recognising
liability in tort for pure economic loss.
47
Zetzsche et al., supra note 45, at 22.

13

Electronic copy available at: https://ssrn.com/abstract=3301463

scheme in the event of a coding error. However, parties would still have the freedom to
select no liability allocation mechanism. In such case, there could be an automatic warning
message asking the parties to confirm that they do not wish to specify what should happen in
case the code deviates from the parties’ expressed written wishes, and notifying them that
failure to designate a liability mechanism could result in the allocation of losses wherever
they fall.
Moreover, there are many potential non-contractual liabilities that may arise in
relation to particular transactions effected through smart contracts, including, for example,
claims for fraud, unfair trade practices, insider trading, market abuse, etc. There might be a
possibility for insurance companies to fill in the liability space and insure liability risks in
connection with smart contracts. Conditions under which such insurance applies will be far
from easy to draft.
I. Burden of proof
In many jurisdictions, applicable procedural rules will require each party to assert its
own claims in court and to apply for its legal enforcement with a court. As a general rule, a
claimant will often have to prove the facts on which it seeks to rely and will bear the risk that
such facts cannot be proven. For example, if Party A fails to make a payment under a non-
smart contract that obliges Party A to make the payment to Party B, Party B would have to
assert and, generally, prove in court that it has a valid payment claim and that Party A has not
paid. In addition, Party B would have to apply to the court for legal enforcement of a court
judgment finding that Party B has a valid payment claim, if Party A still does not pay. Hence,
Party B would bear the legal risk that it cannot prove its claim and the risk that Party A may
enter into insolvency prior to legal enforcement of the judgment. While these general
principles also apply to claims relating to smart contracts, the circumstances of the claim (and
hence the burden of proof and associated risks) are likely to be reversed as a result of
automation. If, in the above example, the payment were automated under a smart contract,
Party B would automatically receive payment and so it would not have to assert its payment
claim in court. Rather, Party A would now have to assert and, generally, prove in court its
claim for repayment of the relevant amount if it considers that the payment should not have
been made. As a result, Party A would bear the legal risk of having to prove its claim as well
as the risk that Party B might enter into insolvency before the repayment is made. There may
also be other legal consequences for Party B, such as an inability to exercise rights of
retention or set-off either within or outside of litigation.
The party benefitting from this procedural “reversal” and shift in risk (Party B in the
above example) may therefore be more willing to enter into a contract with a pseudonymous
third party. However, this procedural “reversal” and shift in risk resulting from the automatic
performance of a contract may not be desirable in certain cases. For example, certain types of
parties (such as consumers) may be less able to assume such risk. Hence, legal systems may
seek to prohibit any change to the usual burden of proof to the detriment of a consumer.48

48
Clifford Chance and European Bank for Reconstruction and Development, supra note 9, at 43-44.

14

Electronic copy available at: https://ssrn.com/abstract=3301463

 J. Governing law and dispute resolution mechanism
Because a smart contract automatically performs across distributed computing
systems, it may be difficult for a court to determine the place of that performance when
attempting to decide what governing law ought to apply to the smart contracts. While this
difficulty will not prevent courts from taking jurisdiction over smart contract disputes, it does
prevent accurate prediction as to which court will take jurisdiction and which governing law
it will apply. Some comfort can be derived from the fact that courts are used to dealing with
difficult jurisdictional issues in, for example, contracts formed over the internet (e.g., an
online purchase of goods or services). Jurisdictional uncertainties in the case of smart
contracts might be resolved (to some degree) by having a mandatory field in a smart contract
for the parties to indicate which governing law applies. In many jurisdictions, courts will
generally seek to uphold the parties’ express choice of law to the extent possible. Notably,
however, when selecting the governing law, parties should ensure that they choose the law
that recognises contracts written in code, concluded electronically or with a pseudonymous
counterparty as legally binding.
Still, there may be an issue concerning the location of the smart contract, which could
be relevant for determining what professional regulatory or taxation regime applies, and these
are not necessarily the areas where the parties’ agreement is determinative. Instead, it can be
a matter of objective determination based on the place of performance. Where the applicable
conflicts of law rules provide that, in the absence of the parties’ express choice of law, the
applicable law is the law of the jurisdiction where an asset is located, an additional practical
consideration arises in relation to native assets on permissionless blockchains. Namely,
native assets on a public blockchain could be analogised to trade secrets or unregistered
copyrights, which similarly have no central repository or registration authority. Participating
in a permissioned blockchain with a centralised authority, or utilising a third-party
intermediary (e.g., a known wallet provider) to hold blockchain-based assets, may give
parties to smart contracts more reliability that these assets are held in the jurisdiction where
the centralised authority or a third-party intermediary is located. Naturally, this will come at
the expense of the decentralisation that many blockchain proponents desire.49
When it comes to dispute resolution mechanisms, recourse to the courts to enforce a
smart contract can be cumbersome and ineffective. Instead, it has been suggested that a
dispute resolution mechanism built into the smart contract itself could provide a solution.
Such a mechanism would need to have the following characteristics:
- A provision in the code that causes delegation to an arbitrator, which would be
triggered under the rules encoded in the smart contract: for example, by both
parties asserting a defect and nominating the arbitrating entity. In fact, a number
of organisations have already started developing arbitration clauses or “libraries”
that parties could include in their smart contracts.50

49
Jenny Cieplak: U.C.C. and State Law Issues in Smart Contracts, in The Legal Challenges Associated with
Smart Contracts: Formation, Modification and Enforcement, in US Chamber of Commerce: Smart Contracts: Is
the Law Ready? (September 2018), at 58.
50
See, e.g., see CodeLegit Conducts First Blockchain-based Smart Contract Arbitration Proceeding (July 2017),
available at:
https://datarella.com/codelegit-conducts-first-blockchain-based-smart-contract-arbitration-proceeding/,
describing steps in the blockchain arbitration proceedings.

15

Electronic copy available at: https://ssrn.com/abstract=3301463

 - A provision in the natural language version of the contract, agreeing to submit
disputes to arbitration: this assumes that there is a natural language version of the
contract and that it matches the delegation mechanism in the contract code; and
- A forum for arbitration, which could be administered centrally, or via a relevant
ledger, or by use of one of the many existing and experienced for a. The forum
would identify these essential components: a body of rules for the arbitration, pool
of possible arbitrators, and an administration capable of managing the cases as
they are filed and decided.51
The arbitrator could also be (partially) automated and could, for example, have
control over funds deposited by parties to a smart loan contract, which it could automatically
release where it resolves a dispute, deficiency or mistake by deciding that one party owes an
amount to the other under the contract.

In due course and once we start seeing greater use of smart contracts in practice,
lawmakers may also wish to consider whether to establish courts that specialise in smart
contract disputes, in the same way that, for example, specialist Intellectual Property Enterprise
Court and the Technology and Construction Court have been established in the UK. Similarly,
some continental European courts have established specialist chambers, for example, for
construction, trade-related or medical disputes, which would be adjudicated by technical
experts.

K. Privacy issues
Privacy concerns the protection of personal information, which is data that can be
traced, directly or indirectly, to a living natural person. This covers such data as name,
address and telephone numbers, but it may also apply to a set of other data that together have
something to say about an identified or identifiable natural person such as, for instance,
location data or video footage. If such information is included in a distributed ledger, it
counts as personal data. Within the European Union, on the basis of the General Data
Protection Regulation (“GDPR”), citizens have various rights with respect to their personal
information. Among other things, this includes the right to correction of personal
information, its deletion and the right to be forgotten. In the smart contracts context, data has
been pseudonymised, and not anonymised, which means that it remains personal data for
purposes of GDPR.
GDPR distinguishes between a data controller and a data processor. Data controller is
a person that determines the purposes and means of processing personal data, while the
processor only processes the personal data on behalf of the controller. Identifying these
persons and their roles can be challenging, particularly given the decentralised nature of
permissionless DLT-based systems and the ability of network participants to enter into smart
contracts directly with each other, share resources on a peer-to-peer basis and add
information to the ledger, without requiring any authorisation from a central administrator.
Arguably, any participant entering personal data in blocks of the ledger may be regarded as a
controller of the data it has provided or to which it has access through the system, unless it is

51
R3 and Norton Rose White Paper, supra note 18, at 19.

16

Electronic copy available at: https://ssrn.com/abstract=3301463

a mere technology service provider supporting the system, in which case it is likely to be
characterised as a processor.
An option often used is not logging personal data directly in a blockchain, but instead
inserting hyperlinks into a blockchain that can be linked to files containing personal data.
Although this makes it easier to remove or amend personal data (see below), it does not
detract from the fact that personal data is being processed. Whether or not the GDPR applies
to a blockchain in which personal data is processed is therefore governed not by whether
there are nodes situated within the European Union, but whether processing is carried out in
the context of the activities of an establishment of one of the controllers (or processors) in the
European Union. Recognising this challenge, the European Parliament has called on the
European Commission and the European Data Protection Supervisor to provide further
guidance on the compliance of blockchain-based applications with the GDPR.52
L. Contractual amendments
Although the immutability of smart contracts is seen by the proponents of DLT as a
desirable feature, from a legal perspective, it can give rise to a number of issues. Natural
language contracts often need to be amended to reflect changes to the underlying commercial
arrangement, to correct errors, or to reflect changes in law. Any such desired changes will be
impossible with respect to the encoded aspects of the smart contract on a distributed ledger.
A possible solution to this issue may be to “reverse” the transaction by a new transaction that
exactly offsets an existing transaction, negating its effect. However, this solution is not ideal,
because such reversal in performance could be void if it is entered into after one of the parties
has become insolvent.
Indeed, the immutability of smart contracts deprives them of the flexibility of
traditional contractual relationships and prevents parties from being able to adjust their
positions in response to changed circumstances. The problem these features can give rise to
were revealed in June 2016, during the hack of the Decentralized Autonomous Organization
(DAO) – a fundraising vehicle that raised USD 168 million when it was launched on
Ethereum in 2016. When an attacker exploited a smart contract flaw to siphon off over USD
50 million from the DAO, the Ethereum community questioned the principle of maintaining
the ledger’s immutability. The Ethereum Foundation decided to intervene on the DAO
investors’ behalf – in effect, bailing them out – by rewriting Ethereum’s core code to
delegitimise the attackers’ transactions and recover the funds. To do so, the Foundation,
influenced by the platform’s heavily invested founders, convinced most users to go along
with its decision. In order to return the diverted funds, a fork was created, which changed the
Ethereum protocol that restored the stolen tokens as if the hack had not happened. However,
this breach of immutability was a controversial move, and one that prompted a split in the
Ethereum community – a minority of the participants continued with the original, unamended
code. As a result, Ethereum split into parallel crypto-universes, identical in most respects
with one key difference: the forked Ethereum universe essentially treated the DAO’s smart
contracts and rescindable by all participants due to mutual mistake, and the non-forked
Ethereum universe continued to treat the attack as a valid transaction within the terms of the
DAO’s smart contract.

52
European Parliament: Distributed ledger technologies and blockchains: building trust with disintermediation
(October 2018), ¶ 33.

17

Electronic copy available at: https://ssrn.com/abstract=3301463

 Another problematic issue that arises as a consequence of the immutable nature of
smart contracts is the way in which a court’s decision that a smart contract is void (i.e., never
existed) would be effected. Clearly, “reversing” the transaction by a new transaction that
exactly offsets an existing transaction, negating its effect will not produce the same result as
if the contract were treated as never having existed.
M. Conclusion
Given that smart contracts decrease transaction costs by cutting out intermediaries,
they are likely to increase in relevance and scope. Admittedly, mainstream adoption is still a
few years away, given that smart contracts need to be integrated with the industry’s existing
systems, which raises questions about the effort involved and the investment that will be
required. However, just as companies are starting to identify the changes that will be
required, including to IT systems, processes and change management policies, so too should
regulators and lawyers capitalise on this momentum and focus on smart contracts as part of
the broader FinTech innovation ambit.
Innovative technology does not necessarily require innovative jurisprudence and, in
many instances, the existing legal systems will be perfectly sufficient to deal with the “new”
features of smart contracts – e.g., their expression via computer code. In other cases, the
existing rules will need to be adapted to the new context of smart contracts (e.g., in relation to
the signing via a cryptographic key and compliance with privacy regulations). Some of the
solutions may even be provided by contracting parties through the design of their contracts
(e.g., allocation of liability and specification of the governing law and dispute resolution
mechanism). More broadly, smart contracts represent a unique opportunity for the legal
profession to lead the development of a new, fast-evolving area.

18

Electronic copy available at: https://ssrn.com/abstract=3301463