The
Recognition of Smart Contracts in Jersey
Emma German
This article examines Jersey law around the recognition of smart
contracts as enforceable legal contracts. It considers whether contracting
parties should receive a human readable translation of contractual terms
written in computer code to provide valid contractual consent and whether
Jersey law needs to recognise the concept of an electronic agent. This article concludes
that smart contracts can create enforceable legal contracts under Jersey law
subject to satisfying the usual constituent elements of a contract.
1. Introduction
1 Smart
contracts have the potential to revolutionise contracting and legal practice. Elements
of smart contracts are novel and, being de-materialised, challenge the
traditional methods of conducting business in the “paper era”.[2]
Often described as “self-executing contracts” smart contracts
effectively animate contracts. They can offer automated payment solutions,
secure data transfer and constitute a new way of contracting (potentially
transformative for, eg, finance
contracts, by automating certain quantitative provisions; and, eg, conveyancing contracts, by
automating updates to the public land registry). Using Nick Szabo’s
original example, a blockchain literate car can, using a smart contract, detect
the occurrence of a default on the car finance and disable itself until payment
is received.[3]
2 The term “smart
contract” is a computer science term and not a legal term. A “smart
contract” is computer code and not a contract per se in the legal sense. To constitute a legally binding contract
the code would need to satisfy the usual elements necessary to make a legally
binding contract. Reference to “smart contracts” in this paper is
to smart contracts that are intended to be valid legal contracts or smart legal
contracts.
3 The enormous
potential application of smart contracts creates a commercial imperative for
Jersey law to recognise smart contracts as legal contracts enforceable in
Jersey. This article focuses on whether a “smart contract” is
capable of being interpreted and enforced as a valid contract under Jersey law
and concludes that:
(i) ordinary rules of Jersey contract law apply to
smart contracts;
(ii) some forms of smart contracts are capable of
forming valid contracts under Jersey law without statutory intervention;
(iii) it would be beneficial for Jersey to make a
statement of its recognition of smart contracts as part of the forthcoming
restatement of contract law; and
(iv) amendments to the Electronic Communications
(Jersey) Law 2000 as amended by the Electronic Communications (Amendment of
Law) (Jersey) Regulations 2019 (the “ECJL”) are recommended to
encourage smart contract usage in Jersey.
4 This article
also considers whether smart contracts are a revolution or simply an evolution
in ways of forming a contract. In applying the ordinary rules of contract law
(Norman-derived customary law (“customary law”)) it is evident that
smart contracts are not a revolution. Smart contracts do re-write the rule book
on how we transact, but not the fundamental legal principles of contracting. The
marketplace has evolved, with online retailers, increased use of electronic
signatures and more complex products (eg
synthetic derivative securities) but the fundamental principles of law have
survived.[5]
It is better to adapt long-established principles of contract law[6]
(even with inherent inconsistencies) than to guess the impact of a technology
and attempt to legislate for it. Interpreting the technology using established
principles and allowing the courts to clarify where necessary is more prudent. This
is consistent with the approach of the UK Jurisdiction Task Force (“UKJTF”)
which concluded that “the ordinary rules of contract law apply to smart
contracts”.[7]
2. What
is a smart contract?
5 This section
provides a basic overview of smart contracts to assist the legal analysis that
follows.
2.1 Smart contracts
6 “Smart
contract” is an umbrella term for “smarts” or computer code
with no single legal definition. “Smart contract” is a computer
science term referring to computer code that runs in certain blockchain systems
(eg ERC-20 or ERC-721 using Ethereum)
causing pre-defined outcomes to be performed when pre-defined conditions are
met.[8]
For example, if A occurs, the outcome is B. The smart contract code is run by
nodes (the network participants) and when the pre-defined conditions are met,
the ledger maintained on the network is automatically updated with the
pre-defined outcome, eg the transfer
of ether. Smart contracts are therefore referred to as being auto-executing or
self-executing. The term “contract” is used loosely[9]
as the “smart contract” may not always form an enforceable legal
contract (see below).
7 Szabo first
coined the term “smart contracts” in the 1990s[10] giving the following as
examples of how smart contracts work: (i) a “humble vending machine”;
and (ii) a blockchain literate car that could disable itself in the event of a
default on the repayment of the finance arrangements relating to it.[11]
In these examples, Szabo portrays the computer running the code (the contract)
as performing certain tasks in the contract.
2.2 Usage
8 There are
endless uses in Jersey for smart contracts and distributed ledger technology (“DLT”)
more broadly. A few examples give some context:
(i) The issuance and transfer of digital assets: digital
representations of traditional securities (ie,
security tokens with the rights and obligations of a traditional security which
are transferable in de-materialised digital form); utility tokens; and other
non-security tokens can be issued and transferred by smart contract. This would
enable on-chain transfers of securities and instantaneous updates of registers, eg shares in share transfer companies
owning properties, could be transferred on the blockchain (if the distributed
ledger was nominated as the register of members/securities holders).
(ii) Payment solutions for immediate settlement: bypassing
lengthy settlement times and removing intermediaries, agents and clearing
houses (and their costs) from the process, smart contracts enable immediate
on-chain settlement.[12]
Examples include the JP Morgan DLT derivatives margin payment solution[13]
and the HSBC custody solution.[14]
In the retail context: (a) BMW, General Motors and Ford are testing blockchain
payment systems in their cars;[15]
and (b) Mastercard[16]
and Ikea[17]
are using smart contracts to facilitate settlement.[18]
(iii) Transferring and validating information, such
as:
(a) voting
(eg by security holders), thereby reducing
the administrative burden of convening and voting at meetings.
(b) public
records: if Jersey introduced DLT public registers, they could automatically
update on trigger events.
example (1) The register of immovable properties could update on the change
of legal owner;
example (2) A confidential register of wills (registered on satisfaction
of relevant formalities) could release a will to the family of the testator
following his/her death, but allow codicils or new wills to be made in
sequential order, thereby reducing the costs, delay and emotional burden of
lost, destroyed or uncertain wills.[19]
2.3 Smart legal contracts
9 Smart legal
contracts (a subset of smart contracts) are those which satisfy the conditions
necessary to form a binding and enforceable contract.[20] The Chamber of Digital
Commerce (“CoDC”) identifies two further categories:
(a) internal
smart contracts: a smart legal contract that captures the entire agreement
between the parties, eg a transaction
on standard binary terms selling a digital asset from Alice to Bob. There are
two types:
i(i) where the code represents the
whole agreement between the parties, superseding human-readable clauses which
are considered explanatory; and[21]
(ii) where the code represents
only part of the contract, but that part contains the operative terms of the
contract and supersedes the clauses written in human-legible language;
(b) external
smart contracts: negotiated contracts with bespoke terms that cannot be
reduced to a binary outcome although quantitative elements (eg asset transfer and interest payments)
could be automated, eg syndicated
loan agreements. They are written predominantly in human-parsable languages which
prevail over the code (an interpretation clause is required for that effect).
10 The internal
v external distinction is important in Jersey because it relates to the
interaction between the human-parsable terms and computer code.[22]
11 This article
focuses on whether smart contracts can create legally enforceable contracts
under Jersey law. It is submitted that:
(a) external
contracts are more likely than internal contracts to meet the requirements of a
valid Jersey law governed contract because humans can read their terms and
determine whether to consent to those terms (see developed further at Section
3).
(b) internal
contracts which are not human-parsable and override human-parsable terms are less likely to constitute valid
contracts under Jersey law unless the non-human-parsable automated part
of the code which is inconsistent with the human-parsable terms is peripheral.[23]
12 In Jersey
this position will persist whilst the subjective approach to contractual
consent prevails (discussed at para 27 et seq). For a human counterparty
to subordinate its understanding of contractual terms to computer programming
which he/she cannot understand is not in my view a sound basis for contractual
consent. It may be commercially desirable for precise computer code to take
precedence over lengthy legal prose, but the implementation of technology does
not arise in a legal vacuum and traditional legal analysis must be applied to
it, including the established principles of contractual consent.
13 This
distinction between internal and external smart contracts is likely to be a
short-lived given advancements in technology. Projects are underway to enable
lawyers to draft contracts in human-parsable language which can be converted
into computer code and create new mark-up languages (eg (i) DAML, the Digital Asset Modelling Language which is coded in
the source code, but appears as human language and is converted into bytecode
on the ledger,[24]
and (ii) FpML, the Financial Products Markup Language managed by ISDA for the
electronic dealing and processing of OTC derivatives trades).[25]
This means that it is only a matter of time before programs align
human-parsable language with computer-readable code thereby removing the
potential for uncertainty and inconsistency.
3. Can smart contracts create enforceable contracts under Jersey law?
14 This section
examines the traditional requirements for creating a contract under Jersey law
and shows how smart contracts are capable of satisfying each requirement.
3.1 Choice of law
15 For Jersey
law to apply to a smart contract, it should be governed by Jersey law. This
could be determined by the governance documents of the relevant blockchain or
by a term of the specific smart contract. The ordinary methodology for
determining the governing law of traditional contracts should apply, ie parties make an express choice or
take into account, for example, their physical locations, the situs of an
asset, performance of services or the jurisdiction of incorporation of an
issuer.[26]
For example, Jersey law would be an appropriate governing law for smart
contracts relating to immovable property in Jersey or tokens issued by a Jersey
company. Where neither the identity nor location of the contracting parties is
known, the architects of the blockchain ecosystem would need to select an
appropriate governing law agreed by those participating in the network.
16 Traditional
rules of private international law focus on the lex situs of tangible property. However, for dematerialised
intangible property, analysis has previously focused on the situs of the ledger
(book entry) recording the proprietary rights.[27] The decentralised nature of
the blockchain network can complicate this analysis as DLT systems often have a
cross-border dimension making it “less than clear where assets and their
records are located in a DLT environment.” [28]
17 Therefore, parties intending Jersey law to apply to their
smart contract should include an express term to that effect (although this
does not prevent claims that another governing law applies). Where there is a
conflict of laws, there is a good argument to suggest that the ordinary
conflict of law principles should apply. The UKJTF concluded likewise and
suggested some factors to determine the governing law. These included:
(a) the location of (i) any relevant
off-chain asset; (ii) any centralised control; (iii) a particular participant
controlling a particular crypto-asset;[29]
(b) the law applicable to the relevant transfer (eg due to parties’ choice).
3.2 Contracts
18 Assuming the
parties choose Jersey law, either in the blockchain terms of usage or in the
smart contract terms or Jersey law otherwise applies, the elements of forming a
valid Jersey contract must then be satisfied. Smart contracts are capable of
satisfying these requirements.
19 Where a smart
contract transfers a store of value (monetary or otherwise) from Alice to Bob
in exchange for a benefit (however defined), it is a contract for value or contrat à titre onéreux. Alice
confers a right on Bob with the intention of securing a reciprocal benefit from
Bob. A feature of smart contracts on the public blockchain is that the parties
may be anonymous or pseudo-anonymous, so Alice does not know that she is
contracting with Bob. This is not unique to smart contracts. For example, when
contracting with an agent, Bob might not know the identity of the agent’s
principal. Similarly with contracts concluded in e-market places (eBay or
Airbnb etc), the counterparties might
not be easily identifiable.[30]
It is not a requirement of Jersey law that parties be known to each other to
create legal relations, but it is of practical importance for serving notice
and suing for breach of contract.
20 There are instances when the identity of the counterparty
is relevant in so far as it affects the value and provenance of the subject of
the contract, eg Bob buys Sir William’s
copy of La Glose. The book’s value is affected by the provenance viz.
that it was owned by Sir William. Buying a book from Alice would not justify
the premium.
3.3 Contract formation
21 Jersey law
requires the four keystones of (a) consent, (b) capacity, (licit) objet, and (d) (licit) cause (per Selby v Romeril[31]
and Marett v Marett).[32]
22 Smart
contracts can satisfy these requirements although there are some novel features
which may arise. Some traditional contracts involve additional formalities such
as powers of attorney but even these requirements could be satisfied using
blockchain technology.
23 Intertwined with consent is the need for the parties to
intend to create legal relations. Smart contracts transfer a store of value
from Alice to Bob in return for, eg,
Ether. The mutuality of obligations[33] establishes that
the arrangement is intended to create legal relations.
24 To give clarity to the position, the blockchain terms and
conditions of usage could include an acknowledgement by the parties of their
intention to enter into legal relations. The Guernsey Ordinance[34] deals with this by
including a rebuttable presumption to this effect. Whilst not advocating a
blockchain specific statute, a rebuttable presumption (in statute) could give
an element of contractual certainty. However, this goes beyond the approach
taken for traditional contracts.
3.3.1 Consent
25 Pothier said
the consent of the parties is the “essence of the contract of sale”[35]
(and of contracts generally). Consent is required for parties to reach an agreement
and is essential to the operation of the legal maxim enshrined in Jersey law “La convention fait la loi des parties”[36]
(the agreement makes the law of the parties). It is this key principle that
promotes the inherent flexibility of Jersey contract law and assists with the
legal recognition of smart contracts. The parties are free to reach a binding
agreement by smart contract if they see fit.
26 Under Jersey
law, valid consent requires (a) a definite offer to be bound; (b) an
unequivocal acceptance of that offer; and (c) certainty of terms.
Subjective
v objective approach
27 The Royal Court in Selby
v Romeril[37] did not expressly state
whether consent should be assessed on a subjective basis (looking for the
subjective intention of the individual parties to the contract)[38] or objective basis
(what a properly informed reasonable man would take to be the position). This article
assumes that the current Jersey approach is a subjective test[39] rather than the
objective test applied by the English courts (which “promote[s] certainty
and predictability in the resolution of contractual disputes”).[40] This may change and
legal authorities in Jersey are inconsistent on this point,[41] but it is an
important distinction when evaluating the weight of the various sources of customary
law. Generally, in practice, contractual interpretation in Jersey closely
follows the approach taken in England. However, some contractual dispute
authorities highlight fundamental differences between Jersey and English law (eg cause v consideration, erreur v misrepresentation), and not
least whether Jersey follows a subjective approach (which is the prevailing
view) or an objective approach to contractual consent.
28 Marett v Marett[42] is authority for the
principle that the subjective approach to contractual consent should be
followed. As Sir Philip Bailhache has written—
“One of the
important consequences of the principle [la convention fait la loi des
parties] is the implicit emphasis upon the mutual consent of the parties”
and, citing Incat Equatorial Guinea Ltd v Luba Freeport Ltd that—
“volonté,
or will, which binds them together and requires that the mutual obligations
which they have agreed be given effect by the courts . . . A man is
bound only by his will, and because he is the best judge of his own interests
the best rules are those freely agreed by free men . . .”[44]
29 The law applying to smart contracts should follow the law
applied to traditional contracts. A detailed analysis of the objective v
subjective approach is set out in the judgment of the Court of Appeal in Booth v Viscount.[45] In Booth the court observed:
(a) that the
debate should not be over which source of law to follow (English principles or
French) but instead whether to follow the objective or subjective approach; and
(b) that those advocating the objective view
should not “sweep away
existing Jersey concepts and superimpose English contract law”.
The author’s primary
reservation about adopting the objective approach is the erosion of the inherent flexibility
afforded by customary law. The contractual freedom embodied in “La convention fait la loi des parties”
assists with the legal recognition of smart contracts, because it embodies the
freedom which:
“entails that a
person is free to decide whether or not to bind himself by contract and to
determine the consent of his commitment, the corollary of that . . . consensus
ad idem [meeting of the minds] means that intention will suffice, without
there being any requirement as to form.”[46]
30 Whilst the
objective approach can be substituted for the subjective approach, it will be
submitted that this could lead to potentially unfair outcomes, particularly in
the context of smart contracts written in code which humans cannot read or
where the code supersedes the human-parsable translation.
31 It is argued
that some subjective element of contractual consent should be preserved to
safeguard against such potentially unfair outcomes. However, the Court of
Appeal acknowledged in Booth v Viscount that the subjective view (as
adopted in French law) was not without its problems: notably the indefinite
uncertainty of discovering a defect in consent at a later date that could lead
to the contract being void.
32 The
discussion over objective v subjective approach is just as relevant to smart
legal contracts as it is to traditional contracts. Arguably, contracting by
smart contract leans more towards the objective approach given the potential
lack of direct negotiation between parties (potentially anonymous) and
increased reliance on the limited written communications and/or code to
demonstrate their respective intentions.
33 Some members
of the judiciary appear to take the view that the subjective approach is less
desirable than the objective approach because the objective approach is more
modern: the court in Calligo stated
that the Jersey contract law needs to be updated from its customary law roots
to “suit the needs of a modern community which is also a sophisticated
international finance centre”[47] and the “requirements
of life in the 21st century”. Whilst a clear and consistent contract law
is desirable, it is not clear that a modern approach (if that means
fundamentally different) is required or indeed that an objective approach
achieves that. This modern community needs to apply Jersey contract law to
smart legal contracts and it is the subjective approach, stemming directly from
the customary law principles, which assists both with their legal recognition
and in providing “individualised justice”.
34 Following the objective approach to contractual consent,
to the exclusion of the subjective approach, makes consent mechanical in so far
as consent will effectively be deemed (or not) from the written word of the
contract and its circumstances. The distinction between the two approaches is
important because it can lead to very different outcomes in practice. The
examples below highlight these different outcomes in the blockchain context.
(a) Example
1: transferring a token from Alice to Bob via smart contract (running
human-parsable code). Applying the objective approach to contractual
consent, the outcome is assessed by the facts: the smart contract is agreed
when the code is run. This automatically performs the terms of the contract and
Bob becomes the tokenholder. Applying the subjective approach, the outcome is
unchanged if the code reflects the human-parsable terms.
(b) Example
2: transferring a token from Alice to Bob via smart contract (running code that
is not human-parsable). Computer code that is not human-parsable cannot be
reviewed by the counterparties. Taking the objective approach, some
construction of the facts could lead to an argument that contractual consent
had been given to terms the parties had not read. A similar approach is taken
under the Guernsey Ordinance (defined below) which gives legal effect to
contracts not reviewed by a human (see para 101 et seq). This may be
efficient for a contract with simple terms but may cause issues with a more
complex contract. By comparison, applying the subjective approach, if the terms
of the contract are not human-parsable, it may be difficult to show that the
minds met or that there was a volonté
of the parties.
(c) Example 3: transferring a token from Alice
to Bob via smart contract (running code that is not human-parsable) the terms
of which will transfer the token to Charlie if the DeFi reaches X. Neither
Alice nor Bob realise there could be an onwards transfer. Applying the subjective approach, Alice and Bob could claim they had
not agreed to the onwards transfer as it did not reflect their intentions. This
argument would not be available if the objective approach were applied. Taking
the objective approach, the facts would show that the code contained the
contractual terms that were exchanged between Alice and Bob.
The above examples indicate
that, whilst there are advantages to the objective approach in terms of
simplicity and contractual certainty, the disadvantage is the potential for
unjust outcomes to arise.[49]
35 If the main
advantage of the objective approach is legal certainty, then there are other
methods to achieve certainty including:
(a) introducing
a limitation period. On its expiry, counterparties would be barred from
claiming their consent was invalid. The limitation period could be: (i) a time
period; or (i) the subsequent transfer of the token. This would provide
certainty in the subsequent chain of transactions and mitigate the risk that
subsequent transferors were transferring assets that they did not have title to
(pursuant to the maxim nemo dat quod non
habet); and
(b) introducing objective elements to the
subjective approach. Such as reference to any human-parsable elements of
the written contract and/or other evidence showing the acceptance of the terms
such as by conduct.[50]
36 Adapting and applying Jersey law to prevailing market
conditions by judicial interpretation is important in a small jurisdiction such
as Jersey which has a relatively slim statute book. Sir William Bailhache[51] observed that volonté (the meeting of minds)—
“. . . result[s] from the
political liberalism of the age of reason and of the economic liberalism of the
19th century, where obligations imposed from outside should be as few as
possible. A man is bound only by his
will, and because he is the best judge of his own interests the best rules are
those freely agreed by free men . . . the same rationale appears
in the commentaries of Berault, Godefroy & d’Aviron on La Coutume Reformée de Normandie
. . . being published in 1684 . . .” [Emphasis
added]—
ie, volonté is what a man consents to being bound by. In this
way volonté and consent are
co-dependant because without volonté
there can be no consent.
37 One might
compare the fintech revolution with the “political liberalism” and “economic
liberalism of the 19th century” that Sir William mentioned. The
characteristics of economic liberalism are evident in the current market demand
for efficiencies and democratisation of capital markets, eg by reducing barriers to entry for retail investors.[52]
Of course, some obligations “from outside” (see quote above) are
necessary in the 21st century as, for example, regulators need to regulate to
help prevent money laundering and protect investors. This should not detract
from the central principle that, if counterparties have a will to contract
using a specific technology, they should not be prevented from doing so or from
being bound by that will—as envisaged by customary law on this point of
principle. The lack of a blockchain statute is of no consequence. In this way,
the spirit of customary law and the freedom of contract (both in terms of the
content of the contract and method of contacting) is as relevant to modern
commerce as it was in the 17th, 18th and 19th centuries.
38 The Jersey Law
Commission[53]
was critical of the customary law, citing difficulties including: (i)
inaccessibility of Norman texts; (ii) language barriers (with French being
regarded as “totally alien”); and (iii) ancient concepts remaining “frozen
in time”.[54]
It is submitted that, since the Commission reports were published, customary law
has become more, not less, accessible. The launch of the Jersey Law Course at
the Institute of Law (“IoL”) and the publication of the contract
law study guides have taught advocates and écrivains
a consistent view of Jersey contract law (among others) from a comprehensive
and accessible text.[55]
In addition, there is more case law and learned articles in the Jersey and Guernsey Law Review on these
topics. The salient provisions of customary law are contained in the study
guides and copies of Pothier and Domat and Fairgrieve’s comparative law
text on contract law are available to buy online. The way to avoid customary law
becoming “frozen in time” is to publish Norman texts (and
translations) so they can be studied and commented upon rather than treating
them as museum pieces.[56]
The translation of the Grand Coutumier and the proposed translation of
the Très Ancien Coutumier will assist in this regard.
39 The Commission
proposed to clarify the Jersey contract law by adopting of a statutory
framework modelled on the Indian Contract Act of 1872, essentially the adoption
of the English common law of contract.
40 To codify, by
extension, means that Jersey would adopt blockchain-specific legislation in
some form. Codification is challenging and a restatement may be a more
sympathetic approach as it enables a settled position on the law to be
pronounced without extinguishing the spirit of customary law. It is important
to keep the spirit of customary law alive as it enshrines into Jersey law an
inherent flexibility to be applied to changing market practice.
41 The rapidly
changing nature of the market requires any restatement to be future-proofed to
avoid the restatement being outdated by technological developments.[57]
This is relevant to contracting by smart contract (as they are increasingly
being seen as a credible means of contracting): numerous initiatives have been launched,
exploring blockchain solutions for standardised contracts such as ISDA[58]
and discussion around the digital future for syndicated loans.[59]
The restatement will need carefully to navigate between a subjective or
objective approach to contractual consent or a combination. This is because:
(a) as set out above, where smart contracts are
written only in programming code (internal contracts) they are not currently
human-parsable (this may change as technology develops). This means that humans
could not read, understand or approve the terms of the contract in order to
provide valid consent (as required for a meeting of minds taking the subjective
approach) unless a human-parsable translation is provided that prevails in the
event of inconsistency (external contracts);
(b) as smart contracts potentially enable
contracts to become more commoditised and standardised and less negotiated,
parties’ contractual intentions over standardised contracts may become
less nuanced. If so, it may be appropriate for less emphasis to be placed on
the parties’ subjective intentions and to follow a more objective
approach focusing on the written terms; and
(c) the objective approach seems to offer a more
certain outcome desirable for meeting the demands of business efficacy; but
(d) contractual certainty should not be achieved
at the expense of individualised justice. A blended approach may therefore be
the solution. A subjective element may become even more important in conserving
equity and justice and ensuring that contractual intention is reflected in
contractual terms if humans are bound to contractual terms written in code that
they cannot read or understand.
Remedies
42 One advantage of smart contracts is that they enable
faster transaction speeds. Consequently, it is foreseeable that remedies to
contractual disputes may be demanded at a similar pace to contract formation. There
may be a demand for faster rather than traditional legal remedies. As
arbitration can be more time and cost effective than legal proceedings, it may
be possible for an arbitration function to be incorporated into the consensus
mechanism on the blockchain. In such cases, the nodes participating in the
arbitration consensus would need to examine the evidence on an objective basis,
probably by looking only to the written material (including code) available on
the blockchain ecosystem and written submissions of the parties. If so, the
same approach taken to contract formation (subjective, objective or a blend)
may need to be applied to contractual remedies. This may also mean that even if
a subjective approach to consent in contract formation is retained, the process
to assess the evidence will create a hybrid approach.
43 In addition,
standardised remedies may develop to deal more efficiently with contractual
disputes (such as (i) a pre-agreed unwinding of the contract on certain terms;
or (ii) a quasi-arbitration to process claims, possibly automated or via the
consensus mechanics on the blockchain). If so, it is likely to be impossible or
impractical for the counterparties’ full subjective intentions to be
examined or accounted for in the remedial process. Consequently, the
requirements for contractual consent should include objective elements to
enable a consistent approach to be taken to contract formation and remedies,
for example, a consideration of the written terms of the contract.
44 The objectivity could be achieved in a manner similar to
that present in the French civil procedure where weight is placed on written
submissions and evidence rather than oral submissions.
45 The UKJTF had
a slightly different theory, that smart contracts would reduce the need for
legal intervention altogether because they “may prevent intentional
non-performance by a party and avoid or limit factual disputes and disputes
about interpretation of terms”.
Offer and acceptance
46 Returning to
the elements of contract formation, in the example of a smart contract
transferring a store of value from Alice to Bob in exchange for Ether, the
offer is made by Alice sending the terms of a smart contract to Bob which is
then accepted by Bob in transferring the Ether to the smart contract address. Further
examples include algorithmic trading and robo-investing, where computer
programs run algorithms reflecting a certain investment strategy to select
order terms to offer to the market[60] and the terms to accept. In both cases these are examples of acceptance
by conduct. The acceptance should be clear as there is no intervening
opportunity for the parties to negotiate terms.
47 In a public
blockchain, where parties are unknown to each other, negotiation is limited
given the limited ability for the parties to communicate outside of the
blockchain ecosystem. However, in a private blockchain, greater negotiation may
be possible.
Certainty
of terms
48 For a smart
contract to constitute a legal contract, it must have certainty of terms. This
is a logical component of the parties agreeing contractual terms that reflect
their intentions. In the smart contract context, where terms can be written
only in computer-parsable code (internal contract), the crucial point is
whether any material, non-human-parsable terms of the contract can be deemed
sufficiently certain to enable a valid contract to be formed. It raises the
question whether the terms need to be capable of being understood by the
parties. If the parties cannot read the terms of the contract, they cannot (i)
understand it; (ii) be certain of its terms; or (iii) check that the proposed
terms reflect their mutually agreed intentions.
49 This is
important because, if “certain” does mean “understandable”,
it could lead to different outcomes depending on whether the objective or
subjective approach to consent is taken. Taking the objective approach, once
the terms are accepted, a reasonable man would say that the parties had agreed
to be bound by the terms. Taking the subjective approach, no consent could be
given if the terms were not understood.
50 The type of
smart contract (internal or external) therefore affects the risk of this
uncertainty arising, for example:
(a) internal contract—where the smart
contract is written only in code and is not human-parsable, it is debatable
whether the terms have sufficient certainty. If certainty of terms simply means
to have identifiable terms, the UKJTF stated “there should be no difficulty in identifying terms (they will
comprise the source code)”. Identifying the
source code containing the terms is one matter, but it is quite a separate
matter to read and understand its terms sufficiently to enable a decision to be
made whether or not to be bound by them. Under Jersey law, so long as the
subjective approach to contractual consent prevails (notwithstanding the mixed
authorities on this point), there is an inference that to have certainty, the
terms should be understood (or at least be able to be understood) by the
parties. If a smart contract is written only in computer-readable code there is
arguably no certainty of terms for a source-code illiterate human unless there
is a human-parsable translation;
(b) where part only of the contract is written in
code and not human-readable, proving the certainty of terms may become pivotal
in the event of inconsistency between human-parsable and computer-readable
elements of the contract (as by extension it relates to proving that such terms
reflect the parties’ mutually agreed intentions). Although, per Prestige
if the inconsistency relates to a peripheral matter it should not be material[61];
(c) external contract—where the contract is
fully human-readable and some terms have been automated (eg payment of interest) certainty of terms would be easily
demonstrated.
51 The type of smart contract could become crucial because if
the terms do not coincide with the terms of the offer understood by the
parties, there is an erreur obstacle
(where there has been no meeting of minds). This goes to the very heart of the
contract. An erreur obstacle
can be as to (i) the nature of the contract; (ii) the objet of the contract; or (iii) the cause of the contract. If
any of these elements is absent, then the contract will be a nullité absolu.
52 Under French
law, there are two types of erreur
and two types of nullité that
arise:
(a) erreur
obstacle—where there is no meeting of minds and no contract is
formed; and
(b) erreur
leading to a vice de consentement
which “does not destroy consent: it merely negatives consent, or to
simplify again, the mistake concerns the validity of the contract”.[62]
53 Arguably, if
the parties cannot read the terms of the contract, they cannot: (i) understand
it; (ii) be certain of its terms; or (iii) ascertain whether the terms reflect
their intentions, and there is an inference that these requirements ought to be
present taking the subjective approach to contractual consent. This concern was
shared by Szabo who raised two concerns about contracts written in code: (i)
human counterparties not understanding the code and therefore the terms of the
contract; and (ii) the computer not carrying out the human counterparties’
intentions. Szabo cautions that the computer processing units involved in the
messaging (which run the smart contract) may or may not be acting in accordance
with the intentions of the human user.
54 This is a key
challenge to any purported “agency” relationship (however tenuous)
between human and computer.
55 Conversely,
following the UKJTF approach, it can be argued that the non-human-parsable
terms (the source code) would have sufficient certainty and, accordingly, that
the parties can intend to accept such terms irrespective of whether they
understand them. This would lead to clear outcomes but may lead to
difficulties, particularly if applied to contracts with members of the public.
56 For example,
Natwest Bank announced a blockchain project to record data in the house buying
process.[64]
Taken together with the HM Registry project to produce a blockchain land
registry, it is feasible to predict a future state where properties (including
residential properties) are bought, sold and mortgaged on the blockchain.
57 There are a
few simple practical solutions to make code or internal contracts
human-parsable:
(a) provide human-readable translations of the
code; and
(b) use pro-forma contracts in human-parsable
language. This could be embedded in the governance documents of the blockchain
protocol. This is ideal for simple contracts. A rider could be included for
non-automated negotiated terms to be populated. These would be qualitative
rather than quantitative terms (eg
payment terms) and would need not be reduced to code to: (i) be valid
contractual terms; or (ii) enable the parties to benefit from automation of the
quantitative elements; in both cases the human “translation” would
prevail.
58 Solutions to
this may become more established with the development of smart contracts which
are both human-parsable and computer-parsable. Mougayar[65] suggests that developments
will—
“. . . include user-friendly entry
points, like a Web browser. That will allow any business user to configure
smart contracts via a graphical user interface, or perhaps a text-based
language input.”
Human counterparties will then
be able to draft contracts in human language using software that codes the
automatable provisions into computer executable code. Such projects are
underway.
3.3.2
Capacity
59 If the
essence of a contract lies in consent,[66] each contracting party must
be capable of giving such consent. Under Jersey law, for natural persons, the
age of majority is 18.[67]
There is a presumption that persons aged 18 are capable of giving valid consent,
although certain medical conditions prevent the giving of consent.[68]
60 To mitigate
the risk of incapacity, private blockchain platforms could incorporate a gating
mechanism that checks age and capacity by incorporating some form of
self-certification or independent identity verification. This would not
mitigate the risk of the counterparty lacking capacity on other grounds, but
this is an accepted risk of dealing with retail clients in online or non-face-to-face
transactions. Public blockchains where parties are anonymous would be at risk.
61 Similar
solutions can be used for corporate entities verifying their corporate
existence which could be verified by reference to Public Registries and
authorised signatories.
3.3.3 Objet
62 Objet is a “party’s
obligation of performance under a contract: What a party promises to do under the contract
by way of performance / discharge of his or her obligations.”[69]
Objet must be (a) certain, (b) possible,
and (c) lawful.[70]
63 Objet relates to either a thing (res) or a service (factum).
64 Applying the
limbs to the example of the transfer of a token:
(a) the objet
is certain (identifiable)—it is the obligation to transfer the token, a res;
(b) as long as the token exists and there are no
transfer restrictions, the transfer will be possible; and
(c) if the token does not relate to an illicit
matter (see below) the transfer will be lawful.
65 Demonstrating
whether an objet is possible should
be straight-forward in a smart contract context. Smart contracts are described
as “auto-executing” because they can be programmed to perform tasks
when certain conditions are met. This feature makes smart contracts suited to
performing certain quantitative contractual terms (eg the transfer of tokens and payment of ether on a given date)
without further instruction by either party.
66 However,
usual contractual principles should apply where the underlying objet does not exist or is flawed. To
use examples given by Pothier,[71]
one cannot sell a horse (if it is dead) or a house in Orleans (if it has burned
down). Nevertheless, one can sell a “mere expectation”[72]
of something which does not yet exist (such as wine which may be made).
Therefore tokenisation (eg of real
estate developments or derivatives) should not present any novel issues.
Lawful
67 Factors
affecting whether the objet is lawful
relate to whether the objet of the
obligation is per se lawful. Under
Jersey law, this is interpreted as not unlawful.
68 Blockchain-related
assets, cryptocurrencies and other digital assets are not prohibited under
Jersey law[73]
as they are in some jurisdictions.[74] Digital assets should
therefore be subject to the same principles of legality under Jersey law as the
subject matter of any other contract, eg
digital assets relating to prohibited substances or sanctioned activities would
be unlawful and fail this limb.
69 It is likely
that being lawful includes meeting all relevant regulatory requirements. In the
context of a Jersey entity issuing a digital security, this may include the
issuer obtaining a consent pursuant to the Control of Borrowing (Jersey) Order
1958 (or future regulatory equivalent) and a consent pursuant to the Companies
(General Provisions) (Jersey) Order 2002[75] depending on the number of
security holders and number of persons to whom the offer is circulated. Cross-border
transactions will require a more extensive review of the global regulations in
jurisdictions for primary and secondary markets, on which the asset will be
available, particularly if issued/transferred on a digital asset exchange.[76]
70 Factors
relating to licit objet are relevant
to licit cause (see below) because a
transaction with an unlawful objet is
likely to have an unlawful cause:
“. . . thus in bilateral contracts
there is a fundamental interdependence between objet and cause. If
one party’s obligation lacks an objet,
then it is likely that the other party’s obligation will lack a cause.”[77]
3.3.4
Cause
71 The final
limb is (licit) cause. In Marett v
Marett[78]
cause was found to be the
reason for the contract, why it is that an obligation under a contract is owed.
72 Cause is essentially the rationale or
reason for the parties to contract. In practice, it is often explained to
foreign lawyers by likening cause to
consideration under English law;[79]
however, the Royal Court has firmly distinguished between the two.[80]
73 The concept
of cause fits blockchain transactions
of all types. By nature, a token on a blockchain transferring a store of value
or operating as a medium of exchange, operates on the basis of reciprocity. The
“value” transferred being anything from monetary value (eg the value ascribed to an ether) to
the value ascribed to the sharing of data.
74 The cause for a party contracting is the
rationale for contracting. Smart contracts should be subject to the same
principles of cause as any other
contract. The discussion above regarding certainty of terms is relevant here as
the terms ought to make the cause obvious.
75 In
considering Marett, the Court of
Appeal in Booth v Viscount intentionally
does not rule on whether cause is
assessed on an objective or subjective basis. Rather the court noted the
uncertainty in modern French law given that the new French Civil Code did not
require cause at all in the formation of a contract.[81]
76 Smart
contracts are not immune to cause
being negated by vice de consentement
(the usual exceptions to autonomy of will). There are three categories of vice de consentement:
(a) dol;
(b) violence, being (i) duress and (ii) undue influence, and
(c) erreur.
77 These are
discussed below in Section 4.
4. Do smart contracts help or hinder issues with consent and authority?
78 This section
addresses whether the fact that a contract takes the form of a smart contract
increases or reduces (or may increase or reduce) the occurrence of:
(a) defective or lacking contractual consent by
reason of a vice de consentement; and
(b) defective authority with computers running
code not authorised by the counterparties.
4.1 Vice de consentement
79 Pothier
stated that contractual consent must be given freely.[82] Impediments or defects to
such consent can result in the contract being capable of being set aside (vice de consentement) or being void ab initio (as if no consent had been
given at all).
80 According to
the court in Steelux Holdings Ltd v
Edmonstone,[83]
a vice de consentement is where there
is no consent, no meeting of minds between the parties, which allows the innocent party to treat the
contract as void. However, the Court of Appeal indicated in HRCKY Ltd v Hard Rock Ltd[84]
that the contract would be automatically void (rather than merely treated as
void).
81 In a
blockchain context, it is arguably easier to demonstrate (objectively) that
consent to contract has been freely given, in particular if certain features
are incorporated into the blockchain ecosystem such as:
(a) click-through screens—requiring
acknowledgement of, and consent to, terms of use and terms of the contract
(assuming they correctly translate the underlying code);
(b) evidence to demonstrate computer access time
and location of both parties;
(c) in relation to a private blockchain network,
identifying counterparties before being granted entry to the platform and
confirming any relevant matters (such as intention to contract; capacity;
receipt of legal advice; or that the parties are not known to each other etc); and/or
(d) a two-stage consent, eg consent is given on one page and re-confirmed on a second page.
82 However, even
incorporating such features does not guarantee that the parties have freely
agreed to the terms (ie free from
duress or fraud) or that those terms reflect their intentions or will. Key
elements of vice de consentement are
briefly discussed below alongside an evaluation of how smart contracts could
heighten or mitigate the risks of these exceptions occurring:
Dol
(fraudulent or false conduct)
83 If a
counterparty is induced to contract by fraudulent or false conduct (dol) or some other “artifice”
the contract will be void. The Court of
Appeal in Hard Rock[85]
held that where a contract is induced by dol
it will be void and every clause will fail. Whittaker[86]
determined that “dol”
includes fraudulent misstatements.
84 Smart
contracts must be subject to the same principles of dol as traditional contracts. The type of dol most relevant to smart contacts is fraudulent misstatements (eg where a misstatement is made
off-chain, but affects a smart contract where the code does not constitute the
entire agreement between the parties).
85 From an
evidential perspective, smart contracts can assist by recording statements made
on-chain and identifying whether a statement has been embedded in a chain of
transactions.[87]
For example:
(a) all documentation including marketing
information (teasers, heads of terms, circulars, offering memoranda etc) can be stored and accessed by
counterparties and potential counterparties on-chain. This would clearly show
all written statements made;
(b) in a private blockchain context, advisers (eg lawyers and tax advisers) can take
part in the consensus mechanism and confirm they have approved or verified the
transaction material;[88]
(c) oracles (see para 129) can be used to confirm
certain matters of fact have occurred, eg
the FTSE index or the NASDAQ DeFi index has reached a certain level; and
(d) in a chain of transactions, the full
transaction history (and documentation) can be made available, thereby reducing
the potential for data to be incorrectly transcribed.
86 Each of
the above examples is also relevant to erreur (see below).
87 Given
the ability for transaction history to be stored on-chain and for misstatements
to be included in documentation used in chains of transactions, smart contracts may be at
increased risk of misstatements. The original
misstatement may be either: (i) an innocent representation made on the basis of
a mistaken belief thought to be correct and may result in the other party’s
consent being vitiated on the ground of erreur;
or (ii) made with the intention to defraud and be dol (see also erreur at para
89).[89]
Subsequent misstatements contained in subsequent transactions, if made by
innocently replicating misstatements contained in earlier transaction documentation,
would likely vitiate consent on the ground of erreur. These are the same risks that apply today in traditional
contracts and would be dealt with in the same manner.
Violence
88 There are two
principal types of violence: (i) duress; and (ii) undue influence. In
each instance, a smart contract should be subject to the same arguments
regarding duress and undue influence as a traditional contract. Consequently,
smart contracts will be affected by the same inconsistencies in case law in
this area (as to whether the English or French approach should prevail) as a
traditional contract.
Erreur
89 The two types of erreur are: (i) erreur sur la personne;
and (ii) erreur sur la substance and should apply equally to smart contracts as for traditional contracts
save that some features of blockchains could mitigate
the risk of erreur sur la personne arising.
90 Erreur sur la personne only applies where the identity of the contracting
party is the main cause for the contract. Given the anonymity
of counterparties in the public blockchain context, erreur sur la personne is
unlikely to arise. In the private blockchain space, however, this would follow
the same principles as a traditional contract. Features can be built in to the
blockchain protocol to mitigate this risk by verifying the identity of
counterparties.
Jersey
law on misrepresentation
91 Irrespective
of the substantive law in this area, and whether or not it is a separate area
of law relating to pre-contractual discussions, such substantive law should
apply equally to smart legal contracts as to traditional contracts.
92 Following Hard Rock, the fact that a vice de consentement (whether that be dol, erreur
or misrepresentation to the extent misrepresentation may exist in Jersey law)
makes a contract void, highlights the importance of including in a smart
contract:
(a) representations and indemnities to deal with
misstatements, in particular when dealing with assets which are frequently
traded (at risk of prior representations causing previous contracts
transferring the asset to be void);
(b) a mechanism dealing with the practicalities of
unwinding the contract in the event of a misstatement or incorrect
representation to return the parties to their pre-contractual state. For
example, in the context of a digital asset, code automating the re-transfer of
the asset to the seller and a refund of the payment to the buyer; and
(c) an arbitration mechanism in the event of a
dispute or claim of vice de consentement.
93 Traditional
remedies in the courts would of course remain available to the parties, but an
in-built mechanism may be a practical means of resolving simple disputes
quickly and cost-efficiently.
4.2 Defective authority
94 The potential physical separation of counterparties in the
smart contract context is not novel. Pothier specifically contemplated that
people could contract remotely by: (i) letter; or (ii) through the intervention
of an agent per epistolam, aut per nuntium[90] (by letter or by
messenger).
Are computer programs forming smart contracts “agents”?
95 Taking the second example, “intervention of an agent”,
there is a questionable line of opinion and legislation supporting the notion
that the smart contract is an agent for the human operator.
96 The argument
in support of this notion is that: (i) smart contracts on Ethereum each have an
address and can store value or data; (ii) the networked computer running programs operated by the human operator
is the agent for the human operator; and (iii) the smart contract is autonomous
(self-governing) insofar as it is only controlled by the code. It is this
autonomy that distinguishes smart contracts from other technologies (such as the internet, which is
simply a medium allowing parties to communicate, but, where the parties remain
in control). However, the smart contract is not fully autonomous, it is simply code run on a network of computers and controlled by the code. The
fact that a smart contract has an address and can store value does not mean
that it owns the value it holds. It is similar to (i) a bank account, with a
distinct number capable of holding a balance for someone; or (ii) a humble
vending machine, holding cans until purchased. Accordingly, the smart contract is not capable of being appointed as an
agent.
97 Szabo[91]
rightly expressed a concern about humans not understanding the underlying code
controlling the smart contracts. In writing about smart contract protocols he
observed that:
“A protocol in computer science is a sequence
of messages between at least two computers . . . These programs act
as proxies, or agents, for human users, who communicate their preferences via
users’ interfaces. We distinguish protocol endpoints by names such as ‘Alice’
and ‘Bob’ . . . which may or may not be under the control
of, or taking actions contrary to the intent of, the human user.”
98 This concern
is amplified applying the objective approach to contractual consent as this
focuses on the written contractual terms (rather than intentions) which may be
concluded between the parties’ “agents” (computer programs)
and contain terms or have consequences that neither party intended. This would
be exacerbated where parties cannot identify each other in order to make
contact and independently verify their respective intentions.
99 As Szabo
observes:
“Human users typically do not have full
knowledge of the protocol in question, but rather a metaphorical understanding
. . . Unlike most real-world contracts, protocols must be unambiguous
and complete.”
100 A party’s
“metaphorical understanding” (or lack of understanding) of the code
may present a challenge to the purported “agency” relationship as
it exposes the principal to the risk of being bound to unintended consequences
resulting from that code. This underlines the importance of parties receiving a
human-parsable translation of the code so as to form contractual intentions
(whether subjective, objective or a mixture) and the extent of the authority
given to the agent. Some jurisdictions,
eg Guernsey, are comfortable with this risk and recognise computer programs
as electronic agents and the resulting contracts formed by such electronic
agents, even where the human counterparties had not read the code. The
advantage of accepting this risk is the resulting contractual certainty.
Guernsey
Ordinance
101 Guernsey has adopted legislation that recognises smart
contracts are concluded using an electronic agent.[92] The Electronic
Transactions (Electronic Agents) (Guernsey) Ordinance, 2019 (“the
Ordinance”) recognises electronic agents can conclude contracts and
provides that such a contract:
“shall not be denied legal effect, validity, enforceability
or admissibility solely because its making, formation, creation or delivery
involved the action or use of one or more electronic agents.”
This appears progressive,
but using electronic agents to form contracts is not without risk and appears
unnecessary.
102 The
Ordinance provides that contracts can be formed either: (i) among electronic
agents;[93]
(ii) between an electronic agent and a natural person;[94] or (iii) with information
in electronic form:[95]
“where no natural person was aware of, or reviewed, the electronic agents’
actions or the resulting terms”[96] or reviewed such
information.
103 This gives a statutory recognition to the practice of
counterparties accepting terms and conditions (“T&C”) that they
have not read. These statutory provisions potentially diminish the significance
of contractual consent (by deeming it to have taken place where no human has
had the ability to review the terms of the contract). There is a difference
between choosing not to review T&C and not being able to read T&C (eg if not human-parsable). Whilst
parties are clearly free to choose to contract even when not able to read the
T&C, it is not without risk. If smart contracts become a prevalent method
of contracting (especially with members of the public), this approach could
have significant risks. For example, an individual may acquire a token (via
smart contract) that results in losing his/her life savings. This creates a curious new form of agency where:
(a) the agent (the code) is not a legal person;
(b) the agent’s actions are limited to
running pre-determined code and consequently the agent is unable to exercise
any discretion;
(c) the principal is unaware of the extent of the
authority delegated to the agent if the principal does not understand the code
being run.
104 Bowstead &
Reynolds[97] (the English law
authority on agency adopted as authority under Jersey law)[98] define “agency”
as:
“ . . . the fiduciary relationship
which exists between two persons, one of whom expressly or impliedly manifests
assent that the other should act on his behalf so as to affect his legal
relations with third parties, and the other of whom similarly manifests assent
so to act or so acts pursuant to the manifestation . . . ”
This definition clearly
demonstrates that the agent must be: (i) a legal person; (ii) a fiduciary;
(iii) appointed and authorised by the principal to affect legal relations; and
(iv) able to act in accordance with such appointment and authority. The
Ordinance meets only half of these elements: the first two elements are absent;
the third element is satisfied through deemed authority; the fourth is
satisfied because the actions of the agent (the code) are limited to running
the code, illustrating that “the manifestation”, the actual
authority, must encompass the terms of the code—potentially problematic
if the principal does not understand those terms. This raises the question of why
does the code need to be an agent? If parties chose to contract by running code
they do not understand, why do they need to be deemed to have appointed an
agent to do that (and nothing more) on their behalf.
105 The
Ordinance describes the electronic agent as acting “on behalf of a person”
and is deemed to be appointed as an agent authorised to contract on behalf of
the counterparties under the usual rules of agency in Guernsey. This aspect of
the agency relationship is consistent with English and Jersey law and, in the
contract law context, consistent with Chitty
on Contracts which provides that the agent is merely a medium through which
assent is given:
“A contract made by an agent as such, is, in
law, the contract of the principal. The agent is considered merely as the
medium by which the contract is effected; and his assent is merely the assent
of his principal.”[99]
If merely a medium to
effect a contract, under the Ordinance, the electronic agent must be deemed to
have such broad authority to contract on behalf of its principal that it is
unnecessary for the principal to be aware of the existence of any contract which
the agent concludes (or its contractual terms, ie the terms of the code). This is hard to justify when “the
manifestation”, the actual authority of the agent to act, must encompass
the terms of the code. If the agent has no discretion, is not a fiduciary and
has no function other than running the code as programmed, it is questionable
whether an agent is needed at all (particularly given the risks of a principal
being deemed to appoint an agent to run code and enter into contracts on terms
the principal does not understand). The central issue that this obfuscates is
the interaction between: (i) the parties’ understanding of the terms of
the contract; and (ii) contractual consent. When the developments in artificial
intelligence and Internet of Things technology[100] are overlaid with
electronic agency, it is foreseeable that once the rights of the principal (to
give actual consent to the contractual terms) are eroded, it may be difficult
for the principal to re-assert those rights.
106 The
Ordinance is noteworthy because it is commercially attractive from the
perspective of legal certainty and because Guernsey has a similar customary law
heritage to Jersey. However it is not recommended that Jersey follow this approach.
Such legislation would need to be constantly amended to keep pace with
technological developments. It is submitted that the recognition of an
electronic agent by the Ordinance is flawed.
107 Nevertheless,
Jersey can learn from the Ordinance. It would be helpful to state the elements
applicable to smart contracts and their recognition as smart legal contracts
(to give certainty to parties using the technology who will be bound). They
could include:
(a) contractual consent (subjective or objective
or a blend);
(b) a rebuttable presumption that the consent
given was valid—in reality this would follow a fairly objective approach
to consent and look to objective evidence to show the parties’ consent
had been given (eg by way of a
click-through screen); and
(c) link any rebuttal of that presumption to the
usual grounds for defective consent under Jersey law (ie whether there was a vice
de consentement).[101]
The period for rebuttal should also be time-limited. For a contract for the
immediate delivery of a digital asset then the period for rebutting the
presumption should be low, eg five
business days.
108 The above
elements would enable some subjective elements to be blended with the otherwise
fairly objective approach needed to give sufficient certainty to the parties
contracting. Maintaining a subjective element is desirable because, if
contracting by smart contract does become market standard, individuals and, in
particular, vulnerable persons, will need protection from an overly objective
approach if, for example, the contracts affect material matters such as their
life savings. The FCA appears to have similar concerns having banned the sale
of crypto-asset derivatives to the retail market.[102]
Can
computer code hold assets?
109 The idea
that smart contracts “hold” digital assets in quasi-custodial and escrow
arrangements has led to the argument that the code must therefore be an agent. BIS
questions this, giving the example of smart contracts where digital assets are
held suspended (not held by either party) and where programmers assert it is
held by the contract, rather like a vending machine storing and dispensing cans
on payment of monies.
110 In law, there are rules
concerning the ability to transfer title to assets. Title to an asset typically
remains the seller’s until the buyer complies with certain conditions. In
an escrow arrangement, an escrow agent may hold an asset for the seller until
the conditions are met, whereupon it is held for the buyer on new terms. In the
smart contract context, the terms of the code (the contract) could provide for
the asset to belong to the transferor until such time as the transfer
conditions are met, whereupon the ledger would update to reflect a change of
ownership. It is submitted that the smart contract need not be an agent to do
this.
Is
computer code a separate legal entity?
111 BIS noted that certain players in the European Commission
advocate the smart contract being its own legal entity. This is a step further
than the electronic agency position under the Ordinance.[103]
Recognising code as a separate legal entity seems to be unnecessary. A smart
contract is code. Code is unable to owe fiduciary duties or to be liable for
its actions and omissions. Code will simply run as written (or not, if the code
contains an error) and does not need legal personality to do that. By way of
comparison, words in traditional contracts are not given legal personality; they
simply describe contractual rights and obligations. To suggest otherwise is a
legal absurdity.
112 Legal personality is given to natural persons with
capacity and to legal persons (ie
bodies corporate) which are given this status.[104]
Laws state what the constitutive documents of the legal person should contain
and what statutory obligations the legal person owes to its members. As these
are creatures of statute, they require a natural person to carry out
decision-making or generally to act on their behalf, eg directors (who in turn rely on natural persons, if a corporate
director). Those decision-makers derive their power from the constitutive
documents, statute and general law and, in turn, owe fiduciary duties to the
legal person. None of this seems to work if legal personality is ascribed to
code. Logic should not be thrown to the wind by the introduction of novel and ill-considered
legal concepts in order to fix a non-existent problem (eg recognising code as an agent or giving it separate legal
personality, when neither is required for smart contracts to function).
113 It is, however, plausible that legal personality or
fiduciary duties could apply to a blockchain ecosystem, or decentralised
autonomous organisations (“DAOs”), or to node operators. Requirements
could be introduced for DAOs to meet minimum standards for protocols and bye-laws
including placing fiduciary duties on the node operators who validate and
participate in the consensus mechanism,
eg to act independently, with due care and skill, and bona fide. This approach would also enable governments and
regulators to ensure that key rights and obligations are dealt with in the
blockchain protocol and ecosystem, eg
by requiring certain minimum technical standards to be met, including as to
security; or by requiring minimum rights and obligations to be contained in the
terms of use of the protocol or resulting smart contract code. In addition, in
relation to tackling money laundering and CFT, this could be achieved by (i)
requiring network participants and their location to be identified; (ii) requiring
insurance; or (iii) incorporating a feature to protect rights relating to the
sale of goods and services (such as a time period within which the contract can
be reversed to deal with a statutory return policy).
Smart
contracts are messages
114 As quoted
above, Pothier contemplated contracting remotely by letter.[105] Contracting by letter
involves an exchange of messages. The exchange of messages is central to the
conclusion of smart contracts. In listing the characteristics of smart
contracts, Mougayar[106]
refers to smart contracts as “software code representing business logic
that runs a blockchain”,ie
computer to computer messaging, via code. It therefore appears that smart
contracts are simply an evolution in letter-writing. We have seen an evolution
in messaging technology before: from letter to email.
115 One novel
feature of smart contracts is their apparent autonomy. However this autonomy
should not be overstated. Mougayar[107] notes that “[t]hey
are closer to an event-driven construct, more than artificial intelligence.”
If so, the perceived autonomy seems exaggerated and in practice it simply means
that code can be written to effect certain quantitative outcomes in certain
quantitative circumstances.
4.3 Concluding contracts electronically
116 As a medium for messaging in electronic form, the code
underlying a smart contract (intended to give rise to a legal contract) and its
deployment on a blockchain network is “electronic communication”
pursuant to the Electronic Communications (Jersey) Law 2000 (“ECJL”).[108] Below is an
analysis of how ECJL enables contracting by smart contract (although amendments
to the Law are recommended).
117 Smart
contracts fall within the scope of ECJL because the code of the smart contract
and manner of its deployment are “a communication of information
transmitted in electronic form” (art 1).
Accordingly, an offer and acceptance can be
expressed by means of electronic communication for the formation of a smart
contract (art 4).
118 For the
purposes of art 8(1), the blockchain protocol would be the “information
system” distributing the source code of the smart contract (the
electronic communication) which operates automatically.[109] In this way, ECJL deals
with “self-executing” contracts in the same way as contracting via
email, without needing to establish an agency relationship (unlike the
Ordinance).
119 In terms of
contractual consent, art 8(4) ECJL allows the counterparty to assume that “the electronic communication received was what its
originator intended to dispatch, and to act on that assumption.” In
other words, there is an allowable assumption that the source code of the smart
contract reflects the intended terms of the originating party. If the
counterparty accepts those terms, there should be a “meeting of minds”
sufficient to constitute consent. In this
way, and if the requirements of art 8 are satisfied, ECJL makes a clear
statement that the parties (dealing directly) can be assumed to intend the
terms communicated; ie the terms of
the source code accepted by the counterparty represented the originator’s
intentions. ECJL therefore supports the centrality of consent and the meeting
of minds.
120 In terms of
concluding the contract, the use of the public–private keys represents
the parties’ signature to the smart contract and the act signifying the
acceptance by the parties of the terms of the contract. Public–private
key cryptography involves the generation of two sets of unique keys:
(a) public keys (which encrypt the message); and
(b) private keys (which decipher the encryption
enabling the parties to access the encrypted messaging contained on the code). It
is the private key which also fulfils the function of the signature—it
enables the sender of the message digitally to “sign” the message.
The typical analogy
regarding the key status is a bank account (the public key) and a PIN (the
private key) which enable access to the funds in the bank account.
121 On receipt
by the recipient counterparty, the recipient counterparty uses the originator’s
public key to verify the originator’s signature (which is done
automatically). Article 12 ECJL recognises the use of electronic signatures but
currently its application is limited to signatures in the case of “a person required by an enactment to provide
a signature . . .”
122 This is of
limited utility. The application is further limited by the requirement at art
12(1)(a) ECJL for a “method [to be] used to identify the person and to
indicate the person’s approval of the information communicated”.[110]
This requirement might be satisfied if the public–private key
cryptography method is deemed sufficient to enable a person to be “identified”
and demonstrate approval, although this will depend on whether a public or
private blockchain is used (given the pseudo-anonymity of parties on public
blockchains).
123 Potential
amendments to ECJL include:
(a) finessing art 12(1)(a) to capture contracting
by smart contract;
(b) bringing signatures to any document in scope (ie not limited to a signature required
by an enactment)—this would also cater for changes in legal practice
following COVID-19 and the marked increase of electronic signatures for
concluding contracts;
(c) whether
specific execution requirements and formalities (such as being witnessed by a
Jersey advocate (eg certain powers of
attorney and wills)) could be satisfied by electronic signatures for both the
signature and to verify the signature:
(i) a private
blockchain-based solution would appear to satisfy this—an advocate could
participate in the consensus to approve the transaction or update of the
blockchain once he/she has ensured that the relevant legal requirements have
been satisfied;[111]
and
(ii) Article 12(3) ECJL addresses
this to some extent by providing that:
“a
signature, seal, attestation or notarisation is not to be denied legal effect,
validity or enforceability only because it is in electronic form”; and
(d) a non-exhaustive list of acceptable forms of
electronic signatures, to give certainty to the market, eg click-through acceptance of terms.
124 Article 8
ECJL preserves existing legal principles by stating at art 8(7) that nothing in
that article affects the law of agency or the
law on the formation of contracts, meaning that art 8 ECJL can be applied in
parallel to the developments of such laws.
5. Contractual
remedies and unwinding smart contracts
125 This section
contains a discussion of:
(a) features of smart contracts that might assist
in contractual disputes; and
(b) potential new contractual remedies made
possible by DLT.[112]
126 The ease of
access to swift and cost-effective contractual remedies will become as critical
as the ease and efficiency of forming smart contracts. Increased transaction
speed could mean that transactions are not well-planned, resulting in more
disputes. It is therefore foreseeable that market practice will demand “self-help
remedies” to enable parties to deal efficiently with contractual issues
among themselves, eg including terms
at the outset for the automatic reversing of the contract or triggering the automatic
payment of damages, without requiring the parties to resort to the traditional
avenues of litigation which are costly and time-consuming (although these
options would remain available).
5.1 Features of smart contracts which may assist
in contractual disputes
Inherent audit trail
127 DLT and
smart contracts have an inherent audit trail. Mougayar[113] said:
“Smart contracts, being computer programs,
are just the enabling technology, but the consequence of their actions can be
made part of a legal agreement . . . A smart contract outcome could
be used as an audit trail to prove if terms of legal agreement were followed or
not.”
128 This
feature, together with art 9 of ECJL (which
allows evidence in electronic form to be given evidential weight), could
transform the disclosure process in litigation. Evidence would be readily
available, tamper-proof and less likely to be contested.
Oracles
129 Oracles are data feeds which verify real-world events or “values”
in a secure and trusted manner by transferring external data to the blockchain
for on-chain use. If used in a blockchain protocol, the computer running the
smart contract code can ascertain whether the pre-defined conditions have been
satisfied. In this way, oracles can transform legal contracts by independently
triggering the performance of certain terms of a contract (eg warranty claims or the payment of interest) when the oracle
confirms that a certain real-world event has occurred (the pre-defined
condition). This extrinsic data, once input by the oracle, can be captured
on-chain and: (a) cannot be disputed by the parties; and (b) may be used as
evidence in a contractual dispute. This may be particularly useful in avoiding
disputes relating to breaches of covenants, because oracles can be used to
trigger automated payments on blockchain. For example, in a construction
contract, oracles can prove weather conditions using data from off-chain
sources such as the Met Office. This can assist with construction delays by
proving weather conditions at the relevant time.
5.2 “Self-help” contractual remedies[114]
Rescinding contracts
130 Smart
contracts run in accordance with the source code. They are coded from the
outset and the code is immutable. A smart contract could therefore be coded
with certain event triggers which enable the contract to be rescinded (ie unwound so as to return to the status
quo ante). Event triggers could include:
(a) a failure to meet pre-set quantitative
standards;
(b) a failure of arbitration (traditional
arbitration or arbitration on-chain via the consensus mechanism);
(c) a limitation period (eg if no dispute is raised within 6 months, the contract cannot be
reversed in this manner). The passage of time could be monitored by an oracle.
These event triggers would
be effective in circumstances where the parties are anonymous because the smart
contract is simply running the pre-agreed code and parties do not need to
contact each other to resolve the dispute,
eg to serve notice in a traditional litigation context. However, this
remedy would not work for every type of contract, such as when specific
performance is warranted.
Reversing
131 A similar
remedy, but one requiring the parties to co-operate, is “reversing”.
Reversing took place following the 2016 DAO hack when a hacker stole 3.6
million ETH (worth $70m at the time).[115] Reversing restored the
on-chain activity to the position pre-hack. However, a survey by Vitalik
Buterin (Ethereum co-founder) showed reversing to be unpopular (60% responded “no”
to reversing). Reversing may be helpful where a chain of transactions is
affected by the same issue, eg a
misstatement in an offer document.
Liability
132 Contractual
disputes bring back into focus the question of where liabilities will lie. The
technology underlying smart contracts brings additional dimensions of
liability. For example, is the developer liable for erroneous source code?[116]
Are those participating in the consensus mechanism validating transactions also
accountable? As the technology matures and disputes are litigated, market
practice will develop to deal with these questions of liability. This may
include:
(a) new insurance products to insure against
liability;
(b) market standards for excluding liability; and
(c) market standards for security and performance
of the network.
6. Conclusion and recommendations
6.1 Evolution
not revolution
133 Contracting is in a new evolutionary cycle and smart
contracts appear to offer a credible method of contracting. Smart contracts enable contract standardisation and automation, a growing trend in various
types of contracts from ISDA master agreements to standard conditions of sale
(for properties). Smart contracts (and DLT more broadly) also assure the
integrity of transaction data and its storage by enabling the secure sharing of
data across a network of stakeholders and by maintaining a data audit-trail. Jersey
needs to embrace smart contracts to stay competitive in the global market.
134 Since smart
contracts are an evolution in contracting, the ordinary rules of contract law,
including customary law principles overlaid with ECJL, apply to smart contracts
without further statutory intervention, as they do to contracts concluded by
email or via the internet. Therefore, a legally binding smart contract
would need to satisfy all the usual elements necessary for any other contract. Principles
of customary law potentially give greater flexibility for the development of
law in this area than would the introduction of blockchain-specific
legislation, by enabling contract law to develop in parallel with technological
developments. Whilst elements of smart contracts are novel (the autonomy and
use of code), they should not change the fundamentals of what constitutes a
valid contract and the ordinary rules applicable to them.
135 Whilst the subjective approach to contractual consent
prevails, the following types of smart contract are capable of constituting
smart legal contracts (assuming the other elements necessary for a binding
contract are present):
(a) External smart contracts where human-parsable
and computer-readable terms co-exist, but the human-parsable “translation”
prevails;
(b) Basic internal smart contracts or those where
only peripheral or immaterial elements are inconsistent with human-parsable
terms;
(c) Other types of smart contract where immaterial
elements are automated or where a full human-parsable translation is provided
which will prevail over the code in the event of a conflict.
136 Ultimately,
all types of smart contract (internal or external) intended to be legally
binding may be capable of creating a valid contract if technology advances and
programs develop to enable all smart contracts to be coded using human-parsable
code. In the fullness of time, developments in the technology could give smart
contracts the ability to satisfy additional formalities, eg those reserved for wills.
137 As noted
above, smart contracts should be subject to the ordinary rules of contract law,
including their inherent inconsistencies. In some respects, smart contracts may
be more effective in addressing contractual issues: for example, demonstrating
consent using click-through screens; storing immutable evidence regarding
acceptance of contractual terms.
138 Ironically,
in the public blockchain context, two key mitigants to undue influence stem
from anonymity: (i) the anonymity or pseudo-anonymity of counterparties reduces
the likelihood of parties identifying each other and inflicting violence,
duress or undue influence;[117]
and (ii) parties may not find each other but are “matched” by an
algorithm, eg on a cryptocurrency or
digital assets exchange.
139 The nascence
of DLT (and therefore smart contracts) means that features and safeguarding
mechanisms can be introduced to tighten procedural elements of contracting on a
blockchain protocol. Governance
standards for DAOs, developers, users and blockchain protocols, could reduce
the ability of parties to attack the validity of their contractual consent; or
digital equivalents of execution requirements and formalities could be
embedded. Until regulators and legislatures understand and address the risks
and opportunities presented by this technology, the industry will be
self-regulating and rely on the good faith of developers and investors.
6.2 Emergence of global standards?
140 Perhaps
smart contracts present an opportunity to set international standards for
contracting and an international taxonomy. Whilst not specific to contracts but
relevant to DLT more broadly, the EU through its fintech action plan[118]
and proposed regulation on markets in crypto-assets (MiCA)[119] is promoting
standardisation in its internal digital market and streamlining DLT regulation.
Jersey should therefore maintain a watching brief on the international developments in this area and at
this stage avoid taking any potentially restrictive action beyond a
clarificatory statement that smart contracts are capable of fulfilling the
criteria for creating a valid contract, and those other actions recommended
below. If smart contracts are to service a global market, there will be
international pressure for a global solution, with jurisdictional variations,
to emerge. Financial and academic investment in smart contracts and DLT should
see a standardised approach and settled taxonomy emerge.
141 In the
meantime in Jersey, smart contracts remain subject to the ordinary legal or
regulatory analysis applied to traditional contracts, securities, property
rights or data. Whilst some features of the technology are novel and new asset
classes may emerge, as a development or digitisation of traditional products,
smart contracts should follow the ordinary approach making allowances for
technological advancements.
6.3 Recommendations
Statement of recognition
142 Jersey would
benefit from issuing a statement of its recognition of smart contracts. Any
restatement of contract law should extend to smart contacts to ensure the
consistent treatment of smart and traditional contracts. Any restatement should
retain the inherent flexibility afforded by customary law to navigate the
current uncertainties over (i) technological developments; and (ii) the
international treatment of smart contracts.
143 It is
recommended that any such restatement should:
(a) state that ordinary rules of contract apply to
smart contracts and adapt the customary law position to current market needs
allowing for technological advances;
(b) state the conditions for valid smart contracts
which could include:
(i) the requirement for a
human-parsable translation of any code;
(ii) the approach for contractual
consent (whether subjective, objective or a mixture);
(iii) a rebuttable presumption that
consent given was valid; and
(iv) a link between a rebuttal of that
presumption and the usual grounds for defective consent under Jersey law.
144 Similarly,
amendments to ECJL could increase uptake in the technology and potentially
revolutionise Jersey’s domestic affairs by facilitating the adoption of
blockchain-based registers.
Engagement
of legal profession
145 Currently
the legal aspects of smart contracts and related concepts are not widely
understood by technologists or lawyers, adding to the perception that there are
great risks in contracting by smart contract. Risks include defects in consent
(vices de consentement) and the
misguided electronic agency arrangements. This perception is reinforced by dicta from elements of the developer
community promoting the technology as “unregulated”, and by
criminals exploiting anonymity. Perceptions can change with education and
collaboration. Perceptions will also change as products from well-regulated
financial institutions come to market. The ISDA smart contract project is an
example of lawyers, developers and academics working together on a new
operating model for smart derivatives contracts which will drive market
acceptance in this area.
146 Indeed,
there are many features of smart contracts that would benefit Jersey’s
legal profession and finance industry more broadly (particularly in the private
blockchain context) including:
(a) lessening the KYC burden;
(b) increasing transaction speeds and efficiency
by automating certain diligence exercises for repeat transactions;
(c) automating performance of certain contractual
terms such as payment of fees and interest;
(d) automatically unwinding contracts in certain
circumstances; and
(e) assuring data integrity via the immutable
audit trail.
147 The Jersey
legal profession should engage with smart contracts. The spirit of customary law
accepts smart contracts as a viable manner of contracting for the continued
benefit and prosperity of Jersey. Long-established legal principles deal with many features of smart
contracts which are not novel. The law enabling
smart contracts to be recognised should be developed by the courts through
custom and usage in the traditional way.
Appendix:
Blockchain glossary
Set out below are a
collection of definitions and meanings in relation to terms used in the
article. Some meanings are not yet settled and the definitions should be treated
as clarificatory rather than prescriptive.
|
Address
|
Similar to a bank account number where your money is kept, Ethereum or
Bitcoin contract addresses are a line of characters or a QR code used to send
funds on Ethereum or Bitcoin respectively. The address represents the
location where the Ethereum or Bitcoin is stored. It is a hexadecimal notion
of the public key.
|
|
Algorithm
|
A sequence of computer code setting rules or giving instructions to a
software executer.
|
|
Bitcoin
|
Bitcoin is a digital or virtual currency that uses peer-to-peer
technology to facilitate instant payments. See the Bitcoin whitepaper for
more details.
|
|
Blocks
|
A block is a computer file that stores transaction data. It records
some or all of the most recent transactions that have not yet entered any
prior blocks. A block is like a page of a traditional ledger or record book.
|
|
Blockchain
|
Blockchain is distributed ledger technology; it is a decentralised
(does not require a central authority) database which can be accessed
simultaneously in identical form by participants (nodes) on a network. It is
a growing chain of records—each block is a transaction or a set of
transactions.
|
|
Blockchain ecosystem
|
The sum of all the parts that make up the blockchain community which
interact within and outside the system. It is a term which encompasses: the
network of nodes including mining nodes, the ledger, the protocol (and its
various layers), the on-chain transactions, the various actors including the
developers and various service providers such as exchanges and wallet
providers and people providing technical support, the DAO and its members.
|
|
Coin
|
A cryptocurrency or digital cash used as an exchange of value.
|
|
Consensus mechanism
|
The process whereby a mining node solves a computational puzzle set by
the system and validate the transaction. “Consensus mechanics”
should be construed accordingly.
|
|
Cryptocurrency
|
A digital currency for which encryption techniques are used to
regulate the generation of units of currency and verify the transfer of
funds, operating independently of a central bank.
|
|
Cryptocurrency token or token
|
A cryptocurrency token is designed to behave like a currency, being a
store of value and medium of exchange and referred to in certain
jurisdictions as a “payment token”.
|
|
Cryptocurrency wallet
|
A device, program, service or other physical medium that sends
receives and stores a person’s public/private keys for their cryptocurrency.
A cryptocurrency wallet is separate from the Blockchain and the actual
cryptocurrency is stored on the Blockchain.
|
|
Cryptography
|
The practice of secure communication using mathematical theories and
computation to encrypt and decrypt information.
|
|
DAOs or decentralised autonomous organisations
|
A DAO is an organization represented by rules encoded as a computer
program that is transparent, controlled by its members and not influenced by
a central government.
|
|
DAO hack
|
In June 2016, users exploited the DAO code and stole one-third of the
DAO’s funds (3.6m ether) to a subsidiary account. All the ether was
stored in a single address and was vulnerable to attack. The price of ether
dropped from over $20 to under $13. In July 2016, the Ethereum community decided
to hard-fork the Ethereum blockchain to restore virtually all funds to the
original contract.
|
|
DeFi
|
The NASDAQ market index dedicated to blockchain projects in
decentralized finance. The DeFI (or decentralised finance, DEFX) collects
market information on blockchain projects.
|
|
Distributed
|
Spread over several devices/computers in different locations.
|
|
Distributed ledger technology (DLT)
|
A digital system for recording transactions in which such transactions
and their details are recorded in multiple places at the same time. Unlike
traditional databases, distributed ledgers have no central data store or
administration functionality.
|
|
ERC-20
|
A technical standard used to issue and implement tokens on the
Ethereum blockchain.
|
|
ERC-721
|
A technical standard used to issue non-fungible tokens on the Ethereum
blockchain. The tokens are not interchangeable.
|
|
Ethereum
|
Ethereum is an open-source, blockchain-based, decentralised software
platform used for its own cryptocurrency, ether. It enables smart contracts
and distributed applications (DApps) to be built and run without any
downtime, fraud, control, or interference from a third party. For more
information about Ethereum see the Ethereum Whitepaper.
|
|
Ethereum addresses
|
See “Address”. The Ethereum address is specific to the
Ethereum blockchain and addresses are based on the Hexadecimal format (also
base16 or hex). They are anonymous, meaning that nobody can know if the
address belongs to a known person. Public keys are used to create Ethereum
addresses.
|
|
Exchange
|
A marketplace for buying and selling cryptocurrencies, security tokens
or digital assets.
|
|
External smart contracts
|
These are smart contracts with terms written in human-parsable
languages and prevail over the code where human-parsable and computer-readable
terms co-exist, but the human-parsable “translation” prevails.
|
|
ICO
|
Initial coin offering—a method of fundraising for new ventures
selling coins to investors.
|
|
|
|
|
Internal smart contracts
|
These are smart contracts with terms where the code either: (i) represents
the whole agreement between the parties, superseding human-readable clauses
which are considered explanatory; or (ii) represents only part of the
contract, and supersedes the clauses written in human-legible language.
|
|
Ledger
|
A file recording a collection of transactions.
|
|
Mark-up language
|
A mark-up language is a computer language using tags to define
elements within a document. It is human-readable, meaning mark-up files
contain standard words in human language, rather than typical programming
syntax. While several mark-up languages exist, the two most popular are HTML
and XML.
|
|
Mining
|
The process of verifying and ultimately adding transactions to the
blockchain ledger, by solving a computational puzzle. This is undertaken by a
mining node. The first individual to solve the puzzle is rewarded with a
newly minted token/coin.
|
|
Network
|
A number of interconnected devices/computers.
|
|
Node
|
Devices/computers on the blockchain network which maintain the
blockchain and sometimes process transactions.
|
|
Non-security token
|
A non-security token can (broadly speaking) be broken into (i) utility
tokens; and (ii) cryptocurrency tokens.
|
|
Off-chain
|
Transactions that occur off a blockchain network.
|
|
Public blockchain
|
Open, public blockchains are dubbed “trust-less” because
no central authority controls access and participation in the consensus.
Participants are incentivised to act honestly by being awarded tokens in the
ecosystem. This encourages participants to build a sufficient economic stake and
not to attack the protocol.
|
|
Oracle
|
A data source of feed from a trusted third party source used for
determining outcomes to smart contracts.
|
|
Parsable
|
Eg human-parsable, being the way humans analyse language in terms of
grammatical constituents, identifying parts of speech and syntactic
relations. This can be contrasted with computer-parsable, viz. how a
computer analyses language or text.
|
|
Participant
|
A device/computer that can access the blockchain and the data stored
on it.
|
|
Private keys
|
Private keys are used to sign blockchain-based transactions to send
and receive cryptocurrencies.
|
|
Private blockchain
|
Closed, private permissioned blockchains are used by a limited number
of trusted participants.
|
|
Public key infrastructure (private-public
key pairs)
|
Keys are generated in pairs: (i) the public key—a formula that
is relatively easy to encrypt, but practically impossible to decrypt; and (ii)
the private key—used to sign transactions and decrypt the data allowing
the user to transfer value.
|
|
Reversing
|
The process of reversing a blockchain ledger to change the state of
the ledger, eg following a hack, to
reinstate the ledger to the pre-hack position. A reverse hard fork is a
radical change to the network’s protocol and makes all previous blocks
and transactions invalid. It requires all nodes and users to upgrade to the
latest protocol software.
|
|
Security token
|
A security token would typically have the characteristics associated
with an equity or debt security in the traditional capital markets sense.
|
|
Smart contract
|
There is no settled definition of a “smart contract”. It
is computer code and not a contract per se in the legal sense. Smart
contracts can automate pre-defined tasks (so called
“self-executing”) and remove the requirement for intermediaries (eg paying agents escrow agents). It is
a computer program stating if “x” then “y”.
|
|
Smart legal contract
|
A smart contract which satisfies the elements necessary to form a
valid legal contract.
|
|
Source code
|
Computer code which is a collection of computer instructions and
statements for defining how software will function written using a
human-readable programming language.
|
|
Utility token
|
A utility token confers on the holder merely a usage right or the
right to access a product or service. Such token has no economic rights
attached to it and there is no expectation of a return.
|
|
White paper
|
In the blockchain context, the white paper is an authoritative paper
that informs readers (targeted at developers and investors) about the terms
of blockchain protocol or particular coin or token. In fundraising such as an
ICO or STO they are used by blockchain developers to explain their project (ie the problem they have identified,
the research they have undertaken and the solution that they have designed to
resolve it including the description of the product that they have launched,
it a digital asset this will be a description of the utility of the token or
coin that is being issued) to investors to assist investors in making an
investment decision.
|
Emma
German is a barrister and a solicitor of England and Wales (non-practising) and
an advocate of the Royal Court of Jersey. She is senior associate at Carey
Olsen Jersey LLP, 47 Esplanade, St Helier, Jersey JE1 0BD and runs an
innovation consultancy.