11 October 2019
What does “smart contract" really mean? In this article, I provide a brief (and very simplified) overview of what a contract is and how it’s formed. I also compare it to “electronic” contracts, discuss the difference between an “electronic” and “smart” contract, and examine how traditional contractual requirements translate – or not – to “smart” contracts.
What is a contract?
Treitel's The Law of Contract, succinctly summarizes contracts:
A contract is an agreement giving rise to obligations which are enforced or recognized by law. What distinguishes them from other legal obligations is that they are based on the agreement of the contracting parties.
Contract law in Singapore
Singapore is a former British colony and common law jurisdiction, and the law of contracts in Singapore is derived from and generally consistent with English law. Singapore’s law of contracts remains entirely based in common law and is not codified into statute.
The common law requirements for formation of a contract are well established:
An offer is an expression of willingness to contract on specified terms, made with the intention that it is to become binding as soon as it is accepted by the person to whom it is addressed.
Acceptance is a final and unqualified expression of assent to the terms of the offer.
A promise under an agreement must be supported by consideration in order to be enforceable. In substance, consideration is a benefit conferred by the promisee on the promisor, or a detriment incurred by the promisee, in exchange for the promisor’s promise.
A contract must be made with the intention of creating legal relations in order to be binding. The courts generally presume that agreements made in a commercial context are intended to be binding, but this presumption can be refuted if the parties expressly negative their intention to be legally bound. There is also a presumption that certain classes of parties do not intend to create legal relations, such as parties in parent-child or spousal relationships. Again, this presumption can be refuted by the parties’ clear expression of their intention to be legally bound.
Aside from the above, contractual formation also requires:
Consensus ad idem (the “meeting of minds”)
The parties to a contract must have a “meeting of minds”, or consensus ad idem. The “meeting of minds” refers to their shared and common understanding about the contract’s formation and terms.
Certainty and completeness
A contract must be certain and complete, at least in relation to key issues. If it is too vague, or if it does not contain key issues, it will not be enforceable. An “agreement to agree” (i.e. the parties agree to come to a future agreement) is also not enforceable, as provides neither certainty nor completeness in relation to the matter to be agreed upon.
For completeness, there are other factors affecting contractual formation, validity, and enforceability, such as duress and undue influence, illegality, and capacity to contract.However, an overview of the above factors will suffice for the purposes of analysing how “smart” contracts fit into the established common law framework of the law of contracts.
When is a contract formed?
A contract is generally formed when offer and acceptance have taken place.
What is an electronic contract?
There is no specific definition of “electronic contract” under Singapore law. However, the Electronic Transmissions Act (“ETA”) provides legal recognition of electronic records and electronic signatures. It also states that offer and acceptance can be made by electronic communications, and contracts shall not be denied validity or enforceability on the basis that electronic communications were used in their formation. In other words, the ETA gives effect to electronic contracts by requiring them to be treated the same way as written contracts.
What is a “smart” contract?
As with electronic contracts, Singapore law does not define what a “smart” contract is. The term was coined by Nick Szabo – a computer scientist, cryptographer, and legal scholar, who explained in his paper 1997 “Formalizing and Securing Relationships on Public Networks”:
In electronic commerce so far, the design criteria important for automating contract execution have come from disparate fields like economics and cryptography, with little cross-communication: little awareness of the technology on the one hand, and little awareness of its best business uses other. These efforts are striving after common objectives, and converge on the concept of smart contracts.
… The contractual phases of search, negotiation, commitment, performance, and adjudication constitute the realm of smart contracts. … Smart contracts utilize protocols and user interfaces to facilitate all steps of the contracting process.
The basic idea behind smart contracts is that many kinds of contractual clauses (such as collateral, bonding, delineation of property rights, etc.) can be embedded in the hardware and software we deal with, in such a way as to make breach of contract expensive (if desired, sometimes prohibitively so) for the breacher.
Szabo goes on to provide two examples demonstrating how the "smart contract" concept is a natural progression of existing solutions. His first example is an existing solution with a low order of automation:
A canonical real-life example, which we might consider to be the primitive ancestor of smart contracts, is the humble vending machine. Within a limited amount of potential loss (the amount in the till should be less than the cost of breaching the mechanism), the machine takes in coins, and ... dispense change and product according to the displayed price. The vending machine is a contract with bearer: anybody with coins can participate in an exchange with the vendor. The lockbox and other security mechanisms protect the stored coins and contents from attackers, sufficiently to allow profitable deployment of vending machines in a wide variety of areas.
Szabo's second example demonstrates a higher order of automation that allows for finer degrees of implementation using a "smart contract" solution.
... consider a hypothetical digital security system for automobiles. The smart contract design strategy suggests that we successively refine security protocols to more fully embed in a property the contractual terms which deal with it. These protocols would give control of the cryptographic keys for operating the property to the person who rightfully owns that property, based on the terms of the contract.
In the most straightforward implementation, the car can be rendered inoperable unless the proper challenge-response protocol is completed with its rightful owner, preventing theft.
But if the car is being used to secure credit, strong security implemented in this traditional way would create a headache for the creditor - the repo man would no longer be able to confiscate a deadbeat's car. To redress this problem, we can create a smart lien protocol: if the owner fails to make payments, the smart contract invokes the lien protocol, which returns control of the car keys to the bank. This protocol might be much cheaper and more effective than a repo man.
A further reification would provably remove the lien when the loan has been paid off, as well as account for hardship and operational exceptions.
In this process of successive refinement we've gone from a crude security system to a reified contract:
(1) A lock to selectively let in the owner and exclude third parties;
(2) A back door to let in the creditor;
(3a) Creditor back door switched on only upon nonpayment for a certain period of time; and
(3b) The final electronic payment permanently switches off the back door.
Vitalik Buterin, the co-founder and inventor of Ethereum, wrote in his 2013 whitepaper, “Ethereum White Paper: A Next Generation Smart Contract & Decentralized Application Platform”:
“Another important area of inquiry is "smart contracts" - systems which automatically move digital assets according to arbitrary pre-specified rules.”
We can gather from these explanations and examples, as well as general use of the term “smart” contracts, that a “smart” contract is about automating the transfer or control of digital assets according to pre-specified rules, and such automation can be used in a variety of ways in a commercial context, including ensuring commitment and performance by parties, and triggering remedies.
But this begs the more fundamental question – is a “smart” contract really a contract at all?
Is a “smart” contract an actual contract?
In order for a “smart” contract to be an actual contract, it must fulfill all the requirements for contractual formation.
The immediate question we encounter with “smart” contracts is – which part of the “smart” contract is the actual contract?
There are at least 3 possible permutations of where/how contractual terms may be set out:
Permutation 2: through the text that a user encounters in the application’s User Interface (“UI”) in the course of using and transacting through the application (the “UX Contract”)*, that may prompt the user to accept certain conditions, initiate steps in the transaction, or explain the purposes of particular steps (E.g. “Click here to send the seller your offer price”); and
Permutation 3: through the application code itself.
Distinguishing Permutations 1 and 2
The first two permutations are distinguished from one another based on when the user encounters the terms of the contract. TOUs, EULAs, SSAs, and other legal documents in Permutation 1 set out the terms of the agreement prior to the user engaging in a transaction on the application. By contrast, a UX Contract described in Permutation 2 establishes terms during transactions on the application.
Contractual formation via express legal documents
This is self-explanatory. Documents described in Permutation 1, such as TOUs, EULAs, and SSAs, seek to create an explicit contract between the contracting parties, and can be treated as any ordinary contract is treated.
Contractual formation via UX Contract
In order for there to be contractual formation via a UX Contract as described in Permutation 2 above, the text (collectively) needs to adequately describe and convey to the user all of the usual requirements of a contract, including offer, acceptance, consideration, etc, and it must be presented in a way that allows the user to reach consensus ad idem with the counterparty to the contract. The user journey would also need to be designed in a way that shows, whether express or implied, that the parties intended to contract.
In other words, the parties reach consensus ad idem through their understanding of and agreement to the text presented to them during their user journey as they use the application or transact through it.
Contractual formation via application code
In the absence of Permutations 1 and 2, we face another question – can a contract be formed on the basis of application code? More critically, since the contract (if any) is expressed through a programming language, can consensus ad idem be reached on the basis of the application code?
This turns on how well the parties understand the application code - if the parties are experienced programmers familiar with the coding language of the “smart” contract application, they may be able to understand the terms of the contract as expressed through the code, and achieve consensus ad idem. If the parties do not understand the code, consensus ad idem may not be possible.
Conclusions regarding contractual formation in “smart” contracts
It is clear that a contractual formation can be achieved in Permutation 1. This is as straightforward as contractual formation in any ordinary scenario.
It is also possible for contractual formation to be achieved in Permutations 2 and 3 if the requirements for contractual formation are met.
Further, while contractual formation in Permutation 3 is possible, such formation is improbable, because (a) Permutation 1 legal documents are commonplace so there would be no need to rely on application code for contractual formation; (b) most applications have explanatory text components for ease of use, which could collectively constitute Permutation 2 UX Contracts even in the absence of Permutation 1 legal documents, again removing the need to rely on application code for contractual formation; and (c) the likelihood that contracting parties will understand the application code well enough to reach consensus ad idem in Permutation 3 is low.
Can a “smart” contract be enforced?
“Smart” contracts” are often colloquially described as being self-enforcing. However, this is not always correct – it would be more accurate to describe “smart” contracts as self-executing.
Whether the application’s self-execution is also contractually self-enforcing depends on whether the application executes the terms of the contract correctly.
To assess this, we again turn to the question of where the contract actually lies.
Permutation 1: Contract in express legal document
If the contract is embodied in an express legal document, then it can be treated like any ordinary contract, and the self-executing application can be treated as merely a means to fulfilling the terms of the contract.
In such a scenario, the ordinary doctrines and remedies can be applied to remedy the failure of the application to achieve the promised outcomes under the contract.
Permutation 2: UX Contract
In this permutation, the terms that a user encounters in the course of interacting with the self-executing application can collectively be regarded as the terms of the contract.
As with Permutation 1, the ordinary doctrines and remedies can be applied to remedy the failure of the application to achieve the promised outcomes under the contract.
Permutation 3: Contract in application code
Assuming a contract is successfully formed in Permutation 3, the self-execution of the code would also be inherently self-enforcing.
In other words, there would be no difference or mistake arising between the intention of the parties embodied by the code, and the execution of that same code.
This is because, unlike most natural languages, application code generally leaves far less room for interpretation, and outside of machine learning, most applications are deterministic. Thus, the code simply does what it does, and if parties understand enough the code well enough to achieve consensus ad idem, they must also inherently accept that the code will produce the outcome that it has been coded to produce.
The above sequence of events is deterministic and self-explanatory with little or no room for misinterpretation (or any need for the courts to step in and interpret it).
So long as the application code functions as coded, it is difficult to imagine how parties might construct a claim that what was executed is different from what they had agreed to via the application code.
It is also unclear how the courts might respond to such dispute, partly because there is little or no jurisprudence addressing disputes about the intended outcome of deterministic and self-explanatory application code. *
Associate Director, BR Law Corporation
* Note: The recent case of B2C2 Ltd v Quoine Pte Ltd  4 SLR 17 is notable. There was no dispute in this case about whether the outcome of a piece of deterministic and self-explanatory application code reflected the parties’ contractual intentions as set out in the code. Rather, the High Court considered the doctrine of mistake in a scenario where one of the parties had coded a self-executing and deterministic algorithmic trading program. The contract proper was a Permutation 1-type contract, and the terms and conditions of use were set out on the Quoine website.
Post date. Edit this to change the date post was posted. Does not show up on published site. 11/10/2019
Subscribe to our Newsletter
Subscribe to our quarterly newsetter to keep up to date with a wealth of insights from the BR Law, BR Family Assets and BR Corporate services team.
The posts found in this Law Blog are not legal advice, nor are they given for the purpose of providing legal advice.
You should contact your lawyer for legal advice if you need legal assistance.