Avoiding smart contract conflicts despite ambiguity

A version of this article was originally published by Law360 on Oct. 21, 2020.

Depending on whom you ask, the promise of smart contracts ranges from the mundane to the fantastic—from helping to “facilitate, verify, execute and enforce the terms of a commercial agreement”^[i] to ushering in the end of contract law by providing a technological alternative to the legal system.^[ii] Smart contracts have already been used in connection with real estate transactions,^[iii] bank bonds,^[iv] interbank transfers,^[v] invoice financing,^[vi] and homeowners, renters, pet, and flight-delay insurance.^[vii] B3i Services AG, an insurance startup owned by 20 of the world’s largest insurers and reinsurers,^[viii] released an application that uses smart contracts to allow participants to “negotiate terms, agree on rates and complete contract placements.”^[ix] By February 2020, nine insurers, four major brokerage firms, and eight reinsurers had concluded 30 reinsurance contracts through the application, including, according to B3i, "some of the world’s most complex Catastrophe Excess of Loss (XoL) reinsurance treaties.”^[x] On Sept. 15, B3i announced “several major enhancements” to the application, with future improvements planned for 2021.^[xi] The same day, BNP Paribas announced a partnership “to design a number of real-time trade and settlement apps using … smart contracts.”^[xii] Effective Jan. 1 and July 15, 2020, Illinois and Kentucky, respectively, became the latest states to address smart contracts directly in legislation.^[xiii] And on Sept. 21, the United Kingdom’s Law Commission announced the start of “two new projects to ensure that English law can accommodate two emerging technologies that could [revolutionize] commerce: smart contracts and digital assets.”^[xiv] The aim is to “highlight any uncertainties or gaps” and identify required reforms in the law related to smart contracts, “so that businesses can be confident in their use of smart contracts.”^[xv]

Yet there remains a great deal of confusion about smart contracts, not least because there is no single definition of the term. To be sure, the definitions generally share some elements in common: a smart contract involves computer code performing part or all of a transaction between parties.^[xvi] Some people writing about smart contracts—lawyers, bloggers, commentators—use the term to refer to computer code that is “a complement, or substitute, for legal contracts,”^[xvii] and thus, the code has a legal meaning outside its technical specifications. But others use the term to refer simply to computer code as if the code has no legal meaning or consequences. As such, like the proverbial Holy Roman Empire, some say smart contracts are neither smart, nor contracts.^[xviii] In contrast, the Illinois law defines “smart contract” as “a contract stored as an electronic record which is verified by the use of a blockchain,”^[xix] which says nothing about its form—that is, whether it contains any computer code. A traditional contract stored on a blockchain meets the Illinois definition of a smart contract.

The ambiguity in the definition of a smart contract raises several important questions that this article aims to answer. First, will a smart contract—whether purely code or only partially code—alter the parties’ legal rights and obligations? It will, no matter how the term “smart contract” is defined. Even where the entire smart contract is in code, an implied-in-fact contract likely exists. Second, what will define the parties’ rights and obligations? In all likelihood, it will be the parties’ understanding of how the code was meant to operate, not how it actually operates. In contrast to a traditional contract, where parties may be bound to clear language notwithstanding extrinsic evidence that the language does not match their original intent, clear computer code at odds with the original intent will likely not bind the parties. As such, a party creating a smart contract should use great care when drafting explanations of how the code operates, even if the explanations are not intended to be binding. Third, will the fact that the explanations are binding mean other terms accompanying those explanations are also binding, such as where only part of a traditional contract has been translated into code? Not necessarily, depending on what is required to start the code operating. It is important therefore to tie explanations and other traditional contract terms closely to the code, so that the code cannot be operated without accepting all contract terms.

The problem: Confusion over the definition, operation and effect of a smart contract can lead to conflict between the parties

Some say “a smart contract literally contains the terms of the agreement, transformed into machine-readable scripting code,” where “the digital code is not just a representation of the agreement; it is the agreement,” and “everything beyond the code is just commentary.”^[xx] But there’s an internal tension in this description, reflecting a core area of confusion about smart contracts. The code cannot contain the actual terms of the agreement—the terms as the parties agreed to them—if they have been transformed into code from the form to which the parties agreed. Either the terms the parties agreed to were in code in the first place and were not “transformed,” or they were in natural language^[xxi]—English, for example—and the code “contains [a translation of] the terms.” Either way, a mistranslation between natural language and code can be highly problematic, as the creators of The DAO, a decentralized autonomous organization,^[xxii] discovered in spectacular fashion.

The DAO had a revolutionary goal: create an organization built of smart contracts that would operate autonomously—no centralized governance, no employees, just computer code operating the organization.^[xxiii] The DAO would crowdfund, then allow members to vote on funding proposals.^[xxiv] More than 11,000 people contributed over $150 million to the organization.^[xxv]

When signing up, participants agreed that the terms of the organization were “set forth in the smart contract code,” that any explanations on The DAO’s website did not supersede or modify those terms, and that if there were any conflicts or discrepancies, “The DAO’s code controls and sets forth all terms of The DAO Creation.”^[xxvi] But the code contained a “bug”—or rather, an “explicitly coded feature as per the smart contract terms”—that allowed one participant to siphon over $60 million out of The DAO.^[xxvii] Because the code defined the parties’ rights and the “bug” was an explicit part of the code, the transfer was “formally valid within the rules of The DAO.”^[xxviii] Yet, most participants and people writing about The DAO considered the transfer to be “theft,”^[xxix] and it was reversed by majority vote of The DAO’s blockchain.^[xxx] But because the code permitted the transfer, it constituted “theft” only if the participants’ rights were governed by some contract external to the code that did not permit the transfer.^[xxxi] When parties to contracts operate consistently with their contracts’ express terms, we don’t usually call it “theft”; we call it “performance.”

The DAO debacle demonstrates the importance of determining whether a smart contract will create any legal rights and obligations and if so, what those legal rights and obligations will be. Despite The DAO’s disclaimer that the code was the contract, something external to the code ultimately defined the parties’ rights.

Vending machines and code: How smart contracts operate relative to the creation of legally binding contracts

To understand the legal effect of smart contract operation, it helps to start with what makes a contract. “‘A contract is an obligation attached by the mere force of law to certain acts of the parties, usually words, which ordinarily accompany and represent a known intent.’”^[xxxii] A contract typically comes into existence when an offer, acceptance, consideration and objective intention combine. An implied-in-fact contract, “inferred, as a fact, from conduct of the parties showing, in the light of the surrounding circumstances, their tacit understanding,” best demonstrates a contract’s conceptual existence.^[xxxiii]

The operation of a “humble vending machine,” the smart contract’s “primitive ancestor,” according to Nick Szabo, the inventor of the term “smart contract,” illustrates how an implied-in-fact contract works.^[xxxiv] Obviously, a vending machine is not a contract; its slots and channels, gears and mechanisms, are not contract terms. And yet, when a buyer puts money into a vending machine, a contract is born. The offer, usually expressed at least partly in natural language on the face of the vending machine, is a “general invitation to the public to buy [a] beverage,” assuming we’re talking about a soda machine.^[xxxv] A “contractual relationship aris[es] from such an invitation with those who accept[] it.”^[xxxvi] The contract is between the beverage’s vendor and the buyer.^[xxxvii] The money and soda constitute consideration, and the intent to effect a sale through the exchange satisfies the intent requirement. The contract so created is implied in fact, its terms derived “from the circumstances shown.”^[xxxviii] If the machine provides the wrong soda or one unsuitable for human consumption, it would breach the contract.^[xxxix]

Like vending machines, even smart contracts composed only of code present contract elements. Because the code will implement a transaction, the code—or the natural language understanding of the code—constitutes the offer. Engaging the code in whatever way is required to start its operation, such as by transferring cryptocurrency to the smart contract, accepts the offer. Assets changing hands or services being provided are the consideration. Only intent is slightly ambiguous when it comes to the contract’s existence, as the parties may not intend legal enforcement to be necessary because performance happens automatically. But that’s not the same as intending the contract to be unenforceable—as in, optional.^[xl] Whether a gentlemen’s agreement is enforceable depends on what the parties intend to happen if one of the gentlemen turns out to be a scoundrel. Though they may never have intended to go to court, they may also never have intended the agreement to be discretionary. On this view, even mere code meets the intent requirement: once a party accepts the offer, setting the code in motion, performance will happen, as the parties intended.

Thus, a smart contract—even if it is only code—will alter the parties’ legal rights and obligations. Put differently, even if you think smart contracts are not themselves contracts, they generate contracts. But what sets the contracts’ terms?

Lost in translation: Because no parties may speak code, what sets the contract’s terms is a particularly challenging question

Determining the terms of a smart contract poses a significantly more difficult problem than whether a contract exists. The difficulty arises because, unlike traditional contracting that takes place entirely in natural language, at least a portion—and potentially all—of every smart contract is written in a language foreign to most people: computer code.^[xli] As such, smart contracts usually involve translating from the contracting parties’ natural language into code or the reverse.

“[A] person unable to read a contract due to illiteracy or unfamiliarity with its language may later avoid it if he or she reasonably relied on another’s erroneous translation or explanation of it.”^[xlii] This may be true no matter who did the (mis)translating or explaining—the contractual counterparty, a third party, or even a trusted adviser—and whether the “misrepresentation was fraudulent or merely mistaken.”^[xliii] Though not widely known,^[xliv] this principle of contract interpretation makes intuitive sense and has a long pedigree—and it may come to greater prominence as disputes involving smart contrasts arise.

In 1930, the New York Court of Appeals^[xlv] reached back for authority to Thoroughgood’s Case, an English case from 1582.^[xlvi] “Thoroughgood had signed a deed for lands to Chicken”—yes, that’s the counterparty’s name—that had been misinterpreted to Thoroughgood by “a total stranger to the transaction.”^[xlvii] Because Thoroughgood had relied on the misinterpretation, the deed was “absolutely void.”^[xlviii] In Pimpinello v. Swift & Co., the 1930 New York case citing Thoroughgood, the plaintiff, “[n]ot being competent to read the document,” had relied on his “trusted lawyer,” not a mere stranger.^[xlix] The outcome was the same: the contract was void.

In contrast, consider the classic four-corners-of-the-contract rule: where a contract is unambiguous, a court will look only to its express terms, using the court’s knowledge of the English language—or whatever language the contract is written in—to understand the parties’ intent and thus, the terms of the contract. These two contract interpretation principles highlight the role of natural language in the contracting process. Where both parties speak the language of an unambiguous contract, courts hold the parties to the contract without looking outside its terms. But where one contracting party does not speak the language of the contract, yet has attempted to understand it through translation, courts do not hold the party to the contract where the translation diverges from the contract’s terms.

Consider again a vending machine, but this time, one that offers on its face two sodas for $1, but is designed to deliver only one soda for $1. When a single soda comes out, we would say the machine has breached the contract even though it functioned properly according to its physical design. In effect, the contract was mistranslated into machinery—or the machinery was mistranslated into the offer on the face of the machine.

Even if the parties treated the vending machine itself as the contract, the mistranslation into natural language could void the contract, echoing the mistranslation cases cited above.^[l] With a vending machine, the buyer has no access to the machine’s innards—no way to “read” the actual contract. And even if the buyer could see inside, the buyer may be mechanically illiterate, unable to comprehend the function of its structure—the terms of the contract—putting the buyer in the same position as Thoroughgood.

Similarly, unless both parties to a smart contract speak code, at least one will be relying on a translation. But unlike some mistranslated contract situations where the two parties share no common natural language, with smart contracts, both parties may speak the language in which the explanation of how the smart contract is supposed to work is written. As with The DAO, that explanation will likely set the terms of the contract. Instead of the contract being void, the parties will be bound to the natural language understanding—the expression both parties comprehended—not the terms as expressed in the code.^[li]

While the natural language understanding will likely bind the parties, be careful if the smart contract code can be engaged directly

While any natural language explanations of how the code operates will likely bind the parties, other natural language terms will not necessarily be binding. It will depend on the form acceptance of the offer takes. The problem arises because of the potentially split nature of smart contracts, with natural language terms separate from the code, and the possibility that the code could be engaged without agreeing to such terms.

Rensel v. Centra Tech, Inc.^[lii] illustrates the problem. Rensel purchased Centra Tokens—a cryptocurrency—from Centra Tech, which had a “Token Sale Agreement” with “a mandatory arbitration clause” on its website intended to govern such purchases as well as smart contract code to effectuate the purchase.^[liii] It was possible, however, to operate the code without going through the website by sending Ether—the same cryptocurrency used by The DAO—directly to a specific online location.^[liv] Customers, like the plaintiff, purchasing Centra Tokens that way “were NOT required to check any boxes or click any buttons in order to complete their purchase; the transaction was completed automatically upon transmission of consideration to the smart contract wallet address.”^[lv] As such, Rensel was not bound by the arbitration clause.^[lvi]

While the court needed to go no further in its analysis, we can take it one additional step. Although the Token Sale Agreement did not bind the plaintiff, a legally binding contract was nevertheless created by the smart contract code—but it was a smaller, simpler contract with no arbitration clause. If the code had failed to deliver the Centra Tokens, for example, the plaintiff would have had a claim for breach of contract.

Take care to gain the benefits and avoid the risks

There are at least three broad lessons to be drawn from the above analysis. First, just because a transaction is structured entirely in computer code does not mean there’s no legally binding contract. At minimum, an implied-in-fact contract likely exists. Second, when drafting natural language explanations of how the code in a smart contract is meant to operate, use the same care and energy as if you were drafting a traditional contract. It’s likely the explanation, not the code, will define the parties’ rights. Third, be sure to tie any natural language terms to the smart contract code, so that a party engaging the code will be agreeing to any terms not reflected in the code.

Rather than thinking of smart contracts as a way to avoid natural language contracts, think of them as a way to improve the performance of natural language contracts. As long as any natural language descriptions of the code are accurate and any natural language-only terms are binding, the code should provide a benefit to the transaction without adding the potential for additional conflicts between the parties.

If you have any questions, please contact Andy Foreman or any member of the Technology or Privacy & Data Security Groups.