View COVID-19 resources from Porter Wright here.
October 26, 2020 / Law Alert

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.


[i] Tim Swanson, Great Chain of Numbers: A Guide to Smart Contracts, Smart Property and Trustless Asset Management 11 (2014) (footnotes omitted); see William Mougayar, 9 Myths Surrounding Blockchain Smart Contracts (Mar. 23, 2016),

[ii] Kevin Werbach & Nicholas Cornell, Contracts Ex Machina, 67 Duke L.J. 313, 314–15 & n.5 (2017).

[iii] Propy, Propy Completes the First Real Estate Deal Recorded on Blockchain in the US, Medium (Mar. 12, 2018),

[iv] Banco Santander Issues $20 Million End-to-End Blockchain Bond, Blockchain Land (Sept. 13, 2019),

[v] Spanish banks to test programmable payments for smart contracts, Finextra (Dec. 20, 2019),

[vi] Populous World, Autonomous Invoice Discounting On The Ethereum Blockchain…, Medium (Sept. 21, 2018),

[vii] Nine Companies Using Blockchain to Revolutionize Insurance, Built In (Apr. 6, 2020), (describing Lemonade, Teambrella, and Fizzy).


[ix] John Carolin, B3i’s Blockchain Re/Insurance Network Begins to Offer Real-Life Industry Solutions, Insurance Journal (Oct. 22, 2019),; Blockchain Initiative, B3i, Deploys Cat Excess of Loss Product for January Renewals, Insurance Journal (Oct. 15, 2019),

[x] Major re/insurers and brokers complete complex placements on B3i’s blockchain platform, B3i (Feb. 12, 2020),

[xi] Major enhancements to B3i’s reinsurance solution, B3i (Sept. 15, 2020),

[xii] BNP Paribas Securities Services joins forces with Digital Asset to develop DLT trade and settlement apps, BNP Paribas Securities Services (Sept. 15, 2020),

[xiii] Blockchain Technology Act, 205 ILCS 730/1–20 (Jan. 1, 2020); Blockchain Technology Working Group, KRS § 42.747 (July 15, 2020).

[xiv] Law Commission, Adapting English law for the digital revolution (Sept. 21, 2020),

[xv] Id.

[xvi] The definition used by the Smart Contracts Alliance of the Chamber of Digital Commerce does not even require a transaction between parties: a smart contract is “[c]omputer code that, upon the occurrence of a specified condition or conditions, is capable of running automatically according to pre-specified functions.” Smart Contracts Alliance, Chamber of Digital Commerce, Smart Contracts: Is the Law Ready? (Sept. 2018), By this definition, essentially every computer program or piece of software is a smart contract.

[xvii] Josh Stark, Making Sense of Blockchain Smart Contracts (June 7, 2016),

[xviii] Discuss. See Linda Richman, S.N.L. (1991–94); see also Avivah Litan, Smart Contracts are Neither Smart nor are they Contracts (Mar. 3, 2020),; David B. Black, Blockchain Smart Contracts Aren’t Smart And Aren’t Contracts, Forbes (Feb. 4, 2019),

[xix] 205 ILCS 730/5 (emphasis added).

[xx] Werbach, 67 Duke L.J. at 344, 347, 350.

[xxi] A natural language is a language that developed naturally among humans.


[xxiii] David Siegel, Understanding The DAO Hack for Journalists (July 9, 2016),

[xxiv] Id.

[xxv] Id. Though The DAO currency was Ether, a cryptocurrency like Bitcoin, approximate dollar equivalents to the amount of Ether are used for simplicity.

[xxvi] The DAO - Explanation of Terms and Disclaimer,

[xxvii] An Open Letter To the DAO and the Ethereum community,; Werbach, 67 Duke L.J. at 350–51.

[xxviii] Werbach, 67 Duke L.J. at 351.

[xxix] E.g., id. (“stolen funds”).

[xxx] Antonio Madeira, The Dao, the Hack, the Soft Fork and the Hard Fork (Mar. 12, 2019), The DAO was built on the Ethereum blockchain. Holders of Ether, the blockchain’s cryptocurrency, voted overwhelmingly in favor of performing a hard fork of the chain, a technical revision that split the chain and effectively reversed the transfer.

[xxxi] See Adam J. Kolber, Not-So-Smart Blockchain Contracts and Artificial Responsibility, 21 Stan. Tech. L. Rev. 198, 219–21 (2018).

[xxxii] Bayer Corp. v. Chestnut Acquisition Corp., 189 F. Supp. 2d 153, 158 (S.D.N.Y. 2002) (quoting Hotchkiss v. Nat’l City Bank, 200 F. 287, 293 (S.D.N.Y. 1911) (Hand, J.)); see Werbach, 67 Duke L.J. at 339 & n.134.

[xxxiii] Baltimore & Ohio R. Co. v. United States, 261 U.S. 592, 597 (1923); Armstrong v. Clarkson Coll., 297 Neb. 595, 613 (2017).

[xxxiv] Nick Szabo, Smart Contracts: Building Blocks for Digital Markets (1996),

[xxxv] Burke v. Associated Coca-Cola Bottling Plants, Inc., 7 A.D.2d 942, 942 (N.Y. App. Div. 1959).

[xxxvi] Id.

[xxxviii] See Sparrow v. Airport Parking Co. of Am., 289 A.2d 87, 91–92 (Pa. Super. 1972).

[xxxix] See Burke, 7 A.D.2d at 942.

[xl] Werbach, 67 Duke L.J. at 340.

[xli] See Pierluigi Cuccuru, Beyond Bitcoin: An Early Overview on Smart Contracts, 25 Int’l J. L. Info. Tech. 179, 188–92 (2017).

[xlii] Del Rosario v. Del Rosario, 116 Wash. App. 886, 898 (2003), aff’d in part, rev’d in part, 152 Wash. 2d 375 (2004); see Sofio v. Hughes, 162 A.D.2d 518, 520 (N.Y. App. Div. 1990); 7 Corbin on Contracts § 29.9 (2019). Although the Washington Supreme Court in Del Rosario v. Del Rosario ultimately declined to adopt the rule as articulated by the appellate court, it was only because the issue “was not presented to the trial court and was not adequately briefed or argued by the parties,” not because it was incorrect. Del Rosario v. Del Rosario, 152 Wash. 2d 375, 378 (2004).

[xliii] Id. But “a person who signs a contract written in an unfamiliar language must attempt to have the contract explained or bears the risk of mistake.” Id. at 896.

[xliv] Del Rosario, 116 Wash. App. at 896–97 (finding “very few cases in other jurisdictions” where “a person who is unfamiliar with a contract’s foreign language signs the contract after having another explain its contents, only to later find that the translator has misread or inadequately explained the document”).

[xlv] Pimpinello v. Swift & Co., 253 N.Y. 159, 161 (1930).

[xlvi] Thoroughgood v. Cole, (1582) 76 Eng. Rep. 408, 2 Co. Rep. 9 a.

[xlvii] Pimpinello, 253 N.Y. at 164; Thoroughgood, (1582) 76 Eng. Rep. at 408–09.

[xlviii] Pimpinello, 253 N.Y. at 164.

[xlix] Id. at 165.

[l] Or it could bind the parties to the mistranslation—see below.

[li] See generally Jean Bacon, Johan David Michels, Christopher Millard & Jatinder Singh, Blockchain Demystified: A Technical and Legal Introduction to Distributed and Centralised Ledgers, 25 Rich. J.L. & Tech. 1, 51–53 (2018) (discussing issues related to human-readable language versus computer-readable code, including whether and when legal obligations could be limited to terms expressed in code).

[lii] No. 17-24500-CIV-KING/SIMONTON, 2018 U.S. Dist. LEXIS 100720, at *1, *25–40 (S.D. Fla. June 14, 2018).

[liii] Id. at *25–26.

[liv] Id. at *31.

[lv] Id. at *30–32.

[lvi] Id. at *39–40.