Smart Contract Templates: foundations, design landscape and research directions( Part 1)
1 Introduction
The aim of Smart Contract Templates is to support the management of the complete
lifecycle of “smart” legal contracts. This includes the creation of legal document templates by
standards bodies and the subsequent use of those templates in the negotiation and agreement
of contracts by counterparties. They also facilitate automated execution of the contract and,
in the event of dispute, provide a direct link to the relevant legal documentation.
The templates and agreements may (or may not) be agnostic to the method by which a
contract is executed – that is a design choice for the template issuer, counterparties, network,
etc. The intention is to interface with a wide range of execution platforms. Smart legal
contracts could potentially be executed as software agents operating on distributed ledgers
(such as Corda , Ethereum , Hyperledger , etc.).
Here we aim to make a practical contribution of relevance to financial institutions. We
consider how contracts are written, how they are executed, how they are enforced, and how to
ensure that the execution of a contract is faithful to the meaning of the legal documentation.
We discuss these issues using reasonably straightforward language, so that it is accessible not
only to financial institutions but also to lawyers, regulators, standards bodies, and policy
makers. We hope that the issues and views raised in this paper will stimulate debate and we
look forward to receiving feedback.
Acknowledgements: We would like to thank Clive Ansell (ISDA), Ian Grigg (R3) and
Darren Jones (Barclays) for their helpful feedback.
2 Foundations
In order to lay the foundation for subsequent discussion, there are several topics that require
elaboration. Here we consider the key topics of terminology, automation, enforceability, and
semantics.
2.1 Terminology — “smart contracts”
In , Stark gives an overview of the two different ways that the term “smart contract” is
commonly used:
- The first is entirely operational in nature, involving the execution of software agents,
typically but not necessarily on a shared ledger. The word “contract” in this sense
indicates that these software agents are executing certain obligations and may take
control of certain assets within a shared ledger. There is no clear consensus on the
definition of this use of the term “smart contract” — each definition is different in subtle
ways. Stark renames these agents as smart contract code. - The second focuses on how legal contracts can be expressed and executed in software.
This therefore encompasses operational aspects, issues relating to how legal contracts
are written and how the legal prose should be interpreted. There are several ideas and
projects which focus on these aspects such as the Ricardian Contract, CommonAccord
and Legalese . Stark renames these as smart legal contracts.
Given that there is no clear consensus on the terminology being used, it is important that we
should be clear in this paper. Here we prefer that the term “smart contract” should cover
both versions, so we adopt a higher-level definition based on the two topics of automation and
enforceability, that are explored in depth in sections 2.2 and 2.3:
A smart contract is an agreement whose execution is both automatable and enforceable.
Automatable by computer, although some parts may require human input and control.
Enforceable by either legal enforcement of rights and obligations or tamper-proof execution.
This is sufficiently abstract to cover both “smart legal contracts” (where the agreement is a
legal agreement, which is then capable of automatic execution in software) and “smart contract
code” (which may not necessarily be linked to a formal legal agreement, yet must be executed
automatically). It simply states a requirement that the contract must be enforceable without
specifying what is the aspect being enforced; for smart legal contracts these might be complex
rights and obligations, whereas for smart contract code what is being enforced may simply be
the execution of the code.
We focus on smart legal contracts, with the expectation that it will be possible for execution
to occur using smart contract code. In addition to our definition of smart contract given above,
throughout the rest of this paper we also for clarity adopt Stark’s terms smart contract code
and smart legal contract.
2.2 Automation
We have chosen to say that a smart contract “is automatable” rather than that it “is
automatically executed” because in practice there are parts of a legal agreement whose
execution might not be automatic and will require human input and control. However, to be
a “smart contract” we require that some part of the execution is capable of being automated
(otherwise it is not “smart”).
Automation is generally taken to mean being executed by one or more computers. The
phrase “by electronic means” is a synonym. Our definition of smart contracts does not require
that this automatic execution occurs on a shared ledger, though that is certainly a possible
and even probable method of execution.
As an example of how automation might be achieved using smart legal contracts, Grigg
presents the Ricardian Contract triple of “prose, parameters and code”.
1 The legal prose is linked via parameters (name-value pairs) to the smart contract code that provides execution.
We might for example envisage that an executable software agent has been developed that will
be instantiated on a shared ledger and, once execution has started, will proceed to undertake
various transfers of value in accordance with the legal prose. The parameters are a succinct
way to inform the code of the final operational details.
The code in this case would be suitable for execution on a specific platform but we can
imagine in the future that multiple platforms could be targetted from a single contract.
2.3 Enforceability
Given a smart contract must be “enforceable”, what are the elements that must be enforced?
And how? First we consider what must be enforced:
2.3.1 What to enforce
What needs to be enforced is different for smart contract code and smart legal contracts:
• For smart contract code, the key requirement is that the code should execute
successfully and accurately to completion, within a reasonable time. If the execution
platform is in complete control of all of the actions that the smart contract code
wishes to perform, then these actions should be executed faithfully and with reasonable
performance. Things that can go wrong (and therefore require “enforcement”) would
either be technical issues within the platform, or issues that take place outside of the
execution platform — an obvious example would be the physical delivery of goods.
• For smart legal contracts, things can be considerably more complex. Typically a
legal contract would have a large number of rights and obligations that accrue to the
different parties to the agreement and are legally enforceable. These are often expressed in
complex, context-sensitive, legal prose and may cover not just individual actions but also
time-dependent and sequence-dependent sets of actions. There may also be overriding
obligations on one or more of the parties such that a lack of action could be deemed to
be a wrong-performance or non-performance.
2.3.2 How to enforce
Enforcement might be achieved via traditional or non-traditional methods:
• Traditional means of enforcement include a variety of dispute resolution methods such
as binding (or non-binding) arbitration, or recourse to the courts of law. There is an
established body of law, and the methods by which parties can resolve disputes are well
known. The traditional methods are backed by the power of government as embodied in
the law, law-enforcement agencies and the courts. For illegal acts, courts are for example
empowered (to different extents, according to jurisdiction) to impose fines, sequester
assets, or deprive the wrong-doer of liberty. For disputes relating to contracts, the
courts have extensive experience of adjudicating on issues of wrong-performance and
non-performance, of awarding damages or other reliefs as appropriate, and in some cases
assisting in the enforcement of payment of damages.
• Non-traditional methods of enforcement may also be imagined. For example, there
is currently debate and experimentation on the possibility of enforcing the execution of
smart contract code at a network level without the need for dispute resolution either via
arbitration or via the courts. This is a fundamentally different notion of enforcement that
is often expressed in terms of “tamper-proof” technology, with the assumption that in
a perfect implementation of the system wrong-performance or non-performance become
impossible.
“Tamper-proof” execution is typically described in terms of distributed networks of
computers that are unstoppable and in a technological sense cannot fail regardless
of malicious acts, power cuts, network disruption, natural catastrophies or any other
conceivable event.3 With such a system, it is assumed that a software agent, once
started, could not be stopped. For truly “unstoppable” software agents, code must be
embodied to take the appropriate action in response to various dynamic states that might
occur (such as another party not having sufficient funds to execute a required payment).
In a normal system, the software agent might abort and the wrong-performance or
non-performance by a party would be enforced by traditional means; but in a truly
unstoppable “tamper-proof” version of the system, all such possibilities would have to be
anticipated and appropriate actions determined in advance, so they are no longer deemed
wrong-performance or non-performance but are instead anticipated states of the system
with known resolution.
Although some groups are actively pursuing tamper-proof smart contract code, our preference
is for smart legal contracts that are enforceable by traditional legal methods for reasons
including:
• In a system with enforcement by tamper-proof network consensus, there would be no
“execute override” provisions. Agreements, once launched as smart contract code, could
not be varied. But it is quite common for provisions of an agreement to be varied
dynamically — for example, to permit a favoured client to defer paying interest by a few
days, or to permit a payment holiday, or to permit the rolling-up of interest over a period.
Unless every possible variation is coded in advance, none of this would be possible in a
tamper-proof system.
• Enforcement by network consensus can only apply to the execution of obligations, or the
exercising of rights, that are under the control of the network. However, objects and
actions in the physical world are unlikely to be under full (if any) control of the network.
• Mainelli and Milne observe that smart contract code “that involved payments would
require posting collateral to be completely automated. This locking-up of collateral would
lead to a serious reduction in leverage and pull liquidity out of markets. Markets might
become more stable, but the significant reduction in leverage and consequent market
decline would be strongly resisted by market participants.”
2.4 The semantics of contracts
Part of our remit is to consider the semantic construction of a contract — i.e. what is the
“meaning” of a contract? Does it have more than one meaning? How should a contract be
interpreted? We start with a simple semantic framework and view a legal contract as having
two interpretations:
- The operational semantics: this is the operational interpretation of the contract,
which derives from consideration of precise actions to be taken by the parties. Thus, this
is concerned with executing the contract.5 - The denotational semantics: this is the non-operational legal interpretation (or
“meaning”) of the entire contract, including all of its obvious constituent parts and
including any other legal documents that it references. This is the meaning that would
be given to a contract when a lawyer reads the contract.
These two semantics do not consider different parts of the contract — they are both
interpretations of the whole contract, but with different aims.6
A contract may comprise several documents, and the process by which these documents are
agreed may be complex. The denotational semantics of even quite straightforward contracts
can be very large and complex, yet by contrast the operational semantics might be simple and
easily encoded for automatic execution.
The operational semantics dictate the successful execution of the contract to completion. If
a dispute arises, then the denotational semantics of the contract typically dictate what happens
next7 — i.e. in the context of the rights and obligations of the parties, the specification of
what remedies shall be applied in the case of partial-performance or non-performance by one
party.
The greater part of a legal contract may often be devoted to defining the obligations and
liabilities of the parties in the event of a problem with execution. Sometimes, the actions
to be taken in case of a material breach of contract are expressed precisely; however, this is not always the case and dispute resolution may require a protracted process of negotiated
settlement, arbitration or court proceedings.
Furthermore, it is important to realise the important role of law. It is not possible to take
literally the doctrine that all one needs to know about a contract is contained within “the four
corners of the document”. A lawyer would read and understand the contract in the context
of the governing law — i.e. each legal document must be interpreted according to the relevant
law (corporate law, consumer law, etc) of its stated or inferred jurisdiction, and therefore the
semantics of that law must also be understood. It should be noted that the issue of law relates
not only to the denotational semantics but also to the operational semantics — for example,
trading with certain countries may be illegal due to government-imposed sanctions.
Given this semantic framework for the legal contracts that underpin financial instruments,
we can derive a different perspective of smart contracts:
• smart contract code focuses exclusively on execution and therefore concerns itself only
with the execution of those operational semantics that are expressed in the code, whereas
• smart legal contracts consider both the denotational and operational semantics of a legal
contract, whose operational semantics must then be executed (possibly by smart contract
code).
This idea was previously expressed in a slightly different way by Grigg [8], displayed as a
chart where the y-axis was denoted the “Ricardian axis” of increasing semantic richness (i.e.
increasingly capturing the denotational and operational semantics of the legal prose) and the
x-axis was the “Smart axis” of increasing performance richness (primarily concerned with
the execution of the operational semantics): see Figure 1. Both are important, yet they are
orthogonal issues and with appropriate interfacing developments can potentially proceed along
both axes simultaneously.
3 Smart Contract Templates
Smart Contract Templates provide a framework to support complex legal agreements for
financial instruments, based on standardised templates. Following Grigg’s Ricardian Contract
triple , they use parameters to connect legal prose to the corresponding computer code, with
the aim of providing a legally-enforceable foundation for smart legal contracts.
Complex sets of legal documentation can be augmented with the identification of
operational parameters that are key to directing the executable behaviour of the smart contract
code (in this paper we call these “execution parameters”) — the smart contract code is assumed
to be standardised code whose behaviour can be controlled by the input of such parameters.
Here we explore the design landscape for the implementation of Smart Contract Templates.
We observe that the landscape is broad and that there are many potentially viable sets of design
decisions. We therefore propose that a new domain-specific language should be developed
to support the design and implementation of Smart Contract Templates, and we conclude
this section by sketching some requirements for that language. The design of that language
has already begun, and we have given it the name “CLACK” — a Common Language for
Augmented Contract Knowledge.
3.1 Templates and Parameters
A template is an electronic representation of a legal document as issued by a standards body
— for example, by the International Swaps and Derivatives Association (ISDA). As illustrated
in Figure 2, a template contains both legal prose and parameters, where each parameter has
an identity (a unique name), a type, and may (but need not) have a value.
An agreement is a fully-instantiated template (including any customised legal prose and
parameters). The customisation of legal prose and parameters at this stage is commonplace
and results from negotiation between the counterparties. We also observe that it is common
for agreements to comprise multiple documents such as Framework Agreements (e.g. a Master
Agreement) with various Annexes (e.g. a Schedule) and Credit Support Documentation (e.g.
a Credit Support Annex). Thus, the legal prose of an agreement will be derived from that of
the template, but need not be identical, and similarly the parameters of the agreement will be
derived from the template but need not be identical.
Сontinuation in part 2