Deconstructing “Code Is Law” and Layer 2 “Smart Contracts”

Layer 2 “smart” contracts typically spend participant’s money to an N of N multisig controlled by all participants, and/or an arbiter. To be a bit sardonic, in this architecture you get to use cool, trendy “smart contracts” up until someone honest thinks something went wrong, or someone dishonest thinks that they can take advantage of you, and at that point you are back to human negotiation and the judicial system. For example, given a 2 party contract based on top of 2-of-2 multisig, let us presume that the contract execution awards the money to party A. Party B can simply choose to not acknowledge that and refuse to sign the spend transaction. At this point the only option is a negotiation between A and B. Any such negotiation ultimately comes down to who needs the money more verses who is willing to let it sit, potentially indefinitely, in the multisig address. Ultimately, A may be able to sue B in an attempt to use the judicial system to force B to sign the transaction. A similar exploit is possible with an arbiter (based on 2 of 3 multisig, say) by compromising the arbiter. Sounds a lot like paper contracts, right?

Weren’t “smart” contracts supposed to be more than that?

Yes, the original smart contract concept is better described as “trustless, uninterruptible contracts”. This is the crux of smart contracts. The fundamental difference between this technology and current pen-and-paper contracts with manual at-will execution is that the contract is executed as stated, automatically and unstoppably, no matter what. Smart contracts are therefore very different than traditional contracts, and have different advantages and disadvantages.

This is the formulation that I will refer to for the rest of this document when using the term “smart contract”, and I will refer to architectures that record traditionally executed contracts on the blockchain as “blockchain settled contracts”.

If you believe that contracts are generally more correct than wrong, then you can see how one could argue that in general it is better to use “trustless, uninterruptible contracts” and allow parties to negotiate fix-ups for any contractual errors afterwards than to allow either party to stop executing the contract whenever they want to, forcing litigation and a judge that determines what to do.

Code Is Law

The phrase “code is law” has been misunderstood to accuse advocates of proposing that in a smart contract “world”, code will supersede or even enable the removal of the legal/judicial system. This is simply not the case. “Code is law” is a shorthand for the idea proposed above — that a smart contract will execute as specified without interruption, and that that’s generally a better choice than allowing any party to interrupt execution at any time. “Breach of contract” suits are therefore impossible, but “smart contract is legally invalid” or “smart contract did not match human understanding” suits are very possible.

But in cases where there jurisdiction is unclear, where the contract value is too small to justify the expense of a suit, where parties are not identified, or where there is no clarifying “human” agreement, the smart contract’s content effectively defines and guarantees the final outcome because the difficulty of bringing or winning a suit is overwhelming.

Uses For Smart Contracts?

The above statement is very important. Prior to smart contracts, this list of situations was basically was a danger checklist. Entering into a contract with some of the above qualities would result in a significantly higher chance of a negative outcome. International deals, small values, unidentified parties (or parties who can disappear easily — for example, a small business), and unclear contractual terms (often complicated by foreign languages) all contribute to a higher risk for negative outcomes.

Smart contracts may fill the niche described by this “danger checklist”, because it is not possible for the other party to interrupt the contract’s execution.

Uses for Blockchain settled Contracts?

However, smart contract rules may be manipulated by a dishonest party in a manner which any human would see as clearly against the intention of the contract. In this case the “smart” contract is actually extremely dumb — it will execute its rules allowing the exploit, whereas a human would likely stop. This is what happened in the infamous Ethereum DAO hack.

To round out the negatives, smart contracts may be not applicable or provide only marginal benefits in many situations that already require trust. For example, a smart contract for widgets may pay based on some signed statement by the delivery service, allowing the sender to trigger payment by mailing an empty box.

Today, when people think of contracts, they typically think of agreements that require trust. Payment for service. Payment for digital goods. Agreement to deliver N widgets on some schedule. Smart contracts cannot determine whether the goods were delivered or the service completed. So for the majority of contracts blockchain settled contracts may be the only applicable technology for what we see as contracts today.

Hybrid Contracts: Using Smart Contracts as a better base for Blockchain Settled Contracts

An interesting evolution is hybrid smart and blockchain settled contracts. This may allow contracts to stipulate certain undeniable guarantees, but still have the applicability of blockchain settled contracts. For example, in the introduction I showed that problem with basing blockchain settled contracts solely on multisig is any problem results in a traditional negotiation between parties. In a payment for service contract, this could be very bad for the service provider because toward the end of the contract, it has completed or nearly completed the work, yet the purchaser has invested nothing. A better base for this kind of contract could be a smart contract that has an exit clause in which the service provider receives some payment that is proportional to the time passed (this is different than periodic payments — the implication, which may be important in subsequent litigation, is that the contract was breached and a penalty payment made, periodic payments may imply that one party exercised his right to amicably terminate the relationship). Another possibility is that the contract verifies that periodic payments are made, and exits with a penalty payment to the service provider if a payment is missed.

You can see movement to hybrid contracts in the token community. Originally, tokens were controlled entirely by smart contracts, but various exploits and hacks have convinced designers to give powers, like the ability to force-upgrade the token to a new version, to the underwriter. But I believe that in some cases too much power is being given away. After a few exploits by the underwriter (or criminals compromising the underwriter’s authority) we may find token contracts moving to a middle ground that carefully offers very specific powers to the underwriter.

Finally hybrid contracts can be used to minimize and isolate trust. This is the goal of DATASIGVERIFY (implemented as OP_CHECKDATASIG in BCH). A hybrid contract could be written to pay some escrowed money to person Alice or Bob, based on a signed statement (using CDS) by Carol. Unlike traditional escrow, Carol cannot in any way access the money. She must conspire with Alice or Bob. But in general, Carol is expected to run an “expert service” (building inspection, for example) where a false statement will undermine her future business and potentially lead to prison.

So smart contracts are no panacea. Like any new technology, they will be useful in some situations and not in others. Their most common use may be underpinning clauses in hybrid contracts, but that is still an incredible innovation. But if your so-called “smart contract” system is really a blockchain settled contract. If it does not have the property of guaranteed trustless execution, then it is not novel. It is not fundamentally different than traditional contracts, and is more similar to placing an agreement written in english into an OP_RETURN than it is to trustless, uninterruptable smart contracts. It therefore may not be useful in elevated-risk situations, and should be valued by investors accordingly. And finally, shame on you for exploiting buzzwords and creating confusion by disguising the same old thing in the clothes of a genuinely novel and interesting technology.