Published in


How to Think About “Smart” Contracts

The Road From Legalese to Code

Summary: Before we can decide whether smart contracts are going to bring significant change to business and law, we first need to make sure we’re all talking about the same thing.

The term “smart contracts” gets tossed around a lot lately in the context of blockchain and related technologies. As an attorney, I’m often asked what the term means, and whether smart contracts represent a big shift in the future of contracting.

The short answers are: (1) it depends; and (2) sort of.

It does seem that everyone is talking about smart contracts. People tend to line up on one side or the other: Either smart contracts are going to have a revolutionary impact on business, or they are doomed to fail. A recent article in The Economist took something of the latter view, for instance:

If smart contracts spread widely, you would take away much of the flexibility that smooths the economy’s functioning. Real-world institutions can adjust when things go wrong. For many years to come, and perhaps for ever, human institutions, flawed though they are, will be a smarter bet than relentless, bug-ridden code.

Compare that with a recent headline about the formation of the “Smart Contracts Alliance” by the Chamber of Digital Commerce:

Smart Contracts Alliance Aims to Help “Change the Landscape of Modern Business”

But sometimes the debate has the aspect of ships passing in the night.

A key reason for this is terminology.

First, let’s ask a threshold question: What is the difference between a “transaction” and a “contract”?

A working definition of “transaction” might be “an exchange of value between two or more parties.” Now, unless that transaction is simultaneous, at least one party is always promising to deliver their part of the exchange at some time in the future. In other words, some uncertainty derives from the element of time and the ability for one party to renege on the deal. And if there’s no enforcement mechanism, this is just a bet on compliance.

The enforcement mechanism can be many things: law, risk to reputation, or even “self-help” (some guy named “Knuckles” who “knows wheres you live”).

If the enforcement mechanism is based on law, we typically require that before a purported contract is enforced, there is proof that the parties actually decided upon the value exchange. In legal terms, we make sure there has been OFFER and ACCEPTANCE. Depending on the complexity of the arrangement, and the length of time involved, we set these agreements down in writing — but ultimately this is still about proving the parties’ deal.

So, what is a “smart” contract?

Turns out, in some situations its really just a transaction, and in others it’s more like a legal contract. In fact, we can identify several different kinds of smart contracts:

  • Transactional instructions running entirely in code
  • Legally enforceable contracts at least partially expressed in code

That’s why I said earlier that it depends. It depends on context.

Blockchain developers and engineers often mean smart code when they talk about smart contracts. Essentially these are computer programs, but when stored and executed on a blockchain people use the term “contract” because the code is self-executing: it can automatically complete a transaction by moving value from one party to another. We’ve discussed this type of “smart contract” in prior posts.

So, when these kinds of “smart contracts” reside on a blockchain, they have the following unique characteristics:

  • Transactional parameters that can be arranged by arms-length parties (i.e., across trust boundaries)
  • The program itself is stored on blockchain, and can control assets
  • Once programmed, neither party can renege — the code itself controls enforcement (although the parties could potentially build in safety valves that would allow for halting execution on mutual agreement)

Using our distinction earlier between “transactions” and “contracts”, these probably fall closer to a transaction than a true contract. Since by definition they are largely unstoppable after they are coded, whether they are truly a legal contract may not much matter — the value exchange is going to happen.

But assuming one party is unhappy with the result and wants to “undo” the transaction (and the other party is able to be located, and still has possession of whatever has been exchanged), presumably enforceability would be determined by looking at the traditional legal concepts for existence of a contract: Was there consideration, offer, acceptance, mutual assent?

If the only terms the parties agreed upon were just defined by the code itself (as opposed for instance in communications preceding the deal), then even i a court can find a contract it is unlikely that the court could ever find a “breach” since the code can only execute the parties’ terms faithfully. This is an argument that has been discussed at length in connection with TheDAO, the autonomous blockchain-coded investment vehicle created in April that raised over $150 million, but which contained a flaw that a user exploited to drain nearly a third of the value (until the Ethereum hard fork, but that’s a story for another post).

Was this exploitation of TheDAO a contract breach or, if the “code is the law,” was the flaw in essence a part of the “terms” of the deal? In the case of TheDAO, there was not even a true counter-party to the transactions when users contributed their cryptocurrency to the project — they were “contracting” with a distributed software program. It seems unlikely that a court would easily find a traditional breach of contract in this instance, although there are other legal claims that an investor might have brought, as explained in a great article by Drew Hinkes.

In any event, this type of smart contract is really just a way of saying that parties have agreed to an irrevocable series of events that will take place upon the occurrence of certain conditions.

When lawyers talk about smart contracts, we’re often talking not about pure code, but about standard legal contracts with provisions that can be reduced to code (especially on a blockchain). Usually these provisions will be the “executable” part of the contract: The part that sets out what the parties have to do in order to complete the deal.

To take a simple example, I agree to create a new app for you called “Tao of the DAO”, which provides relaxation tips to users whose digital currency has been lost in unfortunate online schemes. You agree that once the app is delivered and you have approved it, I will earn 10% of the purchase price for every download by a user. After 10,000 downloads, my percentage goes up to 20%.

Obviously, your approval of the app is not something that could easily be coded, unless the “approval” was simply hitting certain technical benchmarks. If things like aesthetics matter to you, you’re simply not going to hand over that portion of the contract to the code, you’re going to want to review the final app yourself.

However, we might well commit the payment aspects to code, especially if the process of purchasing the app by a user is handled using a blockchain-based system: The user pays his or her money, and the money automatically moves to our respective wallets/accounts in the correct percentages.

Under this scenario, you and I would enter into a traditional contract that might have many other terms, including dispute resolution, warranties, indemnities and the like. We would be agreeing in the larger contract that the code would control execution of the payment provisions.

Such a contract is likely enforceable, so long as the overarching agreement demonstrates offer and acceptance, etc.

One way to view these two different categories of smart contracts is just to see them along a scale, from existing legal contracts, to legal contracts that are partially reduced to code, to transactional terms completed reduced to code. Which type we chose will depend on a variety of factors, and in particular on balancing the need for efficiency and speed with the need to cover all contingencies.

Another key issue is simply how much and which parts of existing legal contracts can actually be reduced to code. That’s an issue we intend to discuss tomorrow in another post.

Going back to that second question that we started with—do smart contracts represent a big shift in the future of contracting — my answer is “sort of” because to the extent we are talking about self-executing code on a blockchain between arms-length parties, then yes, this is something quite new and different, and may challenge existing legal conventions. But if we’re talking about traditional contracts being reduced to code, those fit pretty neatly into existing legal structures and while I think we’ll see a major acceleration of reducing contractual provisions to executable code, that’s not as much of a game-changer, purely from a legal perspective, as the first category.

Although it’s going to be an interesting ride either way.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -

Note: I am very indebted to an article by Josh Stark in which he distinguishes what he calls “smart contract code” from “smart legal contracts”; although others have covered similar ground, I found his article one of the clearest conceptual pieces on smart contracts to date.

As always, the opinions expressed on this blog should not be taken as legal advice.



Musings on Distributed Applications for the Arts and Beyond

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Lance Koonce

Father, Tech/IP Lawyer, Dis(Mis?)placed Carolinian. Tweets about #IP #blockchain #bitcoin #AI #VR #privacy #NYCtech