In the author's opinion, the Genesis Files is one of the most important chapters of the textbook. The history of digital currency demonstrates the philosophy behind the development of privately created digital money: [1] privacy, [2] anti-government, and [3] abolition of the bank as intermediary. However, as the Chapter speaks for itself, this supplementary material reviews Nick Szabo's "smart contract", as the latter is insufficiently covered in the text.
Smart Contracts: Nick Szabo
In the 1990's, Nick Szabo published at least three papers on what he called "smart contracts". [Nick Szabo 1994, 1996, and 1997] In his 1994 paper, the shortest of the three, Szabo states: "A smart contract is a computerised transaction protocol that executes the terms of the contract." [Szabo 1994] He states that the three primary objectives of "smart contracts" are: [1] implement common contractual clauses such as payment terms and liens, [2] minimise error both intentional and accidental, and [3] obviate third party intermediaries. A secondary objective is to reduce "transaction costs." The term "transactions costs" refer to costs incurred in making a market transaction that do not benefit participants to the exchange. They are sunk costs, that is, lost costs. Examples of "transaction costs" include search and information, bargaining, and enforcement.
Szabo cites examples of "some technologies that exist today that can be considered as crude smart contracts": e.g., electronic data interchange, point-of-sale terminals, and digital asset protocols. He also recognised the intersection of law and economics as well as the fusion of computer science and cryptography in the establishment of more complex "smart contracts". Further, he prompted the idea of the use of smart contracts for what he called "synthetic assets". The latter comprised various financial instruments such as bonds and derivative securities. Finally, he broached the concept of "smart property" - a combination of software and hardware, a smart contract embedded in tangible property.
The 1996 article entitled "Smart Contracts: Building Blocks for Digital Markets" starts with a review of contracts from a legal and economic perspective. He notes that the common law of contracts is a prerequisite to a free market economy and then proposes to design electronic contracts by incorporating common law principles in code. Szabo notes that algorithms and networks make possible this new way "to formalise relationships". [Szabo 1996] He then states: "A smart contract is a set of promises, specified in digital form, including protocols within which the parties perform on these promises".
The primitive ancestor to the "smart contract" is the vending machine, an illustration Szabo repeats in his publications. A vending machine contains products marked with a price, a medium to pay for the product, and a mechanism to return change, if necessary. In general, a contract is legally enforceable if an offer and acceptance contain exactly alike terms. In the illustration, the vending offers to enter into a contract with anyone having the money to buy the product. The machine displays a beverage marked with a price of $1. A person selecting this beverage and making a payment of $1 accepts the offer. The payment and delivery of the product are the performance. The vending machine is used to illustrate a precursor of the smart contract because the parties enter into a contract without a legal text.
Szabo, relying upon economic theory and the common law of contracts distills four objectives of contract design to use in smart contracts. First is observability, the ability of contract parties to monitor each other's performance. Second is verifiability, the ability of a party to prove the existence of the contract to a third party like an arbitrator. Third is privity, the rule that only parties to the contract have right and obligations towards one another - third parties are left out. Fourth is enforceability of contract terms. Szabo asserts that smart contracts can be built upon these four design principles by using cryptographic protocols, such as public/private keys and digital signatures.
Szabo then demonstrates how contracts may be "embedded in the world" through smart property. He gives the example of a lien on a car. Assume the purchaser had to borrow funds to make the car purchase. The lender has a lien on the automobile until full payment of the loan is made. A smart contract can enforce the lien holder's right upon default and can enforce the debtor's right to ownership upon payment. For example, if the debtor defaults on payment, the smart contract/property disables the vehicle - the software instructs the hardware built into the car to render the vehicle incapable of being started. Likewise, upon full payment to the creditor, any automatic lien mechanism is terminated.
The 1997 paper entitled "Formalising and Securing Relationships on Public Networks", the lengthiest paper, elaborates on ideas contained in the preceding two papers. However, the 1997 publication speaks of a "fourth cost revolution" where "civilisation must ... adapt to a radical new media". [Szabo 1997] The "fourth revolution" is the transition from the "static medium of written literacy on paper" to the "physics of cyberspace", radically different from the properties of paper. "Smart contracts" can be designed to cover the "contractual phases of search, negotiation, commitment, performance and adjudication". The vision of the evolved "smart contract" is predicated upon mathematically based protocols, eliminating trusted third parties and using computer networks for construction of contracts.
Post-Szabo Articulations of Smart Contracts
a. Harvard Law School Forum on Corporate Governance 2018
I quote the preliminary remark in its entirety. "Smart contracts" are a critical component of many platforms and applications being built using blockchain or distributed ledger technology. Below, we outline the background and functions of smart contracts, discuss whether they can be deemed enforceable legal agreements under contract law in the United States, and highlight certain legal and practical considerations that will need to be resolved before they can be broadly used in commercial contexts". In sum the Harvard publication does not define the term "smart contract" and, except for noting the ability to run on DLT, regrettably fails to advance on Szabo's vision.
The preliminary remark demonstrates the degree to which "smart contracts" have evolved since Nick Szabo first coined the term. In addition, the remark recognises that "smart contracts" are deployed on blockchain or distributed ledger technology. Finally, the remark demonstrates that not everything called a "smart contract" is a legally enforceable contract.
In view of the passage of time since 1997, it is worthwhile to revisit the definition of the term "smart contract". The authors state: "Smart contracts" is a term used to describe computer code that automatically executes all or parts of an agreement and is stored on a blockchain-based platform". It is not necessarily 'smart', an intelligent tool using artificial intelligence, or a 'contract', a legally enforceable agreement. This raises the question: what is it? The answer may reside in Vitalik Buterin's observation that it would have been better to call them "persistent text".
At the time of publication in 2018, smart contracts were extremely rudimentary. The authors stated that they were best suited for two types of transactions: [1] payment of funds upon triggering events, and [2] imposition of financial penalties if specified conditions were not satisfied. "At present the input parameters and execution steps ... need to be specific and objective. In other words, if "x" occurs, then execute step "y". [Harvard 2018] However, the authors, invoking "Amara's Law", noted that we tend to overestimate new technology in the short run but underestimate it in the long run. AI algorithms built into the code of "smart contracts" has the potential to make them intelligent.
The Harvard publication then considers the obstacles to wide-spread adoption of "smart contracts". Two types of contracts are considered: [1] code only, and [2] textual contracts supplemented by code. The first hurdle is that most parties to a contract will lack the technical ability to write code recording exactly the terms of their agreement. Parties need to rely upon a technical expert. This reliance involves making certain the technician understands the terms of the contract so that they may be transcribed to code without error. Parties also may insist upon a guarantee from the technician that the code does not contain errors. The technician may resist giving a warranty or may search for insurance, if the market provides policies against this risk. The parties and the technician probably will enter into a contract for services. Libraries of standardised "smart contracts" available from multiple providers may mitigate this initial obstacle.
Second, the "smart contract" may require off-chain data to execute its terms. The canonical method to transfer off-chain data to on-chain programmes is using an "oracle". An "oracle" is a trusted third-party that "retrieves off-chain information and then pushes that information to the blockchain at pre-determined times". [Harvard 2018] Use of an "oracle" raises other issues: [1] accuracy and quality of the data, [2] uniformity of the data, [3] an additional point of failure, and [4] a separate contract between the parties and the "oracle". It must be noted that data pushed onto to the chain must be validated by multiple nodes.
Third, if the total obligation of the parties consists of a standard text contract and a "smart contract", which contract takes priority in case of an inconsistency. Related issues are jurisdiction and venue. Jurisdiction means which substantive law governs the agreement. Venue means which place is used to adjudicate or arbitrate disputes. Parties may deal with these issues by specifying jurisdiction and venue, since "smart contract" running on distributed ledger technology cross multiple jurisdictions.
Fourth, parties may wish to amend or terminate the "smart contract". Technical flexibility exists but these features add another layer of complexity to "smart contracts".
Ethereum Smart Contracts
"Ethereum is a decentralised platform that can execute smart contracts". [Zheng 2017] Ethereum "smart contracts" are written in Solidity, Serpent, Low-level Lisp-like language, and Mutan, machine codes. Then the contract is loaded to the Ethereum Virtual Machine and runs. [Id.]
An Ethereum smart contract "is simply a program that runs on the Ethereum blockchain. It's a collection of code (its functions) and data (its state) that resides at a specific address on the Ethereum blockchain". [Ethereum 2021]
In an undated White Paper entitled "A Next Generation Smart Contract & Decentralised Application Platform", Vitalik Buterin defines "smart contracts" as "systems which automatically move digital assets according to arbitrary pre-specified rules".
A simple example suffices. Assume a farmer enters into a contract with a market to sell 100 ears of corn to be delivered upon a specific date in exchange for a payment of $100. The market, the contract creator, locks in its funds, and specifies the rules of execution, that is delivery and payment. If the farmer delivers the corn as required, the smart contract releases the funds to his account. If the farmer fails to deliver or delivers late, then the contract is canceled and the funds are reversed to the client.
Buterin recognised the potential of smart contracts for financial derivatives. Consider an interest rate swap, "where Party A agrees to pay Party B each month an amount equal to 5% of notional amount X, and Party B agrees to pay Party A each month an amount equal to some floating rate of interest of notional amount X". [Jenny Cieplak and Simon Leefatt 2017] Party A is betting that the floating rate of interest will exceed 5%; Party B bets the opposite. Payments are netted out.
A smart contract can be used to "encode the terms of the swap, import information from a rates provider, and automate payments from the parties' accounts". [Cieplak]
Other fields of applications include: [1] real estate, [2] insurance, and [3] supply chain.
The term "smart contracts" has caught the notice and imagination of many. A book entitled "Fintech: Law and Regulation" contains a chapter on smart contracts authored by Jelena Madir. The latter previously published papers on the same topic. In a 2018 paper, Madir distinguishes between "smart contract code", an automated business process, and a smart legal contract. "Smart legal contracts are functionally made up of pieces of smart contract code “under the umbrella of an overall relationship that creates legally enforceable rights”.
The main point is the observer now must look to the underlying legal context and jurisdiction to determine whether a legally enforceable contract, using smart contract code, exists. Madir then explores superficially rules found in different jurisdictions and considers several legal issues governing the formation, performance, and breach of contracts. The author notes the multiplicity of approaches in various jurisdictions.
The author also notes that the term " smart" is misleading as the algorithms built into the code do not necessarily incorporate artificial intelligence or the ability of the algorithm to learn.
Ricardian Contracts
In 1997, Ian Grigg coined the term "Ricardian Contracts" naming it after the famous economist David Ricardo.

1. Nick Szabo, Smart Contracts 1994 at
2. Nick Szabo, Smart Contracts: Building Blocks for Digital Markets 1996
3. Nick Szabo, Formalising and Securing Relationships on Public Networks 1997 [see file below]
4. Stuart D. Levi and Alex B. Lipton, An Introduction to Smart Contracts and Their Potential and Inherent Limitations May 26, 2018 in Harvard Law School Forum on Corporate Governance at
5. Vitalik Buteri, Ethereum White Paper, A Next Generation Smart Contract & Decentralised Application Platform [see file below]
6. Jenny Cieplak and Simon Leefatt, Smart Contracts: A Smart Way to Automate Performance, 1 Geo. L. Tech. Rev 417 (2017) [see file below]

Explore working with "smart contracts" on Ethereum. Use GETH, Remix, Ganache and/or MyEtherWallet. Follow the tutorial here: