Incomplete Contracts (and Scaling Crypto)

One way to think about various kinds of crypto projects is through the lens of contract theory. An axiom of this area of legal scholarship states: “all but the simplest contracts are incomplete”. That is, contractual arrangements cannot anticipate every possible outcome or set of actions, given complex and dynamic changes in the world the contract lives in.

When contracts are incomplete, they rely on renegotiation when unexpected contingencies like bankruptcy, regulation or even simple changes in details emerge. Such contingencies often require third parties like the legal system to help interpret and mediate between the two parties, and can lead to unpredictable outcomes. In this way, contracts are always about the unknown eventualities of decision making, incentives, and governance authority.

But if we accept that contracts are simply decision logic — akin to computer programs, then contract theory gives us a framework for thinking about different types of smart contracts and crypto-enabled projects — and how they can scale (including governance of them).

As a thought exercise, let’s divide crypto projects into categories: projects that aim to be “complete” and those that, due to their complexity, are “incomplete”. While admittedly reductive, the goal of this division is to highlight how each of these systems might achieve scale.

Let’s start by identifying projects that are (mostly) “complete”. These projects aim to specify a system end-to-end, minimizing the need for subjective interpretation, renegotiation, and external governance. In software terminology, the goal of these systems is to be “correct by construction”. Bitcoin’s proof-of-work mining is one such system. Bitcoin’s completeness is a function of its verifiable computation — deterministic hashing algorithms plus hard-coded game-theoretic incentives. Together, these consistently drive the system towards the outcome of producing a correct chain, while minimizing the need for human interpretation or external decision-making.

Ethereum meets this bar too, since the work done in its network is similarly deterministic. Applications built on Ethereum transitively inherit the “completeness” of the underlying platform, and can choose to extend completeness to create autonomous software applications. One example is Uniswap, a clever token exchange whose logic and incentives are entirely encoded in immutable smart contracts. Incentives for market makers to engage are hard coded into the contract, bootstrapping a liquidity network effect without ongoing central management.

In each of the above examples, completeness is correlated with automation. A system that is fully specified can be automated and run without intervention. Nick Szabo famously deemed these types of automated systems “socially scalable” because their coordination mechanisms offer guarantees that remain consistent or strengthen with the number of participants. Minimizing external human interpretation reduces coordination complexity, allowing the system to scale as additional participants join.

Projects that exist within the realm of “complete” contracts are necessarily constrained in design space. This is because scalability through automation is limited to work that can be verified by computers deterministically. This typically requires inputs to a decision that are numerical, quantifiable, or otherwise machine-readable.

What about “incomplete” projects? Their need for dynamic, human, subjective inputs to ongoing operations makes them difficult to computationally verify and automate.

One example is MakerDAO. Maker is largely “complete” in that much of its logic is deterministically executed on Ethereum, but it remains “incomplete” in a few critical areas. Namely, it requires dynamic parameterization to maintain the peg of the DAI stablecoin and the underlying collateral ratios. Today, the work of setting these parameters is too complex to automate, so instead the community votes on how the variables should be set. Similarly, MolochDAO, a guild for the furtherance of Ethereum infrastructure votes on decisions, like who to admit to the guild and which projects to fund. While settlement on the outcome of votes is handled by smart contracts, Moloch’s organizational structure is mostly “incomplete,” as it relies on the subjective interpretation of complicated, unquantifiable inputs such as reputation, social capital, and project feasibility. While these projects can adapt to change, they can’t scale through automation. And voting as a coordination mechanism risks becoming less effective with the number of participants. “Incomplete” projects therefore require different ways of achieving social scalability.

To recap —

If “incomplete” projects depend upon human decision making, how will they repeat the successes of Bitcoin and Ethereum and scale beyond early adopters? One answer is through delegating governance, while aligning decision-makers through ownership, as is done in cooperative enterprises. Historically, the most successful of cooperative organizations have, over time, converged on modes of decision making featuring hierarchy similar to that of corporations: Stakeholders appoint a management team to make day-to-day decisions that represent their ownership interests. This scales much better than each member voting on every decision. Other community-enabled efforts like Wikipedia have also developed a structured governance model based on community reputation (although this was not present at the outset.) While hierarchical systems are anathema to the decentralization culture permeating crypto, they may be the most viable path for more complex, “incomplete” projects that are being built on top.

Objections to “incomplete” systems are often raised on the ground that they don’t take full advantage of the deterministic or “trustless” capabilities of the underlying crypto computing platforms. I would argue that capabilities native to crypto still provide incomplete projects with powerful new tools.

• By virtue of distributing packets of value with the ease of information (through tokens) blockchain computers enable communities to create internet-native startups which default to stakeholder ownership and representation.
• Deterministic processes for organizational operation, such as appointing delegates with authority to make subjective decisions (liquid democracy), triggering bounties, transferring funds.
• A fluid ability to “exit” by forking code, and lower switching costs to substitutes.

I have a hunch that the most interesting projects built on top of blockchain computers will be “incomplete,” since interestingness often derives from adaptability, evolution, and surprise. The degree to which “incomplete” applications leverage the underlying software platform for execution of all business logic may ultimately prove to be less important than the degree to which these new internet-based organizations land on effective organizational scalability models. Software can’t single-handedly solve for the “completeness” of every contract, but it can help — and through token enabled ownership, it can help communities overcome the bootstrap problem to fostering innovation.