What do smart contracts provide that legal contracts don’t? How do both kinds of contracts manage problems of ambiguity, and how can blockchain systems manage ambiguity well?

I recently found a notes from a great talk on this topic by James Grimmelman in December 2018 that I never published, from my time at the Princeton Center for Information Technology Policy. James Grimmelmann is a professor of law at Cornell Tech and Cornell Law School, where he studies how laws that regulate software affect freedom, wealth, and power. He helps lawyers and technologists understand each other, applying ideas from computer science to problems in law and vice versa. When I recently asked if I could publish this post, James said that while his ideas have developed further, it’s a good summary of his thinking at that time.

What is the blockchain?

James opens up by introducing blockchain ideas. The blockchain is a transactional ledger that is cryptographically secure, does not require a centralized recordkeeper, uses incentives to ensure consensus. If this works well, you reduce the need to trust the counter-parties or centralized recordkeepers. Smart contracts don’t have to run on a blockchain- although today’s talk will focus on the blockchain. By embedding terms of a contract in hardware/software, smart contracts manage automated interpretation and enforcement of contracts.

What are the advantages of a smart contract compared to a legal contract? Typical legal contracts have three sources of uncertainty. First, language is ambiguous: a contract’s meaning might be unclear. Second courts make mistakes and fail to enforce the contract. Finally, parties can escape enforcement, ignoring the terms of the contract.

Can the blockchain solve the problem of legal ambiguity?

James talks about language ambiguity through the story of Frigaliment v. B.N.S.. In this case, parties went to court over whether the definition of “chicken” meant “any bird of that genus” or vs “any young chicken suitable for broiling and frying.” You might try to define the terms more clearly, but the debate can get ever more nuanced over the meaning of “chicken.”

Courts also make mistakes, says James. Litigation is uncertain. And not every court judgment is worth the paper it’s printed on. Some defendants have no assets to pay, have fled the jurisdiction, or just have vanished into thin air. And you can’t always get your property back because it was destroyed, or sold to a third party.

Smart contracts provide answers to many of these sources of uncertainty, in theory. If you write the contract as a computer program, the program is unambiguous. Next, by de-centralizing the decisions, miners will collectively prevent mistakes. Finally, you can give the smart contract control over the assets. To summarize: legal contracts are run by humans who are fallible, while smart contracts are run by computers. They’re precise, deterministic, and reliable. Are these claims true?


“Everything I just said is wrong,” says James.  The idea that there is a technical meaning standing apart from a social meaning, he says, is just wrong. 2+2 in Python evaluates to 4 because that’s how the language was defined by humans not because there is some true Platonic form of mathematical representation.

To illustrate the problem of ambiguity in smart contracts, James points out to three ways that we might identify the meaning of a program. We could use a “reference implementation” for how Python behaves. We could define a “specification” in English that defines the behavior of a correct implementation. Finally, you could use mathematics: outline a formal semantics that identifies programs with abstract entities. All three of these methods have in common the fact that some people got together to write them and put all of their flaws and failings into their attempt. What makes one of them definitively correct is that people agree that it is- these are social facts just like the definition of “chicken.”

The meaning of programs is determined by a technical community who agree on a process for deriving meanings from texts. Developers then implement that process on different computers with different tools. Most of the time, the same program running on different computers yields the same result. We perceive things as technical facts in those cases where programmers arrived at consensus. 

When someone claims “Program P does X when run,” says James, it requries shared assumptions about the specific language, the semantics of the program, and the hardware environment. In theory, blockchain can achieve all three things by working within a specific VM implementation. This breaks down when contracts include bugs.

Your Bug is My Feature

What is the difference between a feature and a bug? Everybody knows the joke, and the joke is about the social construction of meaning. When we use blockchain, we ensure that running a program produces a result– but not necessarily the right result. Specifying in advance the resolution of all possible ambiguities is also a receipt for predictably getting many of them wrong. James next explains a wide range of sources for bugs. He then argues that many of these sources of bugs are also sources of misunderstandings and mistakes in courts.

We might be able to ignore these problems if people never argued over the semantics of smart contracts all the time. But people argue about these things all the time. James tells us about the DAO, an investment scheme that ran a venture capital fund using ether. They had legal terms saying that the terms were set forth in the contract code running on Ethereum, with no recourse in the world outside the blockchain. 

The DAO smart contract had a bug, someone found a way to drain the Ether, and if the code was the sole version of the contract, then everyone legally gave their money to that person. What happened? Ethereum upgraded to a new version that specifically unwound the DAO transactions. Not everyone was happy with this, and some people forked Ethereum, creating a disagreement over the semantics of smart contracts.

Every blockchain is always potentially at risk of forking, says James. If anyone objects enough to walk away, the dispute becomes visible as a fork in the software. Anyone could decide to change the semantics at any time. These blockchain forks are visible records of disagreements. While each blockchain is unambiguous, the ambiguity is managed in the choice of blockchains or the possibility of forking. In the case of the DAO contract, the contract assumed that there was a single unique ethereum blockchain, but it turns out that the it could refer to more than one blockchain.

“I don’t mean to sound like a complete skeptic,” says James. This argument tells us more about how smart contracts can work rather than how they can’t. Smart contracts are based on social facts, those facts can change, and they’re always open to argument. Legal contracts are also based on social facts, but they work just fine for many uses. Smart contracts can’t be perfectly unambiguous, but they can still be unambiguous enough to work.

Technology as Consensus

What do blockchains achieve? They force you to acknowledge that consensus is at the heart of agreements. Every contract is open to the possibility that some group of people could be persuaded to change how it works. The contract is consequently political, and any blockchain that doesn’t have governance will collapse, fork, or be hijackable. Blockchain, like contract law, is held together by social institutions. There’s no escape from politics.

What might good blockchain citizens look like, asks James. Good citizens contribute to stable software, as well as stable institutions. In a world where people make mistakes, where bugs happen with regularity, and where protocols need to change, there will be times when changes make sense. Negotiating those decisions will require more than just code- it will involve mailing lists, growing broad developer knowledge, and committing to the long-term health of the project. 

To sum up, James tells us that “governments are made of people, and so are blockchains.”

Photo credit: image by JD Hancock CC BY 2.0