Crypto and the law: harmony with separation

Common law legal contracts are more flexible than many people know. We can take advantage of this flexibility to "contract out" of unproductive legal defaults and reduce the tension between the systems.

In the following article we propose a simple idea and enumerate the implications.

Smart contract code is the canonical description of the rights and obligations of transaction parties except to the extent that the legal system alters them compulsorily.

Code is better

When a lawyer drafts legal wrappers for smart contracts, they often look for ways to fit the smart contract into existing legal concepts. We think that’s a mistake.

If we want better smart contracting to develop, we shouldn't define how the smart contract works by reference to legal concepts because:

• code can create a larger topography of more precisely implemented concepts than law;
• legal concepts are governed by a slow, monopolistic system; and
• legal concepts are more likely to be captured by regulations enacted by the slow, monopolistic system.

We want:

• smart contracts to operate with as little hindrance from the legal system as possible; and
• to be as consistent as possible with the law (because legal compliance is not optional).

The way to do this is to “separate the concerns” of crypto and law, which is to say, reduce the overlap of what the systems deal with as much as possible.

Architecture

In the OSI Model (Open Systems Interconnection Model) used to run the Internet, there’s an engineering separation of concerns between:

• HTTP (application);
• SSL (data presentation);
• Ports (session);
• TCP (transport);
• IP (network address);
• Ethernet (data link); and
• Physical cable.

In this system:

• nodes interact with each other on multiple layers; and
• those layers deal in a non-overlapping way with functions required for the nodes to interact.

The functional layers are ignorant of each other except to the extent that they:

• receive input from the layer above;
• perform the function operation and "wrap" the input with the result of the layer function (known as encapsulation); and
• pass the result to the layer below.

Smart contracts and the legal system

We think an OSI-like-model applied to smart contracting looks like this:

• user interface (user input);
• blockchain smart contracts (transaction operation);
• legal contract (legal system representation);
• nation state legal system (dispute resolution); and
• nation state guns and cages (enforcement).

By using layer separation to govern the interaction of smart contracts and the legal system we allow each system to operate in their own internally consistent ways without having to attempt to reconcile the fundamental inconsistencies between them.

If we take this approach:

• there’s no concept compatibility problem where we are stretching / distorting legal concepts to represent the smart contract code;
• the surface area for mistakes is smaller because there is no concept “sync” necessary between the concepts on the different layers;
• standardisation can be advanced on each layer with fewer complexities;
• coders can be more confident in their experimentation with smart contracts without being “held back” by lawyers looking for non-existent analogies; and
• it’s easier to reason: abstracting away the complexity of the lower layers allows you to build and trust that that layers underneath are going to work.

Wrapper implementation

Consistent with the ideas above, here’s an attempt to define the principle for how the legal wrapper “understands” input from the crypto layer above.

Smart contract code is the canonical description of the transaction except to the extent that the legal system is unavoidable.

A further idea follows.

Where the legal system is unavoidable, traditional contracting between the parties should be used to improve the operation of the legal system where possible.

So, for the purposes of the legal wrapper, the outcome of the code’s operation (as distinct from the intent expressed by the code in writing) is agreed to represent the intent of the parties unless a legal system intervenes unavoidably, whereupon, to the fullest extent available under the law:

• (Experts first) to settle a legal dispute, the parties agree to discuss properly and then, failing that, a final and binding expert determination using an expert in cryptographically secure transaction systems;
• (No blockchain remedies) where the parties end up in legal dispute, they agree that neither will seek a specific performance remedy that would force a party to do something within the crypto system;
• (No mistakes) the parties agree:
  • to conduct sufficient due diligence on the transaction to the extent that any unintentional outcome of the smart contract can be considered the result of their own negligence;
  • that they are sophisticated enough to make that statement; and
  • based on the above, agree not to sue for mistake / fraud;
• (limitation of liability) the parties limit liability to each other to the fullest extent available, with the exception of liabilities caused by smart contract code;
• (Compensation in fiat) the parties agree that to the extent that there are damages payable they will be payable in fiat and the parties agree which fiat that is; and
• (Governing jurisdiction) the parties should agree to the governing law and courts to hear any claim.

Here are some other ideas for topics to address in the legal wrapper for specific types of transaction.

• (Regulatory intervention) The parties should share the risk, as is appropriate, for regulatory intervention. Amounts payable under various indemnities should be determined by the legal layer.
• (Unwinding transaction) Where the smart contract leads to an unlawful / void legal outcome, the parties agree how to unwind / compensate for the legal failure of the smart code transaction.
• (Liquidated damages) The parties may agree how liquidated damages should be calculated for transaction-specific legal issues that arise.

The emergent dynamic

There’s a good technical analogy for the emergent dynamic we’re looking for here.

In an "optimistic user interface", the client side of an application assumes a user action on the client side is valid, so it shows the user action result to the user before a round trip to the server to check the user action validity with trusted code.

This dynamic creates a better user experience because the user interface is not blocked by the time taken for server validation.

The rationale for this approach is that the overwhelming majority of user actions will be valid and there are ways to reverse the outcome if they aren’t, so why wait for the server round trip?

We see the operation of blockchain and the legal system similarly.

In our view, the smart contract should “run ahead” unhindered but be followed up by the slow validation / problem solving processes of the legal system.

The law is still important

The views expressed above privilege smart contracts in many ways, but they are not a dismissal of the traditional legal system.

We should still use legal mechanisms to regulate non-blockchain entities. Like people, for instance. Over time we think smart code systems will regulate people with incentives rather than legal compulsion, but in the interim, there’s a role to play.

There are a few well publicised examples of DAOs voting for developers to do things and those developers not following the vote. It was a mistake to have the mechanism to begin with. Code doesn't regulate people - that's the domain of the traditional legal system.