Smart Contract Templates: Foundations, Design and Research - The Semantics of Contracts

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.4 The semantics of contracts

Part of our remit is to consider the semantics of a contract — i.e. what is the “meaning” of a contract? We view a legal contract as having two aspects:

1. The operational aspects: these are the parts of the contract that we wish to automate, which typically derive from consideration of precise actions to be taken by the parties and therefore are concerned with performing the contract.

   
   

2. The non-operational aspects: these are the parts of the contract that we do not wish to (or cannot) automate.

We may approach the semantics of these two aspects of the contract in different ways. For example, with the operational aspects we may wish to compare a semantic analysis of the contract with a semantic analysis of the computer code — if it were possible to develop a proof for semantic equivalence[3], this could be used early in the development lifecycle to increase confidence and reduce testing and debugging effort. By contrast, for the non-operational aspects of the contract we may wish to conduct a range of different semantic analyses — e.g. to analyse different forms of risk associated with a contract.

A contract may comprise several documents, and the process by which these documents are agreed may be complex. The semantics of the non-operational aspects of even quite straightforward contracts can be very large and complex, yet by contrast the semantics of the operational aspects might be simple and easily encoded for automation.

The operational aspects of a contract would typically dictate the successful performance of the contract to completion. If a dispute arises, then the non-operational aspects of the contract would typically dictate what happens next — 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 contract partial-performance or non-performance by one party.

The greater part of a legal contract may often be devoted to defining the rights and obligations of the parties in the event of a problem. Sometimes, the actions to be taken in case of 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 understand the role of law. 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 non-operational aspects but also to the operational aspects — 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 automation by computer and therefore concerns itself only with performing those operational aspects that are expressed in the code, whereas

• smart legal contracts consider both the operational and non-operational aspects of a legal contract, some of whose operational aspects must then be automated (presumably 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 semantics of the legal prose) and the x-axis was the “Smart axis” of increasing performance richness (primarily concerned with the execution of smart contract code): see Figure 1. Both are important, yet they are orthogonal issues and with appropriate interfacing developments can potentially proceed along both axes simultaneously.

[3] Approaches to formal semantics include, for example, denotational semantics and operational semantics.