Table of Links

Abstract and 1 Introduction

2 Foundations and 2.1 Terminology — “smart contracts”

2.2 Automation

2.3 Enforceability

2.4 The semantics of contracts

3 Smart Contract Templates

3.1 Templates and Parameters

3.2 The design landscape for Smart Contract Templates

4 Summary and Further Work and References

2.3 Enforceability

Given a smart contract must be “enforceable” [15], 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 run successfully and accurately within a reasonable time. If the technology platform is in complete control of all of the actions of the smart contract code then these actions should occur faithfully and without undue delay. Things that could go wrong (and therefore require “enforcement”) include technical issues within the platform and issues that take place outside of the 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 include rights and obligations that accrue to the different parties 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 sequencedependent 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 of the contract.

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. 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 contract 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 enforcing the actions of smart contract code at a network level without the need for dispute resolution. 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” technology 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. For example, a “permissionless” shared ledger might make use of tamper-proof technology. Swanson [18] gives a good overview of many of the complex issues that arise with permissioned and permissionless distributed consensus systems. 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 defined to take the appropriate action in response to various dynamic states that might occur (such as another party defaulting on a required payment). In a truly unstoppable “tamper-proof” version of the system, all such possibilities would have to be anticipated and appropriate actions determined in advance.

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 “executive override” provisions. Agreements, once launched as smart contract code, could not be varied. But it is common for provisions of an agreement to be varied dynamically — for example, to permit a client to defer paying interest, 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 fulfilment 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 [14] 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.”