Breach When the Contract is in the Code — Turning Breach of Smartcontracts from Bug to Feature

Joshua Fairfield
6 min readOct 8, 2020

--

In smartcontracts, the contract is in the code. Where is the breach?

“The duty to keep a contract at common law means a prediction that you must pay damages if you do not keep it, and nothing else.”

— Oliver Wendell Holmes

The popular draw of smartcontracts is that they supposedly cannot be breached. As you have probably already read, a smartcontract is a coded set of instructions that can automate certain conditions, usually payment. If event “x” happens, and the code gets the proper input, then payment “y” is immediately transferred without need for banks or financial intermediaries, and without any other human intervention or indeed ability to cease payment. It’s a contractual vending machine that lives in a database spread across thousands of computers.

Certainly, under a smartcontract, the payment obligation of one party is significantly more likely to occur. If I purchase a new cryptocurrency by depositing ether into its smartcontract, I will almost certainly get the new cryptocurrency. The parts of the deal that have to do with transferring value will be automatically executed, as long as the code doesn’t malfunction. There are, of course, myriad other ways of breaching a contract, especially since putting it on a blockchain doesn’t secure other means of performance. If the deal is that A ships B a widget in return for ether, the widget shipment has to be performed, it is not automatically executed by code.

But beyond that, let us assume that smartcontracts reach the gold standard of unbreachability: performance is executed by code, and so the contract will be performed if the code-specified conditions are met. There is a further problem. Breach of contract is often a feature, not a bug. The core of efficient breach, its founding fable, goes as follows: A contracts with B for electric generators, for example. After a storm hits, C, a hospital, desperately needs generators. C offers A enough money that A is willing to break the contract with B, sell the generators to C, and make B whole or more than whole out of the surplus paid by C.

There are real problems with this founding fable, and we’ll discuss those in a moment. The core issue, though, is that the common law has often found it very useful to permit parties to breach contracts. Breach is often a feature, not a bug. Force majeure, sometimes called an Act of God, is a good example. Performance of the contract is excused if an event occurs that the parties assumed would not occur. It’s a catch-all clause, meant to cover all of the events from alien invasions to zombie apocalypses to hurricanes to worldwide pandemics to successful hacks of unhackable blockchains. The parties could have contracted about any of these at the formation of the contract but didn’t because covering every eventuality would require infinite space and time.

Smartcontracts can’t code for unspecified conditions. Some force majeure events could be coded, and conditions excusing performance could be specified in the contract at certain points, but it is impossible that all such events could be coded. We are talking by definition about situations in which courts would excuse performance, but the code can’t tell what to do because it’s a situation not defined in the code.

What that means is that it’s impossible to code for things like force majeure. Sure, we can create an oracle that kicks the question out to some sort of adjudicative body. The code asks and gets a response from a group of people who can certify whether some unanticipated force majeure event has happened, but that just preserves the issue: suddenly the unbreachability of a smartcontract is subject to the same human oversight and questions of which adjudicative body ought to decide. The smartcontract can’t handle its own adjudication. If we are kicking problems from smartcontracts out to adjudicative bodies, then we have defeated the very purpose of smartcontracts — avoiding a third-party, or even, avoiding human input and interference with performance generally.

There are further problems with smartcontract breach. If we think of smartcontracts as a way of guaranteeing performance of payment obligations, it’s worth noting that we already have such mechanisms. We could permit contract law to enforce large penalties for failure to perform. Liquidated damages clauses are common. In the event of breach, person A pays person B agreed-upon damages. But again, the law stops short of letting parties use liquidated damages clauses to seal a contract up tight against breach. It would be possible: if you entered into a contract to buy a car for $10,000, and it contains a liquidated damages clause imposing a million-dollar penalty in the event of breach of contract, you will perform the contract if it is at all possible to do so.

Courts choose not to, though. Such liquidated damages clauses are struck as a penalty. A penalty for what? For not performing the contract. Courts avoid penalties, requiring liquidated damages clauses to set remedies that are reasonably related to the actual or anticipated damages of the parties. Merely making sure the contract is performed is an inadequate ground for enforcement of the clause. There’s a reason that courts don’t allow for liquidated damages as penalties. They understand that breach is an essential feature of the contract law framework.

In force majeure and liquidated damages cases, we see markers of a trend that extends throughout all of contract law. Contracts are not about securing performance. They are about creating legal relations, a landscape, a framework within which the parties can engage in mutually beneficial exchange.

Breach is a part of that landscape, and there is some reason to think it is a positive part. The possibility and prospect of breach play a much-needed role in bringing parties to the table to renegotiate agreements. After all, if performance were guaranteed according to the original terms, there would be no need to renegotiate. The possibility of breach incentivizes renegotiation in long-term relational contracts. If smart contracts do what they say they do, no-one will come to the table. They won’t even have the opportunity to.

Consider, for example, a ten-year supply agreement between a factory (seller) and a retailer (buyer). The key feature of such contracts is flexibility. Rarely are the contracts carried out after a decade in the way that they were originally negotiated. The parties will usually have breached the contract a number of times during their long term relationship. Breaches are often waived and serve as a way of identifying pain points in the relationship. If one party is being forced by intervening circumstances to breach, it is likely the other party will renegotiate rather than blowing up the deal. For example, if you hire an architect you like to build your house, you are likely to agree to a higher price and longer building horizon if the rock under your house turns out to be much harder to excavate. You are likely to renegotiate with the architect you want to get the house built rather than claim breach and seek another party to do the work. That other party would charge more anyway, and you might as well work with the person you wanted to do the job in the first place. So, breach or the prospect of breach are often paths to getting the parties to a better position and securing the value in the mutually beneficial agreement they originally struck.

The “non-breachability” of smartcontracts runs counter to some of the key limits of contract law that protect parties’ ability to breach contracts. And that protection is in place because the prospect of breach acts as a safety valve, especially in long-term important commercial agreements. Smartcontracts are currently a quite limited tool. About the best thing they do is exchange one kind of cryptocurrency for another, since in such a deal both payment obligations can be automated and decentralized. For smartcontracts to grow up and interact with real world legal relational frameworks, they’ll need to be able to undergird and enforce long term and flexible legal arrangements, and interact with cut-outs (like force majeure) that deal with unprecedented circumstances.

--

--

Joshua Fairfield

Law professor, author, futurist, and expert on privacy, virtual communities, and all things nerd. All opinions are my own. Follow @JoshFairfield