Smart Contract Templatesfoundations, design landscape and research directionsChristopher D. ClackCentre for Blockchain TechnologiesDepartment of Computer ScienceUniversity College LondonVikram A. BakshiInvestment Bank CTO OfficeBarclaysLee BraineInvestment Bank CTO OfficeBarclaysAugust 4, 2016AbstractIn this position paper, we consider some foundational topics regarding smart contractssuch as terminology, automation, enforceability, and semantics and define a smartcontract as an agreement whose cution is both automatable and enforceable. Weexplore a simple semantic framework for smart contracts, covering both operational andnon-operational aspects. We describe templates and agreements for legally-enforceablesmart contracts, based on legal documents. Building upon the Ricardian Contract triple,we identify operational parameters in the legal documents and use these to connectlegal agreements to standardised code. We also explore the design landscape, includingincreasing sophistication of parameters, increasing use of common standardised code, andlong-term academic research. We conclude by identifying further work and sketching aninitial set of requirements for a common language to support Smart Contract Templates.1 IntroductionThe aim of Smart Contract Templates [1] is to support the management of the completelifecycle of “smart” legal contracts. This includes the creation of legal document templates bystandards bodies and the subsequent use of those templates in the negotiation and agreementof contracts by counterparties. They also facilitate automated cution 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 by which acontract is cuted – that is a design choice for the template issuer, counterparties, network,etc. The intention is to interface with a wide range of cution plats. Smart legalcontracts could potentially be cuted as software agents operating on distributed ledgerssuch as Corda [2], Ethereum [5], Hyperledger [12], etc..Here we aim to make a practical contribution of relevance to financial institutions. Weconsider how contracts are written, how they are cuted, how they are enforced, and how toensure that the cution 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 notonly to financial institutions but also to lawyers, regulators, standards bodies, and policymakers. We hope that the issues and views raised in this paper will stimulate debate and welook forward to receiving feedback.Acknowledgements We would like to thank Clive Ansell ISDA, Ian Grigg R3 andDarren Jones Barclays for their helpful feedback.c Barclays Bank PLC 2016This work is licensed under a Creative Commons Attribution 4.0 International License CC BY.Provided you adhere to the CC BY license, including as to attribution, you are free to copy and redistribute this work inany medium or at and remix, trans, and build upon the work for any purpose, even commercially.BARCLAYS is a registered trade mark of Barclays Bank PLC, all rights are reserved.Electronic copy is available at http//arxiv.org/abs/1608.0077112 FoundationsIn order to lay the foundation for subsequent discussion, there are several topics that requireelaboration. Here we consider the key topics of terminology, automation, enforceability, andsemantics.2.1 Terminology “smart contracts”In [15], Stark gives an overview of the two different ways that the term “smart contract” iscommonly used1. The first is entirely operational in nature, involving the cution of software agents,typically but not necessarily on a shared ledger. The word “contract” in this senseindicates that these software agents are cuting certain obligations and may takecontrol of certain assets within a shared ledger. There is no clear consensus on thedefinition of this use of the term “smart contract” each definition is different in subtleways [18, 17, 16, 3]. Stark renames these agents as smart contract code.2. The second focuses on how legal contracts can be expressed and cuted in software.This therefore encompasses operational aspects, issues relating to how legal contractsare written and how the legal prose should be interpreted. There are several ideas andprojects which focus on these aspects such as the Ricardian Contract [7], CommonAccord[4] and Legalese [13]. Stark renames these as smart legal contracts.Given that there is no clear consensus on the terminology being used, it is important that weshould be clear in this paper. Here we prefer that the term “smart contract” should coverboth versions, so we adopt a higher-level definition based on the two topics of automation andenforceability, that are explored in depth in sections 2.2 and 2.3A smart contract is an agreement whose cution is both automatable and enforceable.Automatable by computer, although some parts may require human and control.Enforceable by either legal enforcement of rights and obligations or tamper-proof cution.This is sufficiently abstract to cover both “smart legal contracts” where the agreement is alegal agreement, which is then capable of automatic cution in software and “smart contractcode” which may not necessarily be linked to a al legal agreement, yet must be cutedautomatically. It simply states a requirement that the contract must be enforceable withoutspecifying what is the aspect being enforced; for smart legal contracts these might be complexrights and obligations, whereas for smart contract code what is being enforced may simply bethe cution of the code.Wefocusonsmartlegalcontracts, withtheexpectationthatitwillbepossibleforcutionto 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 codeand smart legal contract.22.2 AutomationWe have chosen to say that a smart contract “is automatable” rather than that it “isautomatically cuted” because in practice there are parts of a legal agreement whosecution might not be automatic and will require human and control. However, to bea “smart contract” we require that some part of the cution is capable of being automatedotherwise it is not “smart”.Automation is generally taken to mean being cuted by one or more computers. Thephrase “by electronic means” is a synonym. Our definition of smart contracts does not requirethat this automatic cution occurs on a shared ledger, though that is certainly a possibleand even probable of cution.As an example of how automation might be achieved using smart legal contracts, Grigg[9] presents the Ricardian Contract triple of “prose, parameters and code”.1 The legal prose islinked via parameters name-value pairs to the smart contract code that provides cution.We might for example envisage that an cutable software agent has been developed that willbe instantiated on a shared ledger and, once cution has started, will proceed to undertakevarious transfers of value in accordance with the legal prose. The parameters are a succinctway to in the code of the final operational details.The code in this case would be suitable for cution on a specific plat but we canimagine in the future that multiple plats could be targetted from a single contract.22.3 EnforceabilityGiven a smart contract must be “enforceable”, what are the elements that must be enforcedAnd how First we consider what must be enforced2.3.1 What to enforceWhat 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 cutesuccessfully and accurately to completion, within a reasonable time. If the cutionplat is in complete control of all of the actions that the smart contract codewishes to per, then these actions should be cuted faithfully and with reasonableperance. Things that can go wrong and therefore require “enforcement” wouldeither be technical issues within the plat, or issues that take place outside of thecution plat an obvious example would be the physical delivery of goods. For smart legal contracts, things can be considerably more complex. Typically alegal contract would have a large number of rights and obligations that accrue to thedifferentpartiestotheagreementandarelegallyenforceable. Theseareoftenexpressedincomplex, context-sensitive, legal prose and may cover not just individual actions but alsotime-dependent and sequence-dependent sets of actions. There may also be overridingobligations on one or more of the parties such that a lack of action could be deemed tobe a wrong-perance or non-perance.1https//en.wikipedia.org/wiki/Ricardian_Contract2This could for example be achieved by using the list of parameters to connect the legal prose to a set ofsmart software agents, e.g. one agent per cution plat.32.3.2 How to enforceEnforcement might be achieved via traditional or non-traditional s Traditional means of enforcement include a variety of dispute resolution s suchas binding or non-binding arbitration, or recourse to the courts of law. There is anestablished body of law, and the s by which parties can resolve disputes are wellknown. The traditional s are backed by the power of government as embodied inthe law, law-enforcement agencies and the courts. For illegal acts, courts are for exampleempowered to different extents, according to jurisdiction to impose fines, sequesterassets, or deprive the wrong-doer of liberty. For disputes relating to contracts, thecourts have extensive experience of adjudicating on issues of wrong-perance andnon-perance, of awarding damages or other reliefs as appropriate, and in some casesassisting in the enforcement of payment of damages. Non-traditional s of enforcement may also be imagined. For example, thereis currently debate and experimentation on the possibility of enforcing the cution ofsmart contract code at a network level without the need for dispute resolution either viaarbitration or via the courts. This is a fundamentally different notion of enforcement thatis often expressed in terms of “tamper-proof” technology, with the assumption that ina perfect implementation of the system wrong-perance or non-perance becomeimpossible.“Tamper-proof” cution is typically described in terms of distributed networks ofcomputers that are unstoppable and in a technological sense cannot fail regardlessof malicious acts, power cuts, network disruption, natural catastrophies or any otherconceivable event.3 With such a system, it is assumed that a software agent, oncestarted, could not be stopped. For truly “unstoppable” software agents, code must beembodied to take the appropriate action in response to various dynamic states that mightoccur such as another party not having sufficient funds to cute a required payment.In a normal system, the software agent might abort and the wrong-perance ornon-perance by a party would be enforced by traditional means; but in a trulyunstoppable “tamper-proof” version of the system, all such possibilities would have to beanticipated and appropriate actions determined in advance, so they are no longer deemedwrong-perance or non-perance but are instead anticipated states of the systemwith known resolution.Although some groups are actively pursuing tamper-proof smart contract code, our preferenceis for smart legal contracts that are enforceable by traditional legal s for reasonsincluding In a system with enforcement by tamper-proof network consensus, there would be no“cute override” provisions. Agreements, once launched as smart contract code, couldnot be varied. But it is quite common for provisions of an agreement to be varieddynamically for example, to permit a favoured client to defer paying interest by a fewdays, 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 atamper-proof system.3A tamper-proof network might be used to run a “permissionless” shared system [10] i.e. where anyonecan access the system and trusting a single party is not required. Swanson [17] gives a good overview of manyof the complex issues that arise with permissioned and permissionless distributed consensus systems.4 Enforcement by network consensus can only apply to the cution of obligations, or thercising of rights, that are under the control of the network. However, objects andactions in the physical world are unlikely to be under full if any control of the network. Mainelli and Milne [14] observe that smart contract code “that involved payments wouldrequirepostingcollateraltobecompletelyautomated. Thislocking-upofcollateralwouldlead to a serious reduction in leverage and pull liquidity out of markets. Markets mightbecome more stable, but the significant reduction in leverage and consequent marketdecline would be strongly resisted by market participants.”2.4 The semantics of contractsPart 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 beinterpreted We start with a simple semantic framework and view a legal contract as havingtwo interpretations41. 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, thisis concerned with cuting the contract.52. The denotational semantics this is the non-operational legal interpretation or“meaning” of the entire contract, including all of its obvious constituent parts andincluding any other legal documents that it references. This is the meaning that wouldbe given to a contract when a lawyer reads the contract.These two semantics do not consider different parts of the contract they are bothinterpretations of the whole contract, but with different aims.6A contract may comprise several documents, and the process by which these documents areagreed may be complex. The denotational semantics of even quite straightforward contractscan be very large and complex, yet by contrast the operational semantics might be simple andeasily encoded for automatic cution.The operational semantics dictate the successful cution of the contract to completion. Ifa dispute arises, then the denotational semantics of the contract typically dictate what happensnext7 i.e. in the context of the rights and obligations of the parties, the specification ofwhat remedies shall be applied in the case of partial-perance or non-per