Dan Selman, CTO, Clause Inc. @danielselman
In this article I will introduce smart legal contracts as well as the Open Source Accord Project. I hope it will motivate you to use the existing technology and to join us in defining the standards and Open Source code for smart legal contracts!
What are Smart Contracts?
In the blockchain space the term Smart Contracts has come to mean programmed logic that runs on a ledger-like distributed system in response to transaction submission.
As many people have said (myself included) this machine executable logic is usually not very smart (a deterministic finite-state-machine, or validator of finite-state-machine transitions) and it certainly isn’t a legal contract that a lawyer would recognise! From here on I’m going to refer to this as chaincode (blockchain code).
What are Ricardian Contracts?
One can relate the chaincode created by developers to the governing legal text they are supposed to implement using a cryptographic content-based hash of the chaincode and/or the legal text. For example, the chaincode may hold the hash of the legal text as metadata (“I am an implementation of the legal agreement whose text has the hash 0xdeadbeef”) or the legal text may state that it is implemented by the chaincode whose source or binary code has the hash 0xcafebabe, or in the case of so-called dual-integrated contracts, both. This is the basis for Ricardian Contracts — essentially building content-based traceability from chaincode to legal contract and vice-a-versa.
In more advanced Ricardian schemes the legal text is parameterised and the hash may apply to the parameter values, as well as the surrounding legal text.
Although the the Accord Project Template Specification is not directly Ricardian, it does have Ricardian properties. A Smart Clause is a typed instance of a Smart Clause Template. The data for a Smart Clause is represented as JSON and can be hashed. The contents of a Smart Clause Template can also be hashed. These capabilities ensure that content-based hashing can be used to unambiguously link a smart legal contract to executable code or vice-a-versa.
From Legal Contracts to Machine Code
At Clause we think about legal contracts and machine code as a continuum. At one extreme legal text intended purely for human consumption, at the other, computer executable machine code. In between are different representations and abstractions that strike different tradeoffs between flexibility, intentional ambiguity, computational rigour, and ease of authoring and understanding by legal or computer experts.
As one moves to the right in the continuum (towards chaincode) one moves towards structured representations of the legal text, ultimately arriving via a compiler to machine code that can be executed on a central processing unit (CPU) of a computer chip.
LEGAL CONTRACT < SMART CLAUSE TEMPLATES WITH PARAMETERS < SMART CLAUSE TEMPLATES WITH EXPRESSIONS < DOMAIN SPECIFIC LANGUAGE < COMPILER < MACHINE CODE
We believe that this continuum will always exist, as much of law is ultimately about governing human behaviour, not just orchestrating computational business processes. We don’t espouse either of the two reductionist views I often hear:
- “Contracts are for people, and machines can never play a role in automating them”
- “Law is too messy and should be code: binary, unambiguous, deterministic.”
We believe that, like most interesting problems, the truth can be found in the middle ground, and that there is enormous value in creating systems where machines and humans are working in harmony.
A legal contract is divided into clauses. Some clauses are intended for human consumption, while some clauses can usefully be automated and connected to sensors and systems.
In software development we sometimes talk about the Happy Path and exception handling. There’s enormous value in automating the Happy Path through a contract (the expected behaviours) while using the existing human arbitration and court system to handle exceptional circumstances that rarely occur, or where the desired behavior is uncertain.
For example, Rumsfeld’s “Known Knowns” should probably be automated. His “Known Unknowns” may be specified in the legal text to guide human arbitration, while the ‘Unknown, Unknowns” may have to go to court, and could result in new case law.
Which Clauses Should be Smart?
That brings us to the important question of which clauses in a legal contract should be made “smart”. The ability to automate the execution of a clause depending on many factors:
- What is the business value in automating this clause? Is this a condition that occurs frequently for this type of contract? I.e. is it on the Happy Path”? In decision-automation this is often referred to as Straight-Through-Processing (STP). We strive to increase the percentage of STP so we can have more consistent and better quality results, at lower cost.
- Can the logic of the clause be captured as a deterministic computable expression? Some legal concepts are intentionally human-centric and fuzzy (“party must use appropriate packaging”, “party should use all reasonable efforts to…”). These statements must either be converted to a crisp computational form (which might be contentious), or left as-is, and will be interpreted by a human being when a dispute occurs, based on specific circumstances, and with reference to appropriate case law.
- Do trusted events and event sources exist to allow the conditions of the clause to be automatically evaluated? For example, if this is a clause about the bankruptcy of a company, or the weather data for the city of London, can the contracting parties both trust a source of bankruptcy and weather data?
- Is there business value in seeing the state of the clause, or in applying the side-effects of executing the clause to external systems? For example, would it be useful for the clause to automatically make payments, create accounting entries, put data onto the blockchain etc. Automating these clauses may facilitate the creation of new business models, such as using contractually specified micro-payments.
What Could Go Wrong?
Whenever one moves from one level of abstraction to another there are opportunities for errors in interpretation or implementation, particularly if different people and skills are required to work at the different levels of abstraction. Let’s take a look at some of the potential problems.
For example, in the case of the DAO the legal text was not legally enforceable, and due to bugs the executable logic did not faithfully capture the intent of the implicit legal contract.
Contract is not legal
The legality of the contract text is purely an issue for lawyers and the courts. Clearly if the legal contract contains clauses that are not legally enforceable a party to the contract will struggle to enforce their terms.
Contract doesn’t represent the agreement of both parties
The contract may be legal but may not accurately capture the spirit of the agreement between the parties. Again, this is an issue for the lawyers and the courts as a party may challenge the contract.
Logic for a Smart Clause does not accurately capture the intent of the legal text
For example, a legal contract may contain a clause which states that party A must pay party B a penalty of 10%, however the programmer responsible for the logic has erroneously coded that the late penalty is $10.
Logic for a Smart Clause has bugs
For example a late penalty is charged for every hour that a package is late, however the logic as coded assumes that there are always 24 hours in a day, failing to account for daylight savings time changes.
Underlying environment, operating system or hardware bugs
The logic as written is correct, however due to bugs in the overall execution environment it does not execute as intended. Recent examples include issues with floating point arithmetic on Intel processors.
Garbage In, Garbage Out
The logic may be correct, however if it is passed bad data, then the logic will come to incorrect conclusions. For example, if the weather data feed for the average temperature is incorrect due to a sensor error then the smart clause may produce incorrect results and downstream systems create invalid invoices, or make invalid payments.
Back to Reality
While the list of potential issues is real we must recognise that we are faced with all of these challenges today. In fact the situation today is worse in that the IT systems that help enforce or automate aspects of our contracts are built in silos with minimal legal oversight. Trying to find the source of an error related to a contract may involve much painstaking debugging, as the intent of the legal contract has typically been shredded and scattered across multiple IT systems.
By creating technology that allows technologists and legal experts to collaborate more closely on these challenges we can reduce errors and unlock enormous efficiency gains by making IT systems more aware of contractual rights and obligations, and reducing the impedance mismatches between the contract management, legal department and the IT department and the associated errors.
“By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect increases the mental power of the race.” — Alfred North Whitehead
We want smart legal contract abstractions to be useful and appropriate. For example we believe that the gulf between legal text and Solidity (and Solidity’s esoteric “features”) make it very problematic as an abstraction for smart legal contracts. We need domain specific languages that are much closer to the abstractions present in legal contracts, and with fewer surprises for the legal-tech programmer.
We also don’t want the logic of our smart legal contracts to be tied to a single execution infrastructure, as we know that blockchains and distributed ledger technology is evolving very quickly. We want to be able to deploy our contracts to a variety of existing DLT platforms and to new platforms that have not yet been invented.
Solutions
Within the Open Source Accord Project we are creating a set of legal and technical standards and software tools to address these challenges:
- A globally distributed set of interlinked domain data models to formally capture the concepts required to describe legal contracts.
- The Accord Project Template Specification specifies a packaging format for the natural language text for a Smart Clause, the governing data model, as well as the executable logic. This is the basis for a system of Ricardian contracts, where natural language text can be parameterised and expressed in terms of an executable template.
- Runtimes and compiler tool chains that are blockchain neutral, and allow smart legal contracts to be used on devices, in the cloud, or embedded in a wide variety of distributed ledgers.
- Executable logic for a Smart Clause Template is expressed using the Accord Project domain specific programming language: a functional programming language to safely and verifiably capturing the logic of a legal clause. More details on the domain specific language coming soon!
- Tools to make creating, testing and validating Smart Clause templates easy, such as the Accord Project add-in for Microsoft Word.
- An Open Source curated Smart Clause template library, allowing legal-tech professionals to collaborate on the natural language text, data models and executable logic for Smart Clauses.
Join the Fun!
The Accord Project community is growing rapidly, with 20+ global law firms represented and many of the leading standards bodies and technology companies.
We’d love your help to define the standards for smart legal contracts: on the legal side, standardising legal clauses and data models, helping to specify the executable logic, or on the technology side: creating a domain specific programming language for law, a templating mechanism and productivity tools.
Get involved by signing up at http://accordproject.org. Download the Accord Project code today and take it for a spin!
