Jurisdiction, ‘Code-is-Law’, and Contract-Aligned-Programs
We should define modes of code-law interaction based on the degree to which each use-case requires a jurisdiction to function correctly, then establish principles for each mode.
DISCLAIMER: Jake Chase-Lubitz is an engineering member of LexDAO. He is not a lawyer and this is publication is not legal advice. The post is for informational purposes only.
Debating the viability of code-is-law is not the most useful activity of legal engineering. Instead, we should define modes of code-law interaction based on the degree to which each use-case requires a jurisdiction to function correctly, then establish principles for each mode. This approach will not only create value on it’s own, but it will also advance a ‘code-is-law’ agenda by decreasing the isolation of the pure code-governed organizations.
Jurisdictions are useful.
Attempting to treat smart contracts like legal agreements ignores the fact that the latter assume and require an associated system of interpretation and enforcement — a jurisdiction. All agreements exist in a context and will therefore require interpretation and enforcement. A functioning socio-economic system must interpret agreements based on precedent and an agreed-upon set of rules. Jurisdictions create a flexible and predictable operating environment by placing rules and agreements in the context of expectation and intent, harmonizing them.
Smart contracts are really just software programs with the ability to enforce a narrow set of rules. While this makes them contract-like, they cannot be contracts in a legal sense without being integrated into a jurisdiction. That integration is a (fiat) legal exercise.
Ownership of real things requires jurisdiction.
The common wisdom is that code cannot have jurisdiction because, among other reasons, it cannot enforce rules in physical space. The truth is actually the reverse: code-enforced rulesets cannot enforce ownership of objects in physical space because they lack jurisdiction.
Physical enforcement capacities result from popular acceptance of a system (whether through agreement, tradition, or fear). The integration of rules and agreements with expectation and intent — a core component of jurisdiction — is fundamental to the creation of such a system. The code-is-law approach does not have this integrative property.
Nation-states have a monopoly on jurisdiction.
Two important realities prevent the creation of a truly independent, broadly applicable jurisdiction through code:
Jurisdiction requires the ability to arbitrate and enforce agreements to the exclusion of some other entity. States maintain this exclusion and back up their ability to do so with a monopoly on the use of force.
Traditional courts will typically take a position on an agreement in the case of a dispute, whether or not that agreement was intended to constitute a legal document.
This behavior is a feature, not a bug. A legal system that acts as the final arbiter of interactions between people creates a predictable, approximately-fair environment, which is necessary for anyone to take the kinds of risks that lead to growth and innovation.
Note: one approach to limiting nation-states’ jurisdiction is for all participants in a digital system to adhere to strict anonymity, thereby preventing a traditional government from having enforcement power. This approach makes it almost impossible to engage with the traditional economy (which most people simply refer to as “the economy.”)
Establishing different codes for different modes
People build things on blockchain for different uses-cases. A use-case’s relationship to jurisdiction determines the proper relationship between code and law.
Mode 1: `code is… code`
A `code-is-law` approach is appropriate when the “organization’s” only purpose is to maintain a shared record. Interpretation is irrelevant to this function and therefore so is jurisdiction. Bitcoin illustrates this concept. It offers an inherently trustable record of value transactions, freeing users from the need for a jurisdiction to ensure that the record keeper is honest.
This category of use-case remains narrow, even though the interactions it facilitates can be quite varied. Turing-complete protocols such as Ethereum allow users to program rules governing interactions, but the protocol’s contribution to the meaningfulness of those interactions is exclusively that they will be published to an inherently-trustable record. It has nothing to say about any other part of the interaction, namely expectations or intent of the parties involved.
Code-is-law thinking therefore best applies to cases where one or more of the following is true:
When code-enforced rules governing how information will be recorded are the value proposition, such as blockchain protocols, decentralized exchanges, and automated market makers.
When there is little distinction between the basic the product’s law-like (rule-enforcing) behavior and what we would otherwise call “features.”
Mode 2: contract-aligned-programs
It becomes impossible to treat code as law as soon as expectation and intent become meaningful to the interaction. The Ethereum ledger can confirm the fact that I have sent my designer $500. It is dead silent on whether the design I received is satisfactory because it is unable to consider the degree to which the design accomplishes its purpose, the expectations of either party, or the relative validity of those expectations.
This dynamic extends to most business interactions. A common example is a determination of whether an action was intentional or accidental. We must determine intent, which itself is impossible to measure quantitatively. Whether intentionality is even relevant to remedy in the first place again requires a comparison of expectations and analysis of their validity.
For such interactions, code is best understood as a user experience layer on top of traditional agreements: as contract-aligned-programs. The focus should be on creating user experiences that extend otherwise traditional contracts, intended to be enforced by fiat systems. Such an approach best applies when one or more of the following is true:
When the activity involves frequent interaction between a record and a claim on an off-chain asset, such as a share of a business that frequently changes hands.
When the formation or execution of a legal agreement is highly repetitive, such as contracting scope-based project work, offering loan agreements, and confirming identity
When an activity exhibiting the first two traits also involves controlling physical assets. In this case we’d need an “anchor.”
When the parties involved explicitly choose to express their legal agreement using code. This should be treated like a foreign language contract and include a certified local-language translation.
Procedures vs. Contracts: a new(ish) agreement paradigm medium.com
Mode 3: Jurisdiction-like operational space (JLOS)
We can combine Modes 1 and 2 to create operational environments that mimic jurisdictions by creating mechanisms that allow forcible control of on-chain assets via community intervention. For example, consider a mechanism by which a distributed human jury can reverse certain kinds of transactions. Parties to an agreement can agree to utilize an on-chain Alternative Dispute Resolution mechanism (our anchor concept from Mode 2), and the code, included in the parties’ smart contracts from the outset, could provide the human jury with the ability to enforce their decision by adjusting the distributed record (our “it’s just a record” concept from Mode 1)
We could even extend this functionality by wrapping on-chain businesses in code that allows a the community to transfer control of those businesses in the event of loan default or activity that breaks the community’s rules.
It’s important to recognize, however, that it will always be possible to extract value from these digitally-governed spaces without fiat jurisdiction integration (an anchor) because participation in them is voluntary. Imposing jurisdiction requires power over physical spaces (in which our participation is involuntary).
Suppose a group of five game developers agree to create a smart contract that will automatically divide and distribute the game’s revenue. One of these developers copies the code and publishes the game on an off-chain marketplace, keeping all the revenue for him or herself. In this situation, only the entity that can provide the other four developers with recourse is one that can impose itself on all parties. Only a fiat-law agreement to adhere to the outcome of the dispute resolution mechanism (the jurisdiction integration) can fully protect all parties.
Advancing the ‘Code-is-Law` agenda
There is a path to true jurisdiction for digital communities. Imagine that we build Mode 3 jurisdiction-like operational spaces (“JLOSs”) so effective and comprehensive that the majority of participants in some domain simply choose it as their preferred operating environment. The JLOS would enjoy a monopoly on opportunity, much like the traditional, state-mediated economy does today. Under these circumstances, a sufficient portion of the population would have an interest in physical-world enforcement of JLOS rules that it could create pressure on nation-states to integrate with the JLOS as opposed to the other way around.
This suggests that integration with, rather than isolation from, state governments, is the more promising path to a `code-is-law` reality.
In rule-of-law countries, this integration would likely follow the familiar legislative process, with lawmakers responding to the demands of their constituencies. Under highly corrupt or authoritarian regimes, this might look like existing power-holders either fading out, or more likely, finding ways of integrating themselves into the new paradigm.
This last point hints at the obvious challenge facing the integration approach: people and institutions with power usually fight to protect that power. The gun lobby in the United States and the notary lobby in Germany (perhaps especially relevant to this discussion) are great examples of governments maintaining unpopular, counter-productive policies in the interest of established powers.
It’s worth noting, however, that any approach to systemic change inherently presents this problem. Political strategy is not the subject of this post, but a cryptopunk rebellion, entirely irrelevant to the day-to-day needs of most people, seems less promising to me than attempting to gradually shift the location of economic activity. Whether that results in the new system exhibiting all the same problems as the old one is another matter.
As legal engineers, our best chance of advancing our vision of a world that relies less on governments is creating the deepest, simplest, most extendable integrations with those governments rather than writing code that attempts to insulate digital communities from government jurisdiction. We do that by determining the best mode for each use-case and optimizing for usefulness, not independence from the legal system. We must create a better operating environment than the current system offers.