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 —
- Are "trust-minimized" (have little need for human intervention)
- Are difficult to change
- Are resistant to meddling
- Achieve scalability through verifiable, deterministic processes
Examples: Bitcoin, Ethereum, Uniswap. automated arbitrage smart contracts
- Do not specify what is to be done in every possible eventuality
- Are open to ongoing interpretation
- Require human input (governance)
- Require alternative solutions for scalability
“Incomplete” projects: governance and scale
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.
Will this work?
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.
This post was originally published on a16z.com
The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the enduring accuracy of the information or its appropriateness for a given situation.
This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments for which the issuer has not provided permission for a16z to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://a16z.com/investments/
Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures for additional important information.