Distributed Governance: Beyond Token-based Voting

Distributed protocols can remove centralized actors’ ability to manipulate features of the network in their favor, enabling a ‘level playing field’ for projects building on the network. This outlook expresses a core thesis on a decentralized system’s value, a thesis that some projects have strived to make true through design of distributed governance systems. Recently, the prevailing model for on-chain governance, broadly characterized as ‘token-based voting,’ has received thoughtful critiques from prominent projects, with some projects actively experimenting with new ‘reputation’ or ‘skill’ based models. By briefly reviewing some key history of governance in distributed systems, summarizing the major criticisms of token-based voting, and critically commenting, this article will help readers better understand and assess new developments in governance.


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.

Scope of DecisionsProtocol changes, Funding allocationsValidating blocks, Protocol changes, Funding allocationsWhich projects get listed with Kleros badge.Oracle inclusion, Risk parameters, PersonnelBlock Producer Selection, Broad Referendums‘Baker’ (block producer) selection, Protocol changes
Token MechanismHold 1000 Dash to run a MasternodeLock tokens to generate tickets, used in validation lottery and proposal votingEarly votes have double weightWeighted voting,
‘1 token=1 vote’
Weighted voting,
‘1 token=1 vote’
Weighted voting,
‘1 delegated token = 1 vote’ with some nuance

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.

Perceived Issues in Token-Based Voting:  

01: Sluggish Decision Making

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.

How ‘Rep’ and ‘Skill’ Models Address the IssueHow Token-Based Models Address the Issue
Reputation- or skill-based models involve a smaller group of high ‘reputation’ or ‘skill’ users participating in decision making, in theory speeding up decision-making because the decision-making body is smaller, more formally defined, or composed entirely of experts.Token-based voting models are only ‘slow’ when token holdings are diverse and participation is low; centralized holding leads to faster decisions, but presents other issues (see ‘Centralization’). ‘Slowness’ in decision making is a feature for some projects; preference for faster decisions can reflect different project needs.

02: Lack of Expertise Among Voters

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.

How ‘Rep’ and ‘Skill’ Models Address the IssueHow Token-Based Models Address the Issue
Reputation based models award reputation for voting on ‘correct’ decisions, lost on converse. Appointment to decision-making groups can be based on transparently disclosed work history. Councils attempts to attract skill through competitive salaries.Token-based funding allocations typically have a practice of awarding funding to proposals whose contractors have good results or of tying funding to milestone completion. Subject experts who are not token holders can still influence votes through open discussions of proposals. (See ‘Sluggish Decision Making’.)

03: Conflicts Among Token Holder, User, and Project Interests

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.

How ‘Rep’ and ‘Skill’ Models Address the IssueHow Token-Based Models Address the Issue
The design of conditions for reputation gain and loss allows projects to tailor, to some extent, what stakeholder groups get represented in decision making. Reputation arguably lessens the ability for money to buy influence in project governance. With respects to inter-user conflicts, counsel-based approaches allow certain decisions to be delegated to impartial or trusted third parties.Some token-based models argue that a lack of responsiveness to platform users in the long run undermines tokens as an investment, so see token holders as adequately incentivized to consider user interest. Token-based voting is often not the only way to influence project decision making: a user base can sometimes participate in governance through creating, critiquing, or executing project proposals.

04: Vote Buying

Through vote buying, anyone can use a token-based governance system to undermine competitors or for short-term investment purposes.

How ‘Rep’ and ‘Skill’ Models Address the IssueHow Token-Based Models Address the Issue
Reputation is non-transferable and can be stripped based on behavior. Reputation cannot be trustlessly sold (or so argues DAOstack), introducing counter-party risks that affect market conditions.Purchasing influence can be viewed as a feature; the protocol is to an extent up for sale by those willing to invest in it. The cost of buying enough tokens to achieve short-term interests can be made economically irrational through some approaches (see quadratic voting). Purchasing influence can be viewed as a feature; the protocol is to an extent up for sale by those willing to invest in it. The cost of buying enough tokens to achieve short-term interests can be made economically irrational through some approaches (see quadratic voting).
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.

05: Centralizing

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.

How ‘Rep’ and ‘Skill’ Models Address the IssueHow Token-Based Models Address the Issue
Reputation concentrations can be allotted for specific project contributions—completing value adding tasks, participating in value adding decisions, etc. Reputation can be revoked or made to decay, enabling projects to build a ‘’what have you done for me lately?’ privileging system.Some projects see token holders as taking greater risk, with fairness requiring proportionally greater influence. Token funds or reserves can be allocated for decentralizing purposes. Mechanism design can decrease the effects of token concentrations to some extent (see Decred’s ticket system).

06: Representational Fragility

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.

How ‘Rep’ and ‘Skill’ Models Address the IssueHow Token-Based Models Address the Issue
Reputation is non-transferable and has high counter-party risks, so is a less likely target for fraud. Systems with both token and reputation based voting could give fraud victims another form of representation in decisions in the aftermath of token loss.A community, at its discretion, could vote to allocate tokens to fraud victims or reverse hacks. Fraud victims retain indirect modes of representation through discussion channels and project proposal systems.

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. Melonport’s analysis in particular should remind readers that there is no ‘the’ governance problem for crypto, but rather governance problems for crypto, with models’ suitability varying among different layers and project goals.

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 some respects DAOstack’s ‘reputation v. token’ framing used to promote the new toolset is somewhat unfortunate; introducing ‘reputation’ as a new lever in a decision making process need not be an either-or choice for organizations currently using token-based systems.

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.