Blockchain-based platforms are often touted as removing the need for human trust from transactions. Traditional contracts, we’re told, can’t be trusted. Cryptographically secure peer-to-peer platforms make trust moot and guarantee performance. That’s the claim.

For example, Nakamoto’s bitcoin ur-text summarizes the bitcoin project as “as system for electronic transactions without relying on trust.”[1]. Ethereum also emphasizes trustless transactions: “Using Ethereum, you can create a contract that will hold a contributor’s money until any given date or goal is reached. Depending on the outcome, the funds will either be released to the project owners or safely returned back to the contributors. All of this is possible without requiring a centralized arbitrator, clearing house or having to trust anyone.”[2].

How do old-fashioned legal contracts handle trust? By law and convention, forming a contract requires some standard things. Offer, acceptance, and consideration are common requirements. Performance is too. (Precise terminology will depend on jurisdiction). You also usually have to be a legal adult, with some exceptions. But a 7 year old can’t generally form a contract.

A contract can be confirmed by a handshake, though some will say this defeats the purpose (and not all contracts can be verbal). Contracts can also be written documents with thousands of pages of terms.

It may be easier to breach a contract than to create one. Failing to perform is one way, though all failures aren’t breaches. Sometimes breaches are material, and sometimes they aren’t. It depends. Contract terms, caselaw and facts will determine this. Still, every contract, no matter how complicated, contains some variation on this theme: X agrees to do P1 for Y; in exchange Y agrees to do P2.

But what about trust? One thing you won’t find in most textbook defintions of “contract” is the word “trust”. In fact, you can argue that contracts were initally innovative because they removed some or all of the need for trust in transactions. People removed the need for “trust” with instruments that confirm what X and Y will do. Courts provide a public means to enforce private obligations in the event of a breach.

Of course contract formation can be hard in practice. This creates trust problems. Complex obligations can be difficult to reduce to words, which themselves are subject to interpretation years later. And another problem is that people don’t always know what they want, and what they want may change. Misunderstanding leads to litigation as often as malice. Maybe the widget contract specified “large” widgets, and Buyer thinks large widgets are 11 units long and Seller thinks that they are 12 units long. There are ways to prevent this and rules to sort out who is right. Whatever the reason and the remedy, and whomever’s fault it is, you’re left with a lawsuit, instead of a load of widgets, which was the point to begin with.

Contract remedies are available if someone breaches a contract. But they are often no substitute for performance. Just ask poor old Hadley, the plaintiff in Hadley v. Baxendale, which generations of law students have been treated to in their first year contracts class. If I really need widgets by D date, contract remedies may not matter if my business fails because I didn’t receive the widgets on time. I might be able to enforce a default remedy with a letter of credit or bond, or a lawsuit but what I really wanted was the widgets. I trusted you to get them. I also trusted that the legal system would enforce my remedies in the case of breach (even if I wanted the widgets and not my “lost expectancy”, per the Hadley court). Bottom line: trust was always a factor, even if it wasn’t an explicit term.

Centuries of laws have been built around contract formation and breaches. Along the way — perhaps recognizing that trust matters (and hadn’t really gone away), some courts even added it as a term, creating something called an implied duty of “good faith and fair dealing”, which in many jurisdictions all contracts are deemed to have. (An implied term is one that exists even though the parties didn’t include it. You can read more about how this particular one works in the U.S. in the Supreme Court’s decision in Northwest, Inc. v. Ginsberg, available on the court’s website, here.)

Depending on jurisdiction, this implied duty may grant a plaintiff remedies beyond what a breach might ordinarily entail. Other kinds of contractual relationships may have fiduciary components that by their nature require particular or heightened kinds of trust. An attorney-client relationship is one example. In these relationships, trust (and the obligations that come with it) are also implied by law. And an actor’s “trusted-ness” may be licensed, regulated or state-sanctioned (again, as with an attorney).

The law also anticipates that people will make honest mistakes in the process of contract formation. Doctrines like recission, mutual mistake, and reformation allow drafting errors to be fixed by courts and prevent parties from being subject to unfair or inequitable results. Many other safeguards have been built in, whether by judges or legislatures.

Given all of the flaws in traditional contracts and in people, the concept of trustless peer-t0-peer transactions has great and understandable appeal. Performance automation means I don’t need to trust what my counterparty says in a written contract. In theory, I can turn a contract on and performance just happens. No need for remedies.

But let’s come back to trust for a second. Has it really gone away? Smart-contract trustless-ness at its most aspirational connotes a transaction in which the parties have (1) a borg-like mind-meld certainty that they want the same thing and (2) a guarantee that the thing will be done. With this certainty, it’s almost like the contract becomes an extension of oneself and the notion of paper contracts, courts and remedies disappears.

But trust didn’t really go away, did it? It moved from contractual counter-parties, courts and lawyers, to platforms and developers. If I am going to use SoupChain[3] to automate contract performance, I need to trust that it was built right and the people who are building it are trustworthy and that it’ll perform as promised. I have to trust that it is trustless. (Should I? I read stuff like this article titled “Hijacking Bitcoin: Large-scale Network Attacks on Cryptocurrencies” and I wonder).

Developers may fairly criticize written contracts for containing confusing “boilerplate”, and it’s a problem for sure. (Here’s something I wrote a few years ago on this very topic: “Boilerplate, subrogation waivers and choice of law”). But it’s possible to substitute one black box for another. And the notion that programming language is easier to read and less ambiguous than human language falls apart if you poke at it. Programming languages are human created too. They also require human judgment to create and establish data structures, variables and functions that serve as terms and conditions. And many more people can read English or Russian or Japanese than can read and understand Solidity.

Boilerplate isn’t unique to human languages. It can appear in code too, along with ambiguity. And code cannot only create ambiguity, it can instantiate it and make it live. There’s something to be said for a static, dumb contract, as opposed to a dynamic living contract. If you are building the latter, you better have a high degree of trust in its construction.[4]

Trust is a human quality or characteristic. Code is only trustworthy in relation to humans who create it or use it. Code can be dangerous or harmful, but the normative component of the word “trust” implies human agency or judgment that created the code in the first instance. Calling code trustless or trustworthy may shift focus from where it should be, on the people who create and maintain it and on the code’s efficacy, safety and functionality. Does it do what it supposed to do? Do the people who built it have the skills, training and competence to assure that?

There are clearly some people in the blockchain and bitcoin world whose involvement in a platform are intended to signal a high amount of trust because they are assumed to know what The Right Thing (“TRT”) is. Saying that they are trustworthy (or have a good reputation) suggests that they are honorable, will do what they say, and have a high TRT value. At the moment, there aren’t alot of standards that allow you validate this externally. Figuring out who or what to trust requires a lot of discretion and lot of knowledge.

It doesn’t make sense to criticize a wrench for not being a screwdriver. Neither is it fair to criticize the inventor for failing to create the regulations to govern its use while in the process of invention. That’s not my intent. You can safely automate contract performance using “smart contract” technology. Plenty of smart people are working on doing just that.[5]. But while you can try to move trust from transactions to platforms, the need for trust remains. (This is an example of the first law of lawmodynamics in action). It didn’t disappear, it just moved.

Traditional contract law may have many failings. Courts and lawyers too. But the law recognizes this. Because of this, fail-safes have been built in, created over generations so that your child can’t sign a contract to sell your home for you or that the person who is writing a will for you will do so in a competent fashion, and suffer consequences if they do not.

Blockchain based platforms may become easier to trust if they acknowledge that the need for trust abides, and acknowledge where it lives. Centuries of contract law may provide some useful lessons. The technology may be new, but if history is any guide “[a]ll of this happened before, and all of it will happen again.”[6]

** photo credit: https://pixabay.com/en/mother-child-sculpture-fig-family-589730/

*** Disclaimer: these are my personal opinions, and may not by shared by past, present or future clients or any law firm with which I am affiliated. It’s also not legal advice. Don’t take legal advice from a blog post!

[1]. Satsoshi Nakamato, “Bitcoin: A Peer-to-Peer Electronic Cash System”, p. 9. (available at https://bitcoin.org/bitcoin.pdf).

[2]. https://ethereum.org

[3]. SoupChain: not a thing, as far as I know. Maybe it should be.

[4]. See Stanislaw Lem, “The Electronic Bard”, available at http://sfbay-anarchists.org/wp-content/uploads/2012/05/Trurls-Electronic-Bard.pdf.

[5]. Gratuitous marmot reference.

[6]. Battlestar Galactica, probably referencing Eccelsiastes 1:9.