Early blockchains’ project and protocol governance was (and continues to be) done off-chain, through systems like Bitcoin’s BIP Proposals or Monero’s Forum Funding System, where proposed protocol changes get discussed and development funded. Forks, hard and soft, were the primary vehicle for implementing protocol changes, considered by industry observers as key governance mechanisms, giving token holders voice and exit options.
So-called ‘token-based voting models’—a category that simplifies what is in practice a diverse set of mechanisms—were developed in reaction to these processes’ perceived shortcomings: questions concerning transparency in decision making, independence of funding for development initiatives, and adequate representation of key user groups were key points of contention in early discussions. For example, Decred’s founder, Jake Yocom-Piatt, argued that decisions to alter the Bitcoin protocol are made entirely off-chain, typically by insiders/early adopters and heads of large mining operations. DASH’s ‘DGGB’ process—Decentralized Governance by Blockchain—was designed to be more independent and self-sustaining compared to projects relying on non-profit foundations for governance, relying on a project treasury funded through a portion of the currency’s block rewards, rather than grants, donations, or corporate sponsors as sources of income for project development.
Management of key protocol decisions became increasingly viewed as an attack vector on an otherwise immutable ruleset, a ruleset capable (with good crypto-economic design) of independently incentivizing entrepreneurs to add value to a protocol in the form of an ecosystem of services. Viewed through this lens, the value of a token-based governance system lays in its propensity to resist protocol changes that advantage one stakeholder group at the expense of another.
Criticism of Token Based Voting
Intriguingly, it is through this lens that projects practicing token-based governance—such as EOS, Decred, MakerDAO, and DASH—are themselves receiving thoughtful criticisms of their token-based approaches, criticisms that echo those they levied against the of practice over the past several years. Notable examples include:
- Melonport, an open-source protocol for distributed digital asset management on the Ethereum blockchain, considered and rejected a token-voting based approach to protocol governance, arguing that, for its particular use case and circumstances, token-based voting would not adequately deliver decentralization for users. Melonport instead chose a ‘skill based’ approach and appointed a technical council, The Melon Council DAO, which will utilize the AragonOS.
- DAOstack, a governance framework and DAO management system, released details on its approach to ‘reputation-based’ voting, arguing that the use of reputation corrects for issues with pure token-based approaches, such as vote buying, decision speed, and incentive misalignment. DAOstacks’ Alchemy interface is a hybrid of reputation and token-based voting.
Ethfinex, a hybrid decentralized token exchange, is piloting a DAO using Alchemy. Ethfinex additionally paused token-based voting on listing curation, citing issues with both low voter and project participation. Other notable projects integrating or experimenting with Alchemy include Gnosis’ DutchX trading protocol and the Kyber Network.
The following list summarizes many of the standard criticisms leveraged against token-based voting over the past several years, explaining why an issue matters. The list additionally contrasts token based and reputation/skill based approaches, helping to explain where a difference in ideology leads a seeming feature to be viewed as a flaw or vice versa.
Conducting a vote with enough participation to be legitimate (in the sense of being representative of the relevant community) tends to take substantial time and energy.
Governance decisions made by those with insufficient domain knowledge can lead to suboptimal results, at lease on certain topics. Voters recusing from decision-making on the basis of insufficient expertise can contribute to low turnout. For example, MakerDAO MKR token holders frequently vote to alter the CDP stability fee in response to market conditions, a process which may require considerable knowledge of finance to effectively govern.
Token holders’ interests may not align with users’, the platform’s, or even each other’s. Token holders can use token-based voting to undermine competitors or for short-term investment purposes. A target user group may not risk adopting a platform whose leading actors can easily use token-based voting to change rules to their advantage.
Through vote buying, anyone can use a token-based governance system to undermine competitors or for short-term investment purposes.
The initial distributions of tokens can aim to have tokens end up distributed to long-term partners or founders; long term re-distribution mechanisms can likewise be designed with such aims.
Token-based voting alone does not guarantee that token holdings will not concentrate. Though voting represents a form of ‘decentralized’ decision making, projects decentralized this way are arguably decentralized in the wrong way for a target use cases, in that token-based voting is compossible with a highly mutable ruleset advantaging incumbents.
Tokens as a sole means of representation in decision making is a single source of failure and can compound the ill effects of fraud for victims.
As demonstrated by a growing literature, the limitations of token-based voting are becoming clearer, with projects evidencing a better understanding of suitable use cases and more clearly and comprehensively articulating pain points. Questioning whether token-based voting is suitable for a project given its use case and circumstances, represents a more practical and less ideological turn in thinking about distributed governance.
While Melonport and DAOstack’s particular criticisms are not unprecedented, the launch of Melonport’s DAO and project’s trialing of Alchemy’s adoption are indicative of the industry’s willingness to experiment with novel modes of governance. DAOstack’s Alchemy toolset, which allows organizations to reward or revoke non-transferable reputation to individuals (i.e. Ethereum addresses) on various configurable bases, resembles previously seen approaches the least. In the model, token holdings are still used to bring issues to vote (so, tokenholders as a stakeholder group retains a degree of influence) yet reputation, not tokens, is used to decide issues, potentially conferring a different set of stakeholders greater power in decision making.
In fact, given that changes to a governance model are often in the very scope of token-based governance decisions, reputation systems in some fashion may very well be integrated by projects with current token-based models and in a manner wholy aligning with project’s principles.
On the other hand, it is premature to say definitively whether the alternative arrangements proposed by DAOstack or Melonport will achieve their stated goals. The same flexibility in setting conditions for ‘flow’ of reputations invites a need for clearer design guidelines, rules of thumb, and general practical knowledge in designing a reputation system that reinforces a project’s governance goals. Actual user behavior may not conform to expectations. In general, there are (arguably) desirable conditions for reputation gains and losses that may prove impossible to trustlessly operationalize: user intent, relevant for incentivizing or disincentivizing behaviors in a more fine-grained fashion, is typically not fully discernible through measurable outcomes alone.
The criticisms of token-based voting offered by Melonport and DAOstack are unsurprising in respects—a one-token-one-vote approach is relatively simplistic and is unlikely to work for all governance decisions for all projects. While criticisms of token-based voting have merit, their abstraction from actual mechanisms employed by ‘token-based voting’ projects at time risks strawmanning and can obscure an important point of agreement: that governance is key to keeping networks decentralized in the right respects, so, despite its challenges, is worth the effort in considering how, in a project’s unique circumstances, governance can be implemented to achieve this end. It is time we acknowledge the place for and limits of a simple token-based voting approach, and turn to the next set of problems that a more complex arrangement introduces.