Part I: Observability
Smart contracts are the new buzz words in the blockchain legal industry this year, but what are smart contracts? And what exactly makes them “smart”? And more importantly to those in the legal profession, can smart contracts exist within the legal system as enforceable and valid contracts between parties?
I have begun to dig through some of these questions in my research (available here) and will continue to explore the legal implications and enforceability of smart contracts in future research.
But for now, I want to present a deeper analysis of smart contracts and how they are foundationally similar to traditional contracts between parties. Nick Szabo, in one of the earliest analyses of the legality of smart contracts, broke down contractual design into four major elements: observability, verifiability, privity and enforceability. These elements taken together form the foundation on which all contracts are formed and enforced, and how smart contracts can be analyzed through a legal perspective.
In this four-part post, I will discuss each of the four contractual designs in greater detail and discuss the nexus between smart contracts and traditional contract law. By breaking down contracts into four fundamental elements, I hope to provide readers with a greater understanding of how smart contracts are grounded in traditional understandings of contract law and hopefully provide some useful background about smart contracts in general.
The first contractual design identified by Nick Zsabo is observability: the ability of the parties to observe the performance of the other party to the satisfaction of the contractual requirements. We will first discuss how performance by the parties of their contractual obligations is measured; understanding the basic mechanics of a legal contract is imperative to understanding how observability operates. I will then discuss how parties “observe” the performance of the other party to ensure compliance with the terms of the agreement. In additional, we will consider the difficulties that smart contracts face when attempting to observe external conditions outside the blockchain network. Lastly, this post will discuss how smart contracts can be improved to provide better observability for the parties and accept more external data inputs for more complex transactions.
Performance - A valid contract is generally defined by four basic elements: an offer, acceptance, intent and consideration. What underlies all of these elements is the “performance” of the parties, the completion of their promises memorialized in the contract. Black’s Law dictionary defines performance as “the fulfillment or accomplishment of a promise, contract, or other obligation according to its terms.” Each party agrees to perform in a certain manner to satisfy their promise to the other party. This covers an endless range of activities from mowing the lawn to paying $100 for services.
When the parties agree to a legally binding contract, they are in fact guaranteeing to the other party that they will perform the actions they promised in the contract. If both parties perform, then the contract is enforced and both parties are satisfied. Sometimes, one party will first require performance by the other party before completing their own performance, such as requiring performance of a service before releasing payment. If a party doesn’t perform according to the terms of the contract, then the other may exercise its rights under the contract’s provisions, such as terminating the contract or levying a penalty, or exercise its rights under contract law such as specific performance.
Performance is at the heart of every contract, no matter how simple the contract is or how sophisticated the parties are. Without performance by the parties, which can later be observed and verified, a contract is inoperative. This is even more important in the context of smart contracts — a party only enters into the contract because it reasonably expects the other party to fulfill its obligations through the performance of the provisions of the contract.
Observability - Observability refers to the “ability of principals to observe each other’s performance of the contract, or to prove their performance to the other principals.” Each party examines the opposing party’s performance of their obligations to ensure the terms of the contract are being followed. In traditional contracts, observation occurs through monitoring the performance of the other party through delivery obligations, accounting exercises and performing various audits.
Smart contracts exist on a blockchain network where “assets and contract terms are coded and put into the block of a blockchain…this contract is distributed and copied multiple times between the nodes of the platform” and are then executed between the parties and recorded within the blockchain as a new block of information. Because smart contracts are hosted on a blockchain, they enjoy several benefits of blockchain technology including a distributed network of nodes that all confirm information simultaneously, enhanced anonymity, and automated execution of the smart contract once the “trigger” has been detected by smart contract’s code.
Observability in smart contracts operates similarly to traditional contracts; both parties can observe the other party’s performance to their satisfaction utilizing code in the smart contract to confirm obligations have been fulfilled before executing the contract. Automation is an additional benefit for smart contract, as the coding can confirm performance without third party intervention. For example, a smart contract’s code could be written to confirm that a company made a delivery at 2:00pm by collecting information from the company’s delivery notification system. The contract, upon this information being confirmed by all the nodes on the blockchain, would then execute the smart contract and remit payment to the delivery company for its services.
However, the decentralized nature of a blockchain presents two impediments for smart contracts to observe and react to external conditions: the all-or-nothing nature of a consensus-based system such as a blockchain and the validity of external sources.
All information entering the blockchain is vetted by all the nodes (or blocks) of the blockchain before that information is recorded as new distinct blocks of information, relying on the consensus of all the nodes to confirm the information is valid. Going back to the delivery company example, all the nodes would simultaneously confirm the delivery system marked the package as delivered at exactly 2:00pm in order for the contract’s coding to be satisfied. If a single node returns an error message or a different time stamp from the delivery notification system, the blockchain will reject the performance of the delivery company.
While blockchain technology certainly has its benefits in terms of automation, there are limitations as well. Even if a smart contract’s code is able to retrieve the proper information notwithstanding the possibility of errors discussed above, there still remains the issue of the information obtained from third parties outside of the blockchain’s secure and decentralized network. Is the information valid? Can the source of the information, in the case of our example the delivery system operated and maintained by the delivery company, be trusted without any further review? This is an interesting dilemma, but nothing that doesn’t already exist in normal contracts. Traditional contracts rely on trust and good faith between the parties. Even some of the most secure forms of verifying information, such as a social security number used to verify one’s identity, are not immune to modification or attack. Therefore, while sources must certainly be vetted before they are trusted, there likely will never be a 100% trusted source, which should not hinder the development of smart contracts.
Getting Smarter - Given the impediments to external observability of smart contracts, how do smart contracts get smarter? Accounting for a wider variety of legal complications and developing a better legal perspective regarding smart contracts are common themes I will return to in each part of this broader post, beginning here with how smart contracts can better connect to the “outside world.”
At its core, a smart contract’s interaction with the outside world can be distilled down to the requirement for “some form of input data which the contract processes and, upon agreed conditions met, it produces some resulting output.” Retrieving that “input data” is a difficult task because smart contracts lack consistent and trusted connections to the outside world for the code to pull data. In order to properly execute, “smart contracts need to be able to interface with data in the wider world,” but how would a smart contract go about gleaning such information in a quick and efficient way?
The term “oracle” is used in the blockchain community to describe a third party that provides external data for a blockchain as a trusted source. Information required by a smart contract can range from a stock’s price determined by the market and updated by the millisecond to the credit rating of a company that is subjectively determined by a credit rating agency. In both cases, nodes of the blockchain where the smart contract is hosted would contact a designated oracle to receive the data and then determine whether the retrieved data satisfies the thresholds set by the smart contract terms.
Service providers such as Oraclize act as a “data carrier for decentralized apps” utilizing smart contracts that require external data inputs. Oraclize provides trusted “avenues” of information where a smart contract can retrieve external information inputs. This eliminates the issues caused by consensus-based networks (as discussed above) because the nodes will all contact the same trusted oracle to confirm information required to execute the smart contract and thus will reach a consensus.
Oracles have helped resolved the other main issue surrounding observability of smart contracts: trust. Parties looking to observe each other’s performance require a trusted source to act as a “gate-keeper” to certify when a threshold or provision of the smart contract has been met for execution to occur. While traditional contracts are often overseen by bankers, lawyers, accountants and other trusted intermediaries, smart contracts exist outside of this traditional scope of trusted sources of information. Therefore, oracles can begin to operate as trusted sources not only of raw data but also acting as trusted verifiers of provisions of a smart contract before it is irreversibly executed.
Observability of performance requires verification of that performance by either the opposing party or a trusted intermediary as discussed above. Information flowing into a smart contract needs to be validated in the same manner as information being applied to a regular contract, such as a purchaser’s credit history before being provided a loan for a car. While this may sound intuitive, trusting a source of information to feed decisions into the blockchain is still fraught with potential issues that still need to be resolved.
Observability is one of the fundamental building blocks of traditional contract law and is imperative to understand as smart contracts increasingly enter the legal realm as legitimate agreements between parties. While smart contracts may seem “dumb” currently, coders are increasingly designing more sophisticated triggers and provisions that require information from more external sources. With this basic understanding of the first element of contract design we will next move on to verifiability, how each party can prove breach or performance of the contract. Please look for Part II: Verifiability next week!
About the Author
Jared Arcari is a third year law student at Fordham University School of Law. Jared currently serves as the president of two student organizations, the Fordham Business & Law Association and the Entrepreneur Law Society. He is also a Notes & Articles Editor at the Fordham Journal of Corporate and Financial Law. When he isn’t writing about blockchain-related legal issues, Jared enjoys serving as a research assistant to prof. Bernice Grant researching entrepreneurial topics including non-compete alternatives and improving access to capital. To contact the author, please email him at firstname.lastname@example.org.
Any information contained in this post is for informational purposes only. The information, opinions and commentary contained herein does not constitute legal advice. It also does not constitute tax advice. This post is not a complete overview or analysis of the topics presented and may contain information that varies in different jurisdictions. The transmission of information to the reader does not create a lawyer-client relationship. The reader should not rely upon this post or treat it as a substitute for legal advice. The reader should consult a lawyer familiar with their particular circumstances and licensed in the proper jurisdiction for legal advice.
 Nick Szabo, Smart Contracts: Building Blocks for Digital Markets (1996), http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart_contracts_2.html.
 Black’s Law Dictionary (9th ed. 2009).
 Szabo, supra note 1.
 Olga v. Mack, Smart Contracts: The Future of Contracts, Brought to you by Blockchain, (May 14, 2018) https://abovethelaw.com/2018/05/smart-contracts-the-future-of-contracts-brought-to-you-by-blockchain/?rf=1.
 See Jessica Messier, Why Consensus-Based Blockchain Technology is Better at Keeping Code Safe, (Feb. 13, 2018) https://mytechdecisions.com/it-infrastructure/consensus-based-blockchain-technology-better-keeping-code-safe/.
 See Gideon Greenspan, Why Many Smart Contract Use Cases are Simply Impossible, (Apr. 17, 2016) https://www.coindesk.com/three-smart-contract-misconceptions/.
 See Tom Hingley, A Smart New World: Blockchain and Smart Contracts, (2018) https://www.freshfields.com/en-us/our-thinking/campaigns/digital/fintech/blockchain-and-smart-contracts (noting that despite some commentators worrying about smart contracts taking over jobs, “we’re not there yet…”).
 See BOScoin, Smart Contracts & Trust Contracts — Part 1 (Sep. 8, 2017) https://medium.com/@boscoin/smart-contracts-trust-contracts-part-1-83f12dec7641.
 See id.
 See ISDA & Linklaters, Smart Contracts and Distributed Ledger — A Legal Perspective (2017) http://content.linklaters.com/pdfs/mkt/london/Smart_Contracts_and_Distributed_Ledger_A_Legal_Perspective.pdf.
 Greenspan, supra note 7.
 See id.
 Greenspan, supra note 7 (noting that “in other words, an oracle pushes the data onto the blockchain rather than a smart contract pulling it in”).
 See Oraclize, Understanding Oracles (Feb. 18, 2016) https://blog.oraclize.it/understanding-oracles-99055c9c9f7b.