This post is going to be a little bit weird, so buckle up. There has been a lot of hype lately around smart contracts, driven by an interest in blockchain. In this post I argue that smart contracts are kind of lame, and that using code to formally represent a contract (but not execute that contract) is far more interesting.
Using David Adlerstein’s definition, a smart contract is “a consensual arrangement between at least two parties for an automated, independent commercial result from the satisfaction or non-satisfaction, determined objectively through code, of a specific factual condition”.
The truth is that we already have smart contracts, and they’re incredibly boring. I think the typical example here is a vending machine, but there are plenty of other examples. When I buy a book for my Kindle on Amazon, I make a payment, some magic code runs on Amazon’s server, and suddenly I have my book.
Notice that blockchain has nothing to do with this. Blockchain is relevant to smart contracts, but only by “expanding the scope of contractual matters for which performance can be automated as the nexus among assets, service capabilities, and blockchain grows.” Basically, if a transaction requires the transfer of some physical object, a smart contract probably isn’t going to achieve that. Put that asset on a blockchain, and suddenly a smart contract has relevance. At least, that’s the hope.
That’s fine and all, but smart contracts are still only going to be automating the boring stuff that we already see as routine. In fact, smart contracts are probably just going to replace existing but not-quite-as-smart smart contracts.
Right now when I buy a book for my Kindle on Amazon, I don’t know what magic code runs on Amazon’s servers, and I just have to trust that it will arrive. Of course, the book always does arrive on my Kindle, and my trust isn’t blind either; it’s in Amazon’s interest not to stiff me. And if Amazon really didn’t want to give me the book, I could file a chargeback with my bank, and would be fine. And if that didn’t work, I could probably take Amazon to court (or maybe arbitration, depending on the click-wrap agreement I didn’t read). Nonetheless, the point remains: I had to trust Amazon.
Put that digital book on a blockchain (or something like that) and run this code on some decentralized network and I could probably do this in an automated way, where I really don’t have to trust anyone (besides my ability to read and understand code). The agreement itself could be the mechanism for executing the transaction, and as long as I hold up my end of the deal I am assured that the code will do as it says and the book will be transferred to my Kindle. So there you have it, a slightly smarter smart contract!
But what about the types of contracts that high paid lawyers draft? Can we make a smart contract for an M&A deal? No. The problem isn’t that the assets aren’t digital or that automated processing has to occur on someone’s server. The problem is that the terms we include in the contract cannot be verified by a computer. Does some external event constitute “force majeure”? Was a breach “material”? Was a misrepresentation “negligent”? These are ambiguities that we put in contracts not because natural language is defective and we have no choice, but rather because the subjectivity gives the contract a flexibility that is desirable. Smart contracts and blockchains don’t help us here.
Just because share purchase agreements won’t be self-executing anytime soon doesn’t mean that these types of contracts can’t be expressed as code; they can, and I think they should be! First I will explain how this can be done, and then in the section below I will explain the benefits. I will use share purchase agreements (SPAs) as an example, just because it is a type of contract I am particularly familiar with.
Recall that the fundamental problem with making an SPA into a smart contract is that many of the clauses require subjective human judgment. An SPA might say something like, “The seller warrants that no lawsuits are pending against the company that are likely to materially affect the value of the company”. However, after paying for the shares, the seller finds that the company is defending a few very large lawsuits. Whether this is a breach of the warranty depends primarily on the probability of success in these cases, and for that we need an expert.
The computer isn’t going to verify if a breach of warranty has occurred, and it isn’t going to identify the amount owed by the seller to remedy the breach either. However, the contract can identify the mechanism for determining that amount (i.e. breach of warranty entitles to damages). We can write some boring code that basically just says if breach of litigation warranty: seller pays expected liability of outstanding litigation. We can make breach_of_litigation_warranty a boolean value set initially to False, and expected_liability_of_outstanding_litigation an int. If a breach occurs, someone can change breach_of_litigation_warranty to True, and set the value of expected_liability_of_outstanding_litigation. There’s nothing in an SPA that can’t be represented like this.
Of course, this probably seems useless. I am not saying that we should replace the standard written contracts currently being used; my suggestion is that law firms should be creating these code representations of the contracts they write and storing them. Doing so create huge opportunities in the realm of contract analytics, and would allow a firm to offer services that no other firm can.
In the case of SPAs, imagine a scenario in which a potential buyer is bidding on a firm and as part of the bid has to submit a proposed SPA. A law firm is advising the buyer, and the buyer is concerned about the cap clause (a clause limiting the amount payable under the indemnities). Right now, the lawyers will likely say something like, “We’ve found that market practice is…” but they’re basically just guessing based on the five deals they remember off the top of their heads. Maybe they’ll ask the support staff to go through past agreements so they can provide a better answer, but that takes a fair amount of time and is an imperfect solution.
If every SPA the firm worked on was represented as code, a simply querying tool could be used to find this answer immediately, and also reveal other interesting trends. For example, does the cap change based on the size of the deal? Based on the industry? Etc. Without representing the contract as code, this isn’t easy (it involves some tricky natural language processing).
Of course, representing every SPA in code is probably unnecessary if all you want to do is query the presence of clauses and whatnot. A structured markup language of sorts would probably do. However, if we move beyond SPAs the potential for this type of analysis increases, and the need for a formal representation, not just a markup language, becomes apparent.
Say there is a company that needs large amounts of cotton on a regular basis. It has hundreds of contracts with suppliers to buy cotton at some fixed price; however, each contract specifies the right to renegotiate if the market price of cotton exceeds some set threshold (which differs according to the contract). If tomorrow the price of cotton skyrockets, the company is going to want to know which contracts are potentially at risk. Having each contract represented in code makes it easy for a firm to answer that question quickly and with certainty.
The above example is probably nonsense, as I know nothing about how these types of contracts work in practice, but it isn’t hard to imagine a scenario in which some external event affects hundreds of contracts, and the firm is going to want to understand the potential risk. Representing contracts as code in the manner I outlined in this post isn’t especially hard, but makes it easy to solve these problems.
All of the hype today is around smart contracts, but I don’t think people realize how boring self-executing agreements really are. Seeing people talk about the transformative potential of smart contracts is about as surreal as seeing thought leaders hyping click-wrap agreements. But that’s the world we live in.
My pipe dream is that law firms (or companies) in the future will be using code to create a standard, formal representation of the contracts they write. This would create opportunities in contract analytics that do not currently exist, and would allow firms to add value in entirely new ways.