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.
The Backdrop
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.
Smart Contracts Defined
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 abet 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.
Smart Code — Transactions
running entirely on a blockchain
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.
Coded Legal Contracts
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.
A Continuum
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.
No comments:
Post a Comment