Smarter Legal Contracts Part 1: The What, How, and Why
Smart contracts have received significant attention over the past few years from many quarters, including regulators, bankers, developers, and lawyers. Often, these parties approach the concept of a “smart contract” differently, and understandably so. Some focus on technical aspects, some have seen digital agreements for a while (in financial derivatives, for example), and others focus on the new business models and processes made possible with this evolving technology.
As such, some form of level-setting is necessary to understand what is being referred to when we talk of a “smart contract” and particularly when we consider the relationship to “contracts” that we use time and time again today as PDF or Word documents.
2019 has been a breakthrough year with numerous milestone developments. What better opportunity to use these developments to answer the critical questions: what are smart legal contracts, how are they used, and why are they useful? This three-part series will address these questions. If you want answers, dive in!
What?
So, let’s start by defining what we mean when we use the term “smart contract”? This is a well-trodden path (see these three examples) and, semantic appropriateness aside, one that we can answer fairly succinctly from usage of the term over the past few years. The term “smart contract” has come to refer to a script or series of scripts (read: computer code) that persist and execute (read: stored and run) on a blockchain or other distributed ledger system to perform some operation. That operation is typically — but not necessarily — used to mediate between two or more parties. Such a script could therefore be used to perform operations pertaining to a contract at law between parties. Frequently, smart contract operations will involve a cryptoasset (such as Ether). A fairly classic example is the release of escrowed funds based upon an event occurring such as the passage of a given time period or date.
Now, the caveat for semantics is necessary as a frequent, and valid, retort is that a “smart contract” may neither be smart, nor a contract. In other words, a script may perform any arbitrary operation (smart contract platforms are often designed to enable Turing completeness) which may not have legal significance or constitute a valid contract (or part thereof) at law. A script could, for example, increment a counter every day, week, month, etc.
Jurisdictional variances and issues aside, it is fairly well settled that a “smart contract” can constitute or form part of a valid contract at law. Indeed, one of the major events of 2019 was the release of the UK Jurisdiction Taskforce’s Legal Statement on Cryptoassets and Smart Contracts. The Legal Statement confirmed the application of established principles of contract law to smart contracts and thus the ability of a “smart contract” to be a valid and enforceable contract under English law. However, just because a “smart contract” is used does not mean, despite the terminology, a script fulfilling its technical definition is a contract at law.
This is often why we refer to the term “smart legal contract” in order to distinguish a “smart contract”. The term is both narrower and wider:
- valid and enforceable at law — which a typical “smart contract” may not fulfill; and
- may or may not be blockchain or distributed ledger based — which is wider than a typical “smart contract” per the prevailing technical usage of the term.
Typical examples may include a contract that calculates the price of a good based upon delivery conditions such as timeliness, temperature or humidity in shipment, for use in calculating deposits, and more.
A “smart contract” may be a subset of a “smart legal contract”. In other words, a “smart contract” may be a “smart legal contract” or may be part of a “smart legal contract”, but only if it, or together with its other components, is enforceable as a valid contract.
Both terms are at least somewhat semantically obtuse. Some may see the term to be redundant given that a “contract” has legal definition. Others may see the addition of “legal” as necessary to distinguish “smart contracts” that are legally enforceable or have legal consequences from those that may not. This stems from an overly technical usage of the term rather than by design.
A “smart contract” may be a form of enforceable agreement between parties but one that is enforced by the operation of code rather than by operation of law. The term is therefore considered by some to be appropriate. Despite its purported technical enforceability, however, a smart contract may have no legal enforceability.
Lawrence Lessig’s infamous phrase “code is law” is often used in reference to the technical enforceability of “smart contracts” in a manner that may avoid the usage of traditional or non-software based methods and means of enforcement. Frequently, however, the term is misappropriated to refer to smart contracts having legal or quasi-legal effect. More accurately, the code performs a regulatory function on the relationship but cannot and does not elevate the code to a level of law, despite the fact that it may enforce a contract or have legal consequences within the legal landscape that applies to it.
In truth, the term “smart contract” is often used indiscriminately to encompass a range of distinct incarnations or forms of contractual arrangement. They sit upon a spectrum in terms of their form and function. These may frequently be conflated. Thus it is important to attempt to distinguish what we mean by the various terms that are used in describing these forms and their relative relationships.
“Contract” — An agreement between private parties creating mutual obligations enforceable by law. A “digital contract” is a contract document composed and concluded entirely using software as opposed to being in physical form. A“smart legal contract” is a digital contract comprising executable logic. A “smart contract” is a script (executable logic) instantiated on a blockchain or other form of distributed ledger system that performs an operation or series of operations. As such, a contract may be in digital form, which may be in the form of a “smart contract” or “smart legal contract”, so defined. The former may be wider in terms of technical application (it may have no legal consequences or purpose) but is narrower in that its technical application, as traditionally defined, limits the form in which it takes. A “smart contract” may be a “smart legal contract” (or part thereof) but may not be. In other words, a “smart legal contract” may be implemented in a manner that does not wholly meet the definitional requirements of a “smart contract”. Importantly, both forms are executable in nature: they include computer code that is run to execute operations.
This then begs a third question: how? Definitions and categorization aside, how are smart legal contracts formed and what do they look like in practice? This will be covered in Part 2 next week.
