Governance Beyond Token Voting
Author: Vitalik Buterin
Original Title: 《Moving beyond coin voting governance》
Published on: August 16, 2021
Over the past year, an important trend in the blockchain space has been the transition from a focus on decentralized finance (DeFi) to simultaneously considering decentralized governance (DeGov). While 2020 was often widely and justifiably hailed as the year of DeFi, in the following year, the complexity and capabilities of DeFi projects that constitute this trend have increased, leading to growing interest in decentralized governance as a means of managing this complexity. There are some examples within Ethereum. Projects like YFI, Compound, Synthetix, UNI, Gitcoin, and others have launched and even begun to use some form of DAO. The same is true outside of Ethereum, with discussions around infrastructure funding proposals in Bitcoin Cash, voting on infrastructure funding in Zcash, and more.
The rise in the prevalence of some form of formal decentralized governance is undeniable, and there are important reasons for this interest. But it is equally important to keep in mind the risks of such plans, as evidenced by the recent hostile takeover of Steem and the subsequent mass migration to Hive. I further argue that these trends are inevitable. In some cases, decentralized governance is both necessary and dangerous, a point I will elaborate on in this article. How can we minimize risks while reaping the benefits of decentralized governance? I will argue that a key part of the answer is that we need to move beyond existing forms of token voting.
DeGov is Necessary
Since the 1996 "Declaration of the Independence of Cyberspace," there has been a key unresolved contradiction in what can be termed the ideology of cyberpunk. On one hand, the values of cyberpunk are all about using cryptography to reduce coercion and maximize the efficiency and scope of the then-mainly non-coercive coordination mechanisms: private property and markets. On the other hand, the economic logic of private property and markets is optimized for activities that can be "disaggregated" into repeated one-on-one interactions, while the information sphere, where art, documents, science, and code are produced and consumed through irreducible one-to-many interactions, is completely contrary to this.
In such an environment, there are two inherent key problems that need to be solved.
Funding public goods: How to fund projects that are valuable to a broad, non-choosing population within the community, but which often lack a business model (e.g., research on layer one and layer two protocols, client development, documentation…)?
Protocol maintenance and upgrades: How are protocols upgraded, and how are regular maintenance and adjustment operations for long-term unstable parts of the protocol (e.g., security asset lists, price oracle sources, multi-party computation key holders) agreed upon?
Early blockchain projects largely ignored these two challenges, pretending that the only important public good was network security, which could be achieved through a permanently fixed single algorithm and paid for with fixed proof-of-work rewards. This funding situation was initially possible because of the significant rise in Bitcoin prices from 2010 to 2013, followed by the ICO boom from 2014 to 2017, along with the second crypto bubble that occurred simultaneously, all of which made the ecosystem rich enough to temporarily mask huge market inefficiencies. The long-term governance of public resources was similarly neglected: Bitcoin took an extreme minimalist path, focusing solely on providing a fixed supply of currency and ensuring support for second-layer payment systems like the Lightning Network. Ethereum, due to the strong legitimacy of its pre-existing roadmap (essentially: "proof of stake and sharding"), continued to develop harmoniously (with one major exception), while projects requiring more complex application layers did not yet exist.
However, now, this luck is running out, and coordinating protocol maintenance and upgrades while avoiding centralization risks, as well as funding documentation, research, and development, has become a top priority.
DeGov Needs to Fund Public Goods
It is necessary to step back and look at the currently absurd situation. The daily mining issuance rewards from Ethereum are about 13,500 ETH, or about 40 million dollars per day. Transaction fees are similarly high; the portion not burned by EIP-1559 is still about 1,500 ETH per day (around 4.5 million dollars). Thus, billions of dollars are spent annually on funding network security. Now, what is the budget of the Ethereum Foundation? About 30-60 million dollars per year. There are non-EF participants (like Consensys) contributing to development, but their scale is not large. The situation is similar for Bitcoin, where funding for non-security public goods may be even less.
Here’s the situation in the chart:
In the Ethereum ecosystem, this discrepancy can be argued to be inconsequential; tens of millions of dollars "is enough" for the necessary R&D, and adding more funding does not necessarily improve the situation. Therefore, establishing developer funding within the protocol poses a risk to the platform's credible neutrality that outweighs the benefits. But in many smaller ecosystems, including those within Ethereum and completely independent blockchains like BCH and Zcash, the same debate is brewing, and the imbalances at these smaller scales can lead to significant differences.
Enter DAOs. A project that launched as a "pure" DAO from day one can achieve a combination of two properties that were previously impossible to combine: (i) the sufficiency of developer funding, and (ii) the credible neutrality of that funding (the long-sought "fair launch"). Developer funding does not come from a hard-coded list of receiving addresses but can be decided by the DAO itself.
Of course, making a launch completely fair is difficult; the unfairness brought about by information asymmetry is often worse than the unfairness brought about by explicit preconditions (consider that by the end of 2010, a quarter of the supply had already been distributed, and very few had the opportunity to hear about it—was Bitcoin really a fair launch?). But even so, compensating for non-security public goods within the protocol from day one seems to be a potentially significant step toward achieving sufficient and more credible neutral developer funding.
DeGov Needs Protocol Maintenance and Upgrades
In addition to public goods funding, another equally important governance issue is protocol maintenance and upgrades. While I advocate minimizing all non-automated parameter adjustments (see the "limited governance" section below) and I am a fan of RAI's "non-governance" strategy, sometimes governance is unavoidable. Price oracle inputs must come from somewhere, and sometimes that somewhere needs to change. Improvements must be coordinated in some way before the protocol "solidifies" into its final form. Sometimes, the community of a protocol may believe they are ready to solidify, but then the world throws a curveball that requires a complete and contentious restructuring. What if the dollar collapses, and RAI has to scramble to create and maintain its own decentralized CPI index to keep its stablecoin stable and relevant? Here, DeGov is also necessary, so completely avoiding it is not a viable solution.
An important distinction is whether off-chain governance is feasible. For a long time, I have been a fan of supporting off-chain governance as much as possible. In fact, for underlying blockchains, off-chain governance is absolutely feasible. However, for application layer projects, especially DeFi projects, we encounter the problem that application layer smart contract systems often directly control external assets, and this control cannot be forked. If Tezos's on-chain governance is captured by an attacker, the community can hard fork without incurring any loss (the acknowledged high coordination costs). If MakerDAO's on-chain governance is captured by an attacker, the community can certainly launch a new MakerDAO, but they will lose all ETH and other assets held in existing MakerDAO CDPs. Therefore, while off-chain governance is a great solution for the base layer and some application layer projects, many application layer projects, especially DeFi, inevitably require some form of formal on-chain governance.
DeGov is Dangerous
However, all current instances of decentralized governance come with significant risks. For followers of my writing, this discussion is not new; the risks are broadly similar to those I have discussed here, here, and here. The issues I am concerned about with token voting primarily fall into two categories: (i) inequality and misaligned incentives even in the absence of attackers, and (ii) outright attacks conducted through various forms (often opaque) of vote buying. For the former, there are already many proposed mitigations (such as delegation), and there will be more. But the latter is the more dangerous elephant in the room, and I believe there is no solution within the current paradigm of token voting.
Token Voting Issues Even Without Attackers
Even in the absence of explicit attackers, the issues with token voting are becoming increasingly easy to understand (e.g., see a recent article by DappRadar and Monday Capital), and they primarily fall into several categories:
A small group of wealthy participants ("whales") is better able to successfully execute decisions than a large group of small shareholders. This is due to the tragedy of the commons among small shareholders: each small shareholder has only a negligible impact on the outcome, so they have no incentive to genuinely vote and instead tend to slack off. Even if there are rewards for voting, there is little motivation to research and carefully consider what they are voting on.
Token voting governance empowers token holders and the interests of token holders at the expense of other parts of the community: the protocol community is composed of different voters with many different values, visions, and goals. However, token voting only gives power to one constituency (token holders, especially wealthy ones) and leads to an overemphasis on goals that drive up the token price, even if this involves harmful rent-seeking.
Conflict of interest issues: Giving voting power to one constituency (the holders), especially overly empowering the wealthy within that constituency, risks excessive exposure to the conflicts of interest of that particular elite class (e.g., holders of investment funds or tokens of other DeFi platforms that interact with the platform simultaneously).
To address the first issue (and thus mitigate the third issue), one main strategy is being attempted: delegation. Small shareholders do not have to personally judge every decision; instead, they can delegate to community members they trust. This is a noble and worthwhile experiment; we will see how well delegation can alleviate the problem.
My Voting Delegation Page in Gitcoin DAO
On the other hand, the issue of token holder centrism is clearly more challenging: token holder centrism is inherent in a system where token holder voting is the only input. The misunderstanding that token holder centrism is an expected goal rather than a flaw has caused confusion and harm; a (very excellent) article discussing blockchain public goods complained:
If ownership is concentrated in the hands of a few whales, can crypto protocols be considered public goods? Colloquially, these market primitives are sometimes described as "public infrastructure," but if blockchains serve the "public" today, it is primarily a form of decentralized finance. Fundamentally, these token holders have only one common concern: price.
This complaint is misguided; blockchains serve a richer and broader public than just DeFi token holders. However, our token voting-driven governance system completely fails to capture this, and it seems difficult to establish a governance system that can capture this richness without a more fundamental change to the paradigm.
The Deep-Rooted Vulnerability of Token Voting to Attackers: Vote Buying
Once attackers attempting to subvert the system enter the picture, the problems become worse. The fundamental vulnerability of token voting is easy to understand. Tokens in protocols with token voting are a bundle of two rights combined into a single asset: (i) some economic interest in the protocol's revenue and (ii) the right to participate in governance. This combination is intentional: the goal is to align power and responsibility. But in practice, these two rights can easily be separated. Imagine a simple wrapping contract with these rules: if you deposit 1 XYZ into the contract, you receive 1 WXYZ. WXYZ can be converted back to XYZ at any time, and it can also accumulate dividends. Where do the dividends come from? Well, while the XYZ tokens are in the wrapping contract, the wrapping contract can use them in governance at will (proposing, voting on proposals, etc.). The wrapping contract simply auctions off this right daily and distributes the profits to the original depositors.
As an XYZ holder, is it in your interest to deposit your tokens into the contract? If you are a very large holder, it may not be; you like the dividends, but you fear what a misaligned actor might do with the governance power you sold. But if you are a smaller holder, then it fits perfectly. If the governance rights auctioned off by the wrapping contract are bought by an attacker, you personally will only suffer a small portion of the costs of the bad governance decisions caused by your tokens, but you will personally receive the full benefits of the dividends from the governance rights auction. This situation is a classic tragedy of the commons.
Suppose the decisions made by the attacker harm the DAO, thereby benefiting the attacker. What is the harm caused by the decision's success to each participant? What is the likelihood of a single vote skewing the outcome? Suppose the attacker is bribed? The game theory looks like this:
- The decision benefits you and others
- Accept the bribe from the attacker
- Reject the bribe and vote your conscience
If you are inclined to accept the bribe, but as long as accepting the bribe is harmful to the collective. Therefore, if (often far below), the attacker has the opportunity to bribe users into making net negative decisions, the compensation for each user is far below the harm they suffer.
A natural criticism of the fear of bribing voters is: would voters really be so unethical as to accept such an obvious bribe? Ordinary DAO token holders are enthusiasts who find it hard to be satisfied with such selfish and blatant acts of selling out the project. But this overlooks the fact that there are more obfuscating ways to separate profit-sharing rights from governance rights that do not require something as explicit as a wrapping contract.
The simplest example is borrowing from DeFi lending platforms (e.g., Compound). Those who already hold ETH can lock their ETH in a CDP (Collateralized Debt Position) on one of these platforms, and once they do so, the CDP contract allows them to borrow a certain amount of XYZ, for example, half the value of their deposited ETH. They can then do anything they want with this XYZ. To reclaim their ETH, they ultimately need to repay the XYZ they borrowed plus interest.
Note that throughout the process, the borrower has no financial risk regarding XYZ. That is, if they use their XYZ to vote in favor of governance decisions that undermine the value of XYZ, they do not lose a dime because of it. The XYZ they hold is XYZ, and they ultimately must repay it to the CDP, so they do not care whether its value goes up or down. Thus, we achieve a disaggregation: the borrower has governance rights without economic interest, while the lender has economic interest without governance rights. Some DAO protocols are using techniques like time locks to limit people's ability to participate in such attacks, but ultimately time locks can be circumvented; in terms of security systems, time locks are more like paywalls on newspaper websites than locks and keys.
There are also centralized mechanisms that separate profit-sharing rights from governance rights. Most notably, when users deposit their tokens into a (centralized) exchange, the exchange holds full custody of those tokens and has the ability to vote with those tokens. This is not purely theoretical; there is evidence that exchanges use their users' tokens in several DPoS systems. The most recent and obvious example is the hostile takeover attempt of Steem, where exchanges used their customers' tokens to vote in favor of proposals that helped consolidate the acquisition of the Steem network, while the majority of the community strongly opposed it. This situation was only resolved through a massive exodus, with most of the community moving to another chain called Hive.
Currently, many blockchains and DAOs that adopt token voting have managed to avoid these most severe forms of attack. There are occasional signs of attempted bribery.
However, despite all these significant issues, simple economic reasoning suggests that direct bribery of voters is much rarer, including through vague forms like utilizing financial markets. The question to ask is: why have there not been more direct attacks?
My answer to "why not yet" relies on three contingent factors that are true today but may become less true over time.
Community spirit comes from having a tightly-knit community where everyone feels camaraderie in a shared tribe and mission.
The wealth of token holders is highly concentrated and coordinated; large holders have a greater ability to influence outcomes and invest in long-term relationships with each other (both as venture capital's "old boys' club" and many other equally powerful but low-profile groups of wealthy token holders), making them harder to bribe.
The financial markets for governance tokens are immature: ready-made tools for creating wrapped tokens exist in proof-of-concept form but are not widely used, and bribery contracts also exist but are similarly immature, with low liquidity in lending markets.
When a small, coordinated group of users holds over 50% of the tokens, and they and other users are invested in a tight-knit community, and very few tokens are lent out at reasonable rates, all the aforementioned bribery attacks may still be theoretical. However, over time, regardless of what we do, (1) and (3) will inevitably become less true, and if we want DAOs to become fairer, (2) must become less true. When these changes occur, can DAOs remain safe? If token voting cannot consistently withstand attacks, then what can?
Solution 1: Limited Governance
One possible mitigation for the above issues, which has already been attempted to varying degrees, is to limit what token-driven governance can do. There are several ways to achieve this.
Use on-chain governance only for applications, not for the base layer: Ethereum has already done this, as the protocol itself is governed through off-chain governance, while DAOs and other applications above it are sometimes (but not always) governed through on-chain governance—chain governance.
Limit governance to fixed parameter choices: Uniswap does this, as it only allows governance to affect (i) token distribution and (ii) a 0.05% fee for the Uniswap exchange. Another good example is RAI's "non-governance" roadmap, where governance has control over fewer and fewer functions over time.
Increase time delays: Governance decisions made at time T only take effect at, for example, T+90 days. This allows users and applications who find the decision unacceptable to migrate to another application (possibly a fork) before the decision takes effect. Compound has a time delay mechanism in its governance, but in principle, the delay could (and should) be longer.
Be more fork-friendly: Make it easier for users to quickly coordinate and execute forks. This reduces the rewards for capturing governance.
The Uniswap case is particularly interesting: it is expected behavior that on-chain governance funds teams that may develop future versions of the Uniswap protocol, but it is up to users to choose to upgrade to those versions. This is a hybrid of on-chain and off-chain governance, leaving limited roles for the on-chain side.
But limited governance itself is not an acceptable solution. The areas most in need of governance (e.g., funding allocation for public goods) are also the areas most susceptible to attack. Public goods funds are easily attacked because attackers have a very direct way to profit from bad decisions: they can attempt to push through a bad decision that sends funds to themselves. Therefore, we also need technology to improve governance itself…
Solution 2: Non-Token-Driven Governance
The second approach is to use forms of governance that are not driven by token voting. But if tokens do not determine an account's weight in governance, then what does? There are two natural choices:
Proof of personhood systems: Systems that verify that an account corresponds to a unique individual so that governance can allocate one vote per person. See comments on some technologies being developed here, as well as two attempts to implement this with Proof Of Humanity and BrightID.
Proof of participation: Systems that verify that certain accounts correspond to individuals who have participated in certain activities, undergone certain educational training, or performed certain useful work within the ecosystem. See POAP for how this can be implemented.
There are also possibilities for hybrids: one example is quadratic voting, which makes the power of a single voter proportional to the square root of the economic resources they commit. By distributing their resources across multiple identities, it prevents people from gaming the system, while the remaining financial component allows participants to credibly indicate their level of concern about an issue and their care for the ecosystem. Gitcoin quadratic funding is a form of quadratic voting and is building a quadratic voting DAO.
Proof of participation is less well-known. The key challenge is that determining the level of participation itself requires a very strong governance structure. The simplest solution may be to guide the system through a carefully selected group of 10-100 early contributors, and then as the N-th round of selected participants determines the criteria for participation in the N+1 round, gradually decentralizing over time. The possibility of forking helps provide a pathway to recover from governance derailment and provides an incentive.
Both proof of personhood and proof of participation require some form of anti-collusion (see this article explaining the issue and this MACI documentation) to ensure that non-monetary resources used to measure voting rights remain non-financial and do not ultimately sell governance rights to the highest bidder in smart contracts.
Solution 3: Asymmetric Traps
The third approach is to break the tragedy of the commons by changing the rules of voting itself. Token voting fails because while voters bear collective responsibility for their decisions (if everyone votes in favor of a bad decision, then everyone's tokens will drop to zero), each voter does not bear individual responsibility (if a bad decision occurs, those who supported it do not suffer more than those who opposed it). Can we create a voting system that makes voters individually, rather than just collectively, responsible for their decisions?
If forks are done in a way similar to how Hive forked from Steem, fork-friendliness can be seen as a game strategy. If a destructive governance decision succeeds and there is no longer opposition within the protocol, users can decide to fork on their own. Moreover, in that fork, tokens that voted in support of the wrong decision can be destroyed.
This may sound harsh and might even feel like a violation of an implicit norm that the "immutability of the ledger" should remain sacred and inviolable when forking tokens. But from one perspective, this idea seems more reasonable.
We maintain the idea of a strong firewall, where individual token balances are expected not to be infringed, but only apply this protection to tokens that do not participate in governance. If you participate in governance, even indirectly by putting your tokens into a wrapping mechanism, then you may be held accountable for the costs of your actions.
This creates individual responsibility: if an attack occurs, and your tokens vote in support of that attack, then your tokens will be destroyed. If your tokens did not vote in support of the attack, then your tokens are safe. Responsibility propagates upward: if you put tokens into a wrapping contract, and the wrapping contract votes in support of the attack, the balance of the wrapping contract will be cleared, and you will lose your tokens. If an attacker borrows XYZ from a DeFi lending platform, when the platform forks, anyone who lent out XYZ will fail (note that this makes lending governance tokens generally very risky; this is the expected outcome).
Asymmetric Risks in Everyday Voting
But the above only applies to preventing truly extreme decisions. What about small-scale heists? The economics of unfairly benefiting attackers manipulating governance, but not severe enough to cause catastrophic damage? Then, what about the simple laziness and the fact that token voting governance lacks the pressure of choice to support higher-quality opinions, even in the absence of any attackers?
The most popular solution to such issues is futarchy, introduced by Robin Hanson in the early 2000s. Voting becomes betting: if you vote in favor of a proposal, you are betting that the proposal will lead to good outcomes, and if you vote against the proposal, you are betting that the proposal will lead to bad outcomes. The reason futarchy introduces individual responsibility is clear: if you bet well, you will gain more tokens, and if you bet poorly, you will lose your tokens.
It turns out that "pure" futarchy is difficult to introduce because, in practice, the objective function is hard to define (people want more than just token prices!), but various hybrid forms of futarchy may be effective. Examples of hybrid futarchy include:
Voting as a purchase order: see the ethresear.ch post. Voting in favor of a proposal requires creating an executable purchase order to buy additional tokens at a price slightly below the current token price. This ensures that if a bad decision succeeds, those who supported it may be forced to buy out their opponents, but it also ensures that in more "normal" decisions, token holders can make more decisions based on non-price criteria if they wish.
Retrospective funding for public goods: see the post by the Optimism team. Public goods are funded retrospectively by some voting mechanism after they have achieved results. Users can purchase project tokens to fund their projects while signaling their confidence in them; if the project is deemed to have achieved its intended goals, the purchasers of the project tokens will receive a reward.
Upgrade games: see Augur and Kleros. The value consistency of lower-level decisions is incentivized by the possibility of attracting higher-effort but more accurate higher-level processes; voters who agree with the final decision will receive rewards.
In the latter two cases, hybrid futarchy relies on some form of non-futarchy governance to measure the objective function or serve as a final layer of dispute resolution. However, this non-futarchy governance has several advantages that are not present when used directly: (i) it activates later, so it can access more information, (ii) it is used less frequently, so it can expend less effort, and (iii) each use has greater consequences, making it easier to accept adjustments to the incentives of the final layer solely based on forks.
Hybrid Solutions
There are also some solutions that combine elements of the above techniques. Some possible examples:
Time delays combined with elected expert governance: This is a possible solution to the age-old problem of how to create a crypto-collateralized stablecoin whose locked funds can exceed the value of profit-generating tokens without the risk of governance capture. The stablecoin uses the median price of values submitted by n (e.g., n = 13) selected providers as an oracle. Token voting selects the providers, but it can only cycle through one provider per week. If users notice that token voting has led to untrustworthy price providers, they have N/2 weeks to switch to another stablecoin before the stablecoin breaks.
Futarchy + anti-collusion = reputation: Users vote with "reputation," a non-transferable token. If their decisions lead to the expected outcomes, users gain more reputation, and if their decisions lead to undesirable outcomes, they lose reputation. See here for an article advocating reputation-based schemes.
Loosely coupled (consultative) token voting: Token voting does not directly implement proposed changes but merely serves to publicly establish its results, building legitimacy for off-chain governance to implement that change.
This can provide the benefits of token voting while reducing risks, as the legitimacy of token voting will automatically decline if there is evidence that it has been bribed or otherwise manipulated.
But these are just a few possible examples. There is much work to be done in researching and developing non-token-driven governance algorithms. The most important thing to do today is to rid ourselves of the idea that token voting is the only legitimate form of decentralized governance. Token voting is attractive because it feels neutral: anyone can get some governance token units on Uniswap. However, in practice, token voting may only seem safe today because its neutrality is flawed (i.e., most of the supply is held by a small group of tightly coordinated insiders).
We should be wary of the idea that the current form of token voting is the "safe default." There is much yet to be observed about how they operate under greater economic pressures and in mature ecosystems and financial markets, and now is the time to begin experimenting with alternatives simultaneously.
