Skip to main content

Blockchain Governance in the Wild

Published onApr 22, 2024
Blockchain Governance in the Wild


The key function of blockchains and decentralized applications (dApps) built upon them is to reach consensus with minimal centralization or hierarchy across many independent, economically-motivated actors. We call governance the collection of procedures, rules, and norms that allow these actors to make and implement decisions. Governance is a challenge found in all human societies. While many blockchain enthusiasts believe that all governance can be encoded within software minimizing or removing centralization, actual blockchain governance experiences involving many contributors and significant assets tend to differ from the pristine abstractions described in initial whitepapers.

Through a questionnaire, we have collected data regarding governance practices at 23 blockchain projects, including both layer 1 blockchains and dApps. (See Appendix B for list.) This approach allows us to make high-level comparisons, and to drill down into the complex narrative understandings of project participants. We document and compare how different participants implement project governance, both through formal practice (code or company structure) and informal (social norms and practices).

First, we survey the history of blockchain governance, highlighting major controversies that illustrated recurrent challenges. We describe how our questionnaire provides a common baseline to record how different communities implement their governance arrangements. We then use our dataset to compare blockchain governance structurally, both among our questionnaire respondents and with other kinds of non-blockchain organizations, for example open-source communities like Wikipedia [1].

We then show from the questionnaire responses how different projects address key governance challenges in their own context. This analysis is divided into two parts. We describe how projects implement the two canonical modalities of blockchain governance: immutably- recorded software code of the blockchain (“on-chain”), and mechanisms for stakeholders to negotiate or agree upon decisions among themselves (“off-chain”). And then we compare the way projects think about three key attributes of governance: rule formalization, legitimacy, and decentralization. This survey illustrates the variety of responses among different communities, even on seemingly foundational matters such as what makes a decision legitimate.

A literature review of the way blockchain networks govern themselves or interact with existing governance systems is provided in [2]. Some of the scholarship in this area focuses on how specific projects address moments of crisis, such as the block size debate in Bitcoin [3] and the Ethereum community’s handling of The DAO [4]. Other works of scholarship examine the potential (theoretical) failures resulting from specific design decisions, such as the Babylon update to the Tezos protocol [5]. Others focus on the encoded practices of blockchain communities and their impact on decentralized governance, such as the accuracy of pricing oracles and MakerDAO stablecoin governance decisions [6]. Finally, ethnographers have begun to embed themselves in particular blockchain communities to develop a qualitative understanding of their norms and processes [7].

Our work differs from the existing literature in three significant ways. Firstly, there has been very little comparative work among different blockchain networks or communities—what exists generally focuses only on Bitcoin and Ethereum at most. Secondly, this is not a theoretical study of potential successes or failures: We instead survey practical implementations, and governance development plans of specific projects. Finally, we do not examine only the governance decisions encoded on-chain. Our work expands to consider social norms, informal practices, and institutional governing entities associated with the project outside of the code. We believe this paper is the first to formally document and highlight the importance of informal governance structures within blockchain projects.

The work of [8], which conducts a cross-sectional overview of the governance practices of 50 crypto projects, is most similar to ours in scope. However, it was conducted at a significantly earlier stage of market development. Moreover, their analysis focuses only on formally-codified practices (launch style, corporate support, network value), and does not contain the ethnographic component of informal practices that we capture in our survey. While the explicit rules of blockchain governance structures can be read from their software code or documentation, neither the code nor the documentation can tell us how those rules interact with more informal off-chain practices—practices which we aim to capture in our study.

It should also be noted that these off-chain governance practices and institutions are of interest not only to academics and decentralization purists but also have a measurable impact on the pricing of tokens affiliated with a project [9]. The approach of [10] is the most similar to ours in methodology, as the authors conduct interviews of eight experts to examine two projects, ETH and EOS.IO, through the lens of on-chain and off-chain governance procedures. Unlike their work, we do not constrain our respondents to examine their governance through a specific lens; instead, we provide 20 broad questions and then group answers in post-analysis described in the following section.

Governance Analysis

History of Blockchain Governance

By their nature, blockchains can replace top-down, centralized guarantees provided by one trusted authority with decentralized forms of trust based on economic incentives and cryptographic proofs. While it may seem that decentralization eliminates the need for governance, this is not the case. Even Bitcoin, designed to be fully decentralized and “trustless,” has a governance regime with distinctive norms, procedures, and powerful actors [11]. The continuing evolution of blockchain governance is a natural consequence of experimentation. New blockchain platforms and protocols take stock of existing ones, incorporate their learnings, and seek to improve on them. Governance practices and mechanisms also evolve in response to controversies, which highlight limitations of current approaches.

The most obvious tradeoff of decentralized governance is that it can make decision-making more cumbersome. Organizations led by a single leader, or a small group of decision-makers with authority, can turn on a dime when called for: Facebook founder Mark Zuckerberg decided, virtually on his own, to spend a ridiculous-seeming $1 billion to acquire tiny Instagram, a decision that proved to be a spectacularly good bet. He subsequently decided to spend more than $1 billion per month to pivot the company’s focus to the metaverse, which so far has not yielded similar benefits.

Decentralized governance systems, by their nature, must take into account more voices, who may be in opposition. Even creating the conditions for a debate may be difficult, due to informational gaps, lack of good communications channels, or rational apathy by members of the community. In the case of blockchain-based projects, several factors are likely to accentuate governance challenges. The technology is new, unfamiliar, and often deployed in an imperfect state; participants often have little experience with large-scale organizations or communities; projects (or at least the market value associated tokens) may grow explosively; the ethos of blockchain may encourage individualism over communal activity; and project participants are in many cases pseudonymous, limiting the depth of social connections that might aid dispute resolution. Thus, it is not surprising that the history of blockchain governance to date is largely one of potentially existential controversies.

The first great governance crisis in blockchain was the long-running Bitcoin block size debate [11]. As Bitcoin adoption grew after the initial surge of interest in 2013, network congestion became an increasingly significant problem. A number of proposals were floated, with most seeking to increase the size of each block of transactions added to the blockchain. Significant factions of Bitcoin developers, including influential members of the core group, opposed these changes. They argued that changing an essential parameter such as block size could alter the power balance between users and miners, making it easier for miners to exercise disproportionate influence, which would be inconsistent with Bitcoin’s decentralized ethos. Additionally, implementing any of the proposed changes would require a hard fork of the network. A majority of miners would have to voluntarily switch to the new software, and even then, the minority chain might continue operating in parallel if it retained significant support leading to competing Bitcoin chains.

All of this provoked repeated cycles of conflict with little actual movement forward. Ultimately, an agreement was brokered among leading miners and developers in 2016. Segregated witness (Segwit), a set of improvements to Bitcoin efficiency and transaction integrity, would be implemented first, followed by an expansion of the block size to two megabytes. Though there was substantial opposition to Segwit, it was adopted after threats of a user-activated soft fork (UASF) which might have split the network. The block size increase never took place, as too many miners and other node operators got cold feet. The response to our questionnaire for Bitcoin, written by an influential author and venture capitalist, highlights this example.

While Bitcoin itself did not fundamentally change its structure to incorporate additional functionality or governance capabilities, the limitations of its design revealed by the block size debate became a rallying cry for new blockchains, most prominently Ethereum. However, Ethereum quickly illustrated that with greater capabilities came new governance challenges.

Ethereum was the first permissionless blockchain network to offer a Turing-complete smart contracting language and a virtual machine architecture, meaning that any software that could run on a computer could, in theory, operate on the blockchain. The Ethereum response to the Governance Assessment questionnaire, written by an active participant in Ethereum governance and development efforts at the time, emphasizes the breadth of the Ethereum mission.

Excitement about the potential of dApps and DAOs enabled by Ethereum’s focus on smart contracts, along with a limited number of other uses for the Ether cryptocurrency after Ethereum launched, are among the reasons there was so much excitement in the Ethereum community about The DAO which launched in spring 2016 [4]. The DAO was a decentralized investment fund. Users contributed Ether and received in return tokens granting voting rights. Developers could propose projects for funding, and would receive Ether based on the vote of DAO participants. Within a few weeks of fundraising for The DAO, roughly fifteen percent of the total supply of Ether (worth over $150 million at the time) had been committed to The DAO. Then, a malicious actor exploited a vulnerability in the smart contract code to siphon off roughly forty percent of the committed funds. Thanks to a failsafe mechanism, however, the attacker had to wait a month before the Ether could be taken out of the system entirely.

The Ethereum community faced a choice. The attack was clearly not an intended use of The DAO, and in the minds of most Ethereum holders it was a theft. However, it was within the parameters of the software as written. More to the point, given the decentralized ethos of the project there was no central controller who could reverse the transaction and return the funds to The DAO. Ethereum developers and Ether holders debated whether to execute a hard fork that would return the funds by rewriting transactions on the blockchain: such an action would break the (claimed) immutability of the Ethereum blockchain. In the end, with the support of most of the core developers, the hard fork was implemented. A dissident faction, however, continued to mine the other side of the fork in which the transactions were not undone: that fork has been renamed Ethereum Classic (ETC). As with Bitcoin Cash, Ethereum Classic has continued to operate but at a far lower transaction volume and token price than Ethereum (ETH).

Both sides agreed that the frantic, confused response to The DAO attack was a poor governance model. Bugs, hacks, and unanticipated situations are a natural and continuous danger for any software system. Given the novelty of smart contracts and their technical tools, failures are inevitable and when those failures occur on non-upgradeable smart contracts, there may be no solution other than a disruptive fork. In 2016, when there were few active dApps on Ethereum (other than The DAO itself), a hard fork could be executed without massive disruption; today, with hundreds of billions of dollars in DeFI and NFT platforms on Ethereum, that would be unlikely.

Moreover, as with the Bitcoin block size debate, the informal polls for token-holders to signal their preferences on the post-DAO Ethereum fork were of questionable validity. In particular, they did not incorporate the sybil resistance and double-spend protections that are among the fundamental benefits of permissionless blockchains. Additionally, when faced with an external attack, The DAO incident showed that even blockchain systems occasionally require rapid decision-making capability: a challenge for any decentralized system and a natural channel for off-chain governance to sway decisions. While Ethereum did not adopt formal governance changes after the DAO attack, it did develop a number of mechanisms to facilitate greater rapid coordination among stakeholders.

The DAO incident generated another upsurge of interest in on-chain governance. While Bitcoin’s debate was acrimonious and slow, Ethereum’s response was perceived as lacking transparency and based upon off-chain decisions made by a few central decision-makers. On-chain governance allows for smart contracts to be upgraded based on the votes of token-holders. The smart contracts remain immutable, but enough users acting together could change parameters or execute other functions (such as rolling back state prior to an attack like The DAO exploit), without forking the underlying blockchain.

On-chain voting systems are now widely deployed in base-layer blockchains such as Tezos, Decred, and EOS, which imbued their native cryptocurrency with governance powers, and many dApps which issue special-purpose governance tokens for this purpose. However, on-chain governance has not eliminated blockchain governance controversies, and instead brought in new governance issues.

While token-based governance is intended to be more transparent and accountable than traditional off-chain governance, it faces an important limitation when ensuring a proper representation of the community member’s contributions. While the founders and early contributors are generally assigned a large portion of the overall token supply, market dynamics are such that, over time, the main token holders might no longer be representative of the main contributors. Token-based governance favors those who have invested the most money into the project as opposed to those who have invested the most time or effort. As a result, big investment funds might acquire a large portion of tokens and make decisions that will increase the value of the tokens as opposed to increasing the value or sustainability of the associated initiative. Such a plutocratic system might also be vulnerable to bribery and vote-buying, potentially leading to a situation where vested interests take over the governance of the system, at the expense of the original community values.

The “rational apathy” of low voter turnout creates a climate where active holders of a relatively small amount of voting power might have a disproportionate impact, especially if the governance system lacks sufficient checks.1 This has allowed for so-called “governance attacks.” A prominent example took place in 2019-20 on the Steem platform, a blockchain-based content site that uses its token to reward and incentivize posts [12]. Steem has an on-chain governance platform based on a delegation model. Token holders vote to select Witnesses, analogous to miners for Bitcoin and Ethereum. SteemIt, the original developer of the application, pre-mined a significant amount of tokens when it launched in 2016, although its founders indicated they would not exercise that governance power. Substantial numbers of Steem tokens were also held in custodial accounts by cryptocurrency exchanges. Justin Sun, a controversial founder of the Tron blockchain, attempted to acquire sufficient Steem voting power to take control of the network. He purchased SteemIt and its remaining pre-mined tokens from a co-founder, and convinced major exchanges to vote along with his block. He was able to control roughly 30% of the voting power.

Alarmed Steem users quickly organized a counter-offensive. They were able to vote in a new set of Witnesses that executed a fork, under which Sun’s tokens lost their voting rights. The main exchanges that originally worked with Sun shifted their position amid publicity that they were contributing to a governance attack against the desires of their own customers. In this case, informal channels could assemble enough formal governance power quickly enough to coordinate a hard fork, and exert pressure on other players to align against the interest of a dominant token holder.

As the economic value associated with digital assets and blockchains grew, the stakes of governance controversies increased. With the explosion of digital assets locked in decentralized finance (DeFi) protocols from roughly $1 billion in early 2020 to $100 billion in mid-2021, and the total value of digital assets in circulation reaching approximately $3 trillion during that time period [13], governance failures could have massive consequences.

One of the most prominent failures involved Terra. Terra’s UST algorithmic stablecoin is associated with the floating-value Luna token, which in theory grants governance power to vote on management of the blockchain.2 UST and Luna are redeemable for each other, creating an incentive to maintain UST’s peg to the U.S. dollar. At its peak, the Terra ecosystem held $60 billion in assets. In May 2022, Terra collapsed as UST lost its peg and the Luna token entered a death spiral of redemptions [14]. The actions of Terra’s founders and the rapid collapse of UST illustrated that supposedly decentralized governance sometimes turns out to be illusory.

As this summary demonstrates, governance controversies have persisted for virtually the entire history of the blockchain space. Major governance crises can cause significant disruption, but there are now many operational governance systems that, for the moment, appear to operate smoothly and have incorporated lessons from the governance pain controversies described in this section. There is some basis to believe that, even in the absence of formal technical standards or regulation, the blockchain community engages in organizational learning as projects observe market developments [15].

To assess these operational examples of blockchain governance, we developed the Governance Assessment Questionnaire. In the remaining sections, we use the responses to the questionnaire to consider the intentions and implementations of the governance approaches represented within our sample, and examine the implications for the future of blockchain governance.

The Governance Assessment Questionnaire

One of the authors hosted an initial meeting of experts in 2019, which led to the creation of a 20-question Governance Assessment Questionnaire instrument intended to be broad enough to cover a wide range of blockchains and dApps.3 The questionnaire was refined over a period of several months by participants to create a consistent yet flexible tool for blockchain governance assessment. It was then distributed to projects during 2020 and 2021.4 When feasible, respondents were employed by the project, while for decentralized projects such as Bitcoin and Ethereum respondents were recognized individuals active in the community.5 The only discarded responses were those with substantially incomplete answers (Commonwealth), leaving the diverse sample of 23 projects listed in Appendix B, including permissionless layer 1 blockchains such as Bitcoin, Cardano, Algorand, and Tezos; permissioned blockchains (Corda Network); decentralized applications including Filecoin, Uniswap, and 0x; stablecoins (USDC); and DAOs (MakerDAO and Bankless DAO).

Each answer was reviewed and grouped according to its characteristics by a team of reviewers who manually determined whether a characteristic applied to the project. As an illustration, Figure 1 shows how two projects represent themselves in response to the question: “What behavior does the project seek to incentivize? How are such behaviors incentivized? (For example, financial benefits, belief in shared values, costs of network failure, or costs of exiting.)” In the provided example, the reviewers determined the answer from Compound indicated liquidity targeting through financial incentives, while Decred sought to gain contributions from the community and good governance through financial incentives and risk sharing. All answers can be read on the Wharton Cryptogovernance Project website,

Figure 1: Questionnaire responses to Question 6, “What behaviors does the project seek to incentivize?”, from Compound (left) and Decred (right). Based on projects’ text responses, we coded Compound as incentivizing “liquidity” using “financial incentives” and Decred as incentivizing “community contributions” and “good governance” using a combination of “financial incentives” and “financial risk (staking)”.

Because the questionnaires required manual responses from knowledgeable project participants, we could only collect data from a small percentage of the operating blockchains, dApps, and DAOs. Some projects declined to participate because their governance structures were not well-enough developed; others were concerned that there might be legal consequences in formally identifying those who held governance roles. Despite this, the richness of the data collected allows us to draw a more nuanced picture of the blockchain governance landscape beyond the frequently studied examples of Ethereum and Blockchain.

Visualizing Project Governance

Though it would be impossible to generalize completely across the entire universe of base- layer blockchains, functional dApps, and DAOs, the structured responses allow us to construct a model of how different projects are governed in practice. Before discussing specific aspects of governance, it is helpful to provide high-level visualizations to compare the governance arrangements of three blockchain projects (Ethereum, Tezos, and Uniswap), and to compare those with the governance of two non-blockchain projects: Wikipedia and Meta (Facebook).

We visualize the formal / informal, explicit / implicit interactions across organizations and projects for Ethereum in Figure 2. Of specific note is the importance and number of mostly informal relationships in the Ethereum project. Its sole legal relationship is with the Ethereum Foundation, which maintains control over the open-source repository containing the core code (but not the blockchain itself), and the sole code-based relationship between the Ethereum project and another entity is that between Ethereum and its validators. The mechanisms of Ethereum governance employed across the remaining organizations range widely, from exit by ETH token holders (to show disagreement) to proof-of-stake consensus by the validators to majority voting by the board of directors of the Ethereum Foundation. This shows not only that legal and code-based relationships represent just a small subset of all the governance relationships in the Ethereum Project, but that the remaining informal or off-chain governance processes cannot be easily grouped together as a single “type.”

Figure 2: A model of the governance of Ethereum based on the results of the Governance Assessment questionnaire. The colors of the arrow denote the type of relationship (legal, formal but not legal, informal, or code-based), while the text label denotes the method by which the governing entity makes decisions that pertain to the project (or entity) that it governs. The model above assumes that Ethereum has finished transitioning to proof-of-stake consensus.

Figure 3 creates a similar visualization of governance for a token-centered project (Tezos) and a DAO-centered project (Uniswap). While coded-governance occurs for only one organizational instance in Ethereum (proof-of-stake project proposal voting), it occurs twice in Tezos (Bakers and staked token holders), and three times in Uniswap (DAO members, governance token holders, and any delegates). This visualization emphasizes how the importance of different types of governance varies across projects in the blockchain space. Even legal relationships can vary in notable ways across projects: the Ethereum Foundation contributes to Ethereum governance through majority vote, the Tezos Foundation has a hierarchical decision making process, and it is unclear whether Uniswap has any formal legally recognized relationships.6

Figure 3: Comparing the governance models of (top) a token-centered project, Tezos, (bottom) a DAO-centered project, Uniswap. The models are created using responses from the Governance Assessment questionnaire, while those for Wikipedia and Facebook were constructed from secondary sources. For the legend for these figures, please refer to Figure 2.

Figure 4 models the governance for Facebook and Wikipedia. Facebook is a traditionally established social media platform with a purely digital product governed by Meta, a for-project company listed on the USA stock market. In comparison to preceding graphs of blockchain projects, many of Facebook’s governance relationships are formalized in legal agreements. In contrast, Wikipedia is a community of mostly volunteer editors overseeing the world’s most comprehensive encyclopedia. It is often used as an illustration of how internet-based “commons-based peer production” makes it possible for decentralized communities to rival or even surpass the output of traditional centralized for- profit companies [16]. Like many blockchain projects, Wikipedia is under the oversight of the non-profit Wikimedia Foundation. It has considerably fewer legal governance relationships than Facebook, and also has a code-based governance relationship with its unregistered users despite not being a blockchain company.

Figure 4: The governance model of (top) a traditional social media platform, Facebook, and (bottom) a non- blockchain, peer-produced project, Wikipedia. The models for Wikipedia and Facebook are based on information collected from secondary sources including [1]. For the legend for these figures, please refer to Figure 2.

Figure 2 through Figure 4 highlight how blockchain companies differ from traditional companies (fewer legal relationships, more informal and code based relationships) and also from each other: blockchain governance is multi-faceted and the governance of one project cannot necessarily be generalized to another.

Governance Mechanisms

In addition to the structural analysis described in the prior section, the questionnaire responses allow us to dig into the ways that different projects implement the two signature modes of blockchain governance.

In spite of Bitcoin’s unofficial motto “vires in numeris” (strength in numbers), understood to be a play on words to imply that math (code) is the only thing that matter in a blockchain- based system, the reality is that people interacting with these systems do not only need to trust mathematics and numbers but also the people behind these numbers: one cannot disregard the social and institutional fabric responsible for developing, deploying, executing, and potentially revising that code. We next describe the most common attributes found in the social fabric of existing blockchain systems, and how they each affect the overall governance of the system.

There are two domains of blockchain governance activity: off-chain and on-chain.

Blockchain-based systems may involve multiple forms of both simultaneously. This generates a complex typology of governance structures, each with their own distinctive characteristics and political implications.

Off-Chain Governance

Off-chain governance encompasses both formal and informal activity which is not automatically implemented by the blockchain itself. A decision by miners to adopt a new software update or a standard proposed through a structured process modeled on the Internet Engineering Task Force’s Requests for Comments (RFCs) are examples of off-chain governance. Some humans must take further action to execute any decisions reached.

We identify three important power clusters in off-chain governance, which are highlighted in the questionnaire responses: key stakeholders (developers, validators, and users); charismatic leaders; and legal entities.

The Stakeholder Triad

In a public permissionless blockchain network, power over the consensus mechanism is distributed across three main stakeholder groups: developers, validators, and the “economic nodes” representing users. Software developers write the code that defines the operation of the blockchain. Validators, such as Bitcoin’s miners, compete to add blocks of transactions to the chain. Users decide which client software they will employ to view and transact with the blockchain. The Bitcoin block size debates of saw each of these stakeholder groups exert power to block, or attempt to force, governance decisions regarding the future of Bitcoin in accordance with their interpretation of the original principles laid out in Satoshi Nakamoto’s 2008 whitepaper [3].

To some Bitcoin maximalists, the block size controversy is a success story. They argue that Bitcoin only a unique force for transforming the global financial and political system, to the extent it remains maximally decentralized. Anything that allows a distinct faction to gain power destroys this balance. Moreover, Bitcoin’s extraordinary robustness, even as the value of the token and the sophistication of the mining industry skyrocketed, proved to the advocates of this viewpoint that, “if it ain’t broke, don’t fix it.” Others, however, saw evidence that Bitcoin’s absence of viable governance mechanisms was a terminal flaw. Bitcoin, they felt, simply could not evolve. Most notably, it couldn’t be successfully jury-rigged to do more than it was originally designed for: creating digital money to be used for payments. The questionnaire response reflects the sense that making governance changes to Bitcoin has become harder as the project has aged.

Charismatic Leaders

Even though most blockchain projects allow anyone to contribute code or fork the project, not all voices have equal weight. This is a familiar model from major open-source software projects such as Linux, for which Linus Torvalds is the acknowledged “benign dictator,” or peer production communities such as Wikipedia, led by Jimmy Wales [16]. The Bitcoin model is particularly interesting, as the creator (Satoshi Nakamoto) has decided to remain anonymous and has gone completely silent since the early days of the project. This means that— at least in theory—Bitcoin is a leaderless network with no central authority which has the ultimate say over the way in which Bitcoin shall or shall not evolve. Yet, in practice, while no one is officially in charge of its development, some developers are more influential than others.

Just like many other open-source software projects, the Bitcoin Core repository on GitHub is based on an open contributor model, where anyone can contribute code and patches to the Bitcoin software in accordance with the community guidelines. Yet, there is a small group of core developers (i.e. those who maintain the Github repository and are responsible for merging the pull requests) dominating—and consequently centralizing—the development process. These developers enjoy a privileged position in that they can decide what ultimately gets into the code and when a new version of the Bitcoin Core client gets released.

In the case of Ethereum, the founder (Vitalik Buterin) plays a very significant role. The software development process of Ethereum is similar to that of many other open-source projects, which feature a benevolent dictator. While there is—again, in theory—no central authority in charge of maintaining the software code, Vitalik Buterin is almost unanimously regarded as the ultimate authority by the Ethereum community and exerts considerable influence when it comes to making decisions regarding the development of the Ethereum protocol and associated blockchain network. While he is not necessarily in charge of coding the various components of the Ethereum ecosystem, he is deeply involved in the development thereof, by doing research and providing recommendations on how the code should be implemented, and by reviewing the code of others to ensure that it complies with the overarching policy and technical goals of the system [17].

Just as in the case of Bitcoin, Ethereum enjoys a small number of core developers or maintainers who play a dominant role in the software development process. To be sure, the development process of Ethereum is by some measures more decentralized than that of Bitcoin. There are multiple Ethereum clients created by independent development teams. And because the Ethereum Virtual Machine is rigorously documented [18], competing blockchains such as Avalanche and Binance Smart Chain, as well as scaling systems or “layer 2” solutions such as Polygon and Arbitrum, can directly execute smart contracts developed for Ethereum.

Many “Ethereum” developers are therefore not necessarily working on the Ethereum project itself. Yet, the number of people who actually have a say on the development of Ethereum remains very limited. As clearly stated by Vitalik Buterin in an interview [19], despite its decentralized nature, Ethereum governance is “kind of technocratic in some ways because [...] there is only a small group of people that really deeply understand all the different Ethereum technical considerations,” hence “a lot of decisions get made by a small group.”

The Bitcoin and Ethereum responses to the questionnaire acknowledged the outsized role that charismatic developers play in the governance processes of these projects. The same is likely to be true of most blockchain communities.

The questionnaire responses reveal that most projects have a variety of different types of legal entities involved in governance, with the median project associated with two entity types. For-profit companies are by far the most common legal entity, with 78% of the projects in our sample are associated with at least one for-profit company, as shown in Figure 5. Foundations are the next most-often mentioned, with 52% of the projects in our sample associated with one foundation. There were no projects associated with more than one foundation, though some projects such as Tezos are governed by a separate nonprofit as well as a foundation. Finally, other loosely-organized online communities such as the set of BIP editors or the Ethereum Cat Herders (a group of project managers in the Ethereum community) play an important role in the governance of these projects.

Figure 5: Frequency of different coordinating entities, in response to Question 2, “What, if any, are the coordinating entities, and what are their functions?”

Many blockchain projects are managed by a foundation in charge of stewarding the development of the project. The influence of these foundations is generally not absolute because they do not have the power to directly interfere with the operations of a particular blockchain, but such power can often emerge because they hold the funds raised for a particular project and are thus responsible for hiring the large majority of developers and maintainers.

Bitcoin does not have any official legal or organizational structure that represents it [20]. The Bitcoin Foundation was created in 2012, after the disappearance of Satoshi Nakamoto. Although it never officially represented Bitcoin, its intention was to become a key player in the Bitcoin ecosystem. Its declared objective was to standardize, protect, and promote the use of Bitcoin, by influencing the development and the roadmap thereof. Yet, the Bitcoin Foundation was regarded by a large majority of stakeholders as a controversial entity that could become a centralizing force in the ecosystem, or as a mere façade with no real incidence on the development and uptake of Bitcoin. Originally intended to support the core development of Bitcoin, the Bitcoin Foundation eventually shut down due to its inability to raise sufficient funds to support its operations. In contrast, the Ethereum Foundation was established in order to manage the funds raised by the Ethereum token sale back in 2014 and has since become one of the key players in the Ethereum ecosystem, responsible for promoting the adoption of Ethereum and ensuring the proper allocation of resources to key infrastructure projects. It has also acquired recognition as one of the most venerable voices in the Ethereum ecosystem.

Most of the first-generation smart contract blockchains (such as Tendermint, Tezos, Cardano, and Stellar) have replicated the same process as Ethereum, creating a foundation in order to collect the funds raised through the initial offering of their native cryptocurrency. One reason for the establishment of a foundation instead of a corporate entity is tax optimization. Yet, a foundation also comes with a specific mission, along with a series of requirements and constraints on how money can be spent, which is likely to guarantee more trust and legitimacy than a privately-held company. Cardano’s response describes how the community sees the division of tasks between the foundation and the two for-profit companies associated with Cardano, and highlights how many projects foresee further decentralization as they mature. The Tezos response describes a similar constellation of actors.

What, if any, are the coordinating entities, and what are their functions? (For example, a foundation, software development corporation, DAO, etc.)

[Bitcoin Response] There is no single or official coordinator in bitcoin. The entities which employ the largest number of developers are Blockstream, Chaincode labs, the Digital Currency Initiative, and Square Crypto, although these organizations generally do not demand that their developers advocate for a given political strategy within Bitcoin. Bitcoin development is fragmented and coordination happens through a mailing list, the official bitcoin github, social media settings like twitter and reddit, and a large number of conferences and meetups, in particular the bitdevs meetups. Currently Wladimir van der Laan is the lead maintainer of the Bitcoin Core Github for housekeeping purposes, although he explicitly disavows any power over the direction of protocol development.

Previously, miners were entrusted with signaling authority to ratify various soft forks, giving them effective coordinating ability. However, it is currently unclear whether this coordination method would be adopted for future changes.

[Cardano Response] There are three organisations that are contributing to the development of Cardano:

  • The Cardano Foundation is an independent body based in Switzerland with core responsibilities to oversee and support the Cardano ecosystem. Its mission is to drive adoption, shape blockchain governance, set commercial standards and support the community of users .

  • Input Output HK (IOHK) is an engineering company that builds cryptocurrencies and blockchains for academic institutions, government entities and corporations. IOHK is contracted to design, build and maintain the Cardano protocol.

  • EMURGO, a multinational blockchain technology company providing solutions for developers,

On-Chain Governance

On-chain governance mechanisms operate through transactions on the blockchain itself.

Decisions are then executed automatically through the operation of smart contracts.

As shown in Figure 6, the software code of the blockchain or dApp may give governance rights to particular entities. The consensus process of a blockchain can be seen as a limited form of on-chain governance, through which miners or other validators determine which transactions and blocks are added to the chain. However, as illustrated in the Bitcoin block size debate and the The DAO incident those validators also make off-chain decisions such as which software version to adopt or which chain to follow.

Figure 6: Frequencies of different types of software entities and roles involved in blockchain governance, in response to Question 4, “Does the project’s software code delineate groups with particular functions?”

Token-Based Voting

On-chain governance mechanisms rely on tokens to enable people to vote on specific questions with regard to a large variety of issues, including the development and upgrade of the blockchain protocol itself. Many DeFi platforms have adopted this model, whereby token holders can vote on critical governance questions, such as the fee structure (e.g. how much does it cost to use a particular service) or the formula for the distribution of new tokens. For instance, UNI token holders are solely responsible for the stewardship of the Uniswap protocol. Token holders can vote to change the protocol fees, they can choose to add or remove tokens from the Uniswap default list, and they are in charge of administering the UNI community treasury for the issuance of grants to projects that contribute to the growth of the Uniswap ecosystem.

Similarly, the MakerDAO protocol implements the MKR governance token, used to vote on a variety of things, such as changing some of the parameters of the Maker Protocol (e.g. stability fees, debt ceiling) and making decisions concerning non-technical aspects of the protocol, such as governance processes, role mandates, and asset priority lists.

Like consensus on block validation, governance is a collective action problem. Satoshi Nakamoto’s Bitcoin design overcame that problem through incentives: miners compete to earn rewards for validating blocks. Many on-chain governance solutions take a similar approach.

They offer financial incentives through token grants to those who participate in desired ways. Tezos was perhaps the most prominent early illustrative example of a blockchain project that uses tokens to incentivize good governance. The Tezos blockchain implements a protocol that is designed to enable token holders to decide upon the way in which the rules of the protocol should evolve over time. As shown in the questionnaire response, this process directly connects to the incentive structure for Tezos’ proof of state validation system.

Many token holders either do not care about governance (because their true motivation is appreciation of the token), do not wish to devote the time to evaluate proposals, find the voting process cumbersome, represent multiple stakeholders (such as venture capitalists), or rationally conclude their participation will not impact the outcome of votes [21]. There is continuous experimentation to solve the low voter participation issue. As the Compound’s questionnaire response shows, token requirements for voting can be exclusionary as prices increase, and a natural response is for projects to adjust voting requirements by decreasing the number of tokens required to participate. VeChain shows another evolution for projects with multiple tiers of voting according to token or role in the project.

Another concern is that some actors will gain disproportionate voting power and use the on-chain governance system to benefit themselves at the expense of the community. This is the issue in governance attacks such Justin Sun’s attempt to control Steemit. As with the voter apathy issue, projects are experimenting with a variety of responses. For example, Decred is a blockchain that was specifically designed to prevent powerful individuals or groups of individuals from acquiring an excessive degree of influence over the network. The Decred blockchain comes with a particular community-based governance system, whereby token holders can lock their coins for a particular amount of time in order to obtain tickets that will empower them with the right to participate in the network governance and to activate proposed consensus rule changes (if at least 75% of the non-abstaining ticket holders approve). The underlying idea is that those who have put the most resources into the project, including financial resources by purchasing the tokens, should be in charge of its on-going operations and development.

Because tokens are generally tradeable on exchanges, they have financial value. Holders are therefore incentivized to take actions that increase the value of the token, or stakeholders can be granted additional tokens to reward them for governance activities that benefit the project. As Figure 7 illustrates, such financial incentives are common in the projects that completed the questionnaire, and are overwhelmingly the most popular means of incentivizing governance, although not the only one.

Figure 7: Frequency of different incentive mechanisms across blockchain projects, in response to Question 6, “What behaviors does the project seek to incentivize? How are such behaviors incentivized?”

The incentive mechanism can seek to incentivize a wide range of behaviors associated with both governance and project health. Figure 8 shows the behavior that projects responding to the Questionnaire seek to incentivize through their rewards structure. About 43% of projects seek to incentivize mining or node provision, though almost as many seek to incentivize community contributions in the form of code and apps. Notable is the fact that “good governance” has a relatively low occurrence among the listed of explicitly targeted behaviors – most tokens are not issued with the intention of creating good governance, but to incentivize behavior that add to project value without necessarily yielding governance power.

Figure 8: Incentivized behaviors quantified by the number of projects which actively sought to incentivize those behaviors, in response to Question 6, “What behaviors does the project seek to incentivize? How are such behaviors incentivized?”

EOS is another blockchain-based system that encourages token holders to engage in the governance of the blockchain, by delegating to specific block producers the power to freeze user accounts, update existing applications, and potentially implement changes to the underlying blockchain protocol. While blocks are created by the block producers, token holders nonetheless hold the ultimate say, since they can retire their delegation if the block producers introduce changes without permissions or if they refuse to implement a particular action which has been validated by the token holders.

DAO Governance

Increasingly, token governance is implemented through an arrangement called a decentralized autonomous organizations (or DAO). DAOs were theorized early on by Vitalik Buterin, who defined them as a particular typology of smart contracts designed to collectively manage common resources, i.e. particular set of digital assets that constitute the internal capital or treasury of the organization [22]. While DAO governance has many patterns, it often involves a variation of token-based governance that lives at the application layer (i.e. at the smart contract level) rather than at the network layer of blockchain consensus [23].

With a DAO, the control of digital assets can be delegated to a distributed network of people interacting on top of a blockchain-based infrastructure. Specific DAO building platforms, such as Aragon and DAOstack, emerged to simplify the development and deployment of DAOs. These platforms provide specific governance systems, including traditional (plutocratic) token- based voting or (meritocratic) reputation-based voting. Yet, despite their early promises, these platforms have gained limited traction thus far. DAOs did not acquire mainstream adoption and substantial community engagement until 2020, when they finally began acquiring significant amounts of funds (in the range of several hundreds millions or even billions of dollars) to be collectively managed by their members. As of the writing of this article, the main motivating use-cases for DAOs are crowdfunding applications (e.g. MolochDAO), DeFi applications (e.g. MakerDAO, Uniswap), or NFTs projects (e.g. FlamingoDAO).

Like off-chain foundations, DAOs can manage significant treasuries—sometimes worth several billion dollars. Therefore, DAO governance comes with high stakes. This creates a tension: On the one hand, it becomes crucial to ensure that there are no flaws in the code of the smart contract governing these DAOs, as it could lead to a loss of their funds through an external attack (The DAO exploit). On the other hand, the governance of these DAOs must be simple enough to encourage participation and avoid capture by powerful actors who might divert the funds to serve their own vested interests (the SteemIt experience). If the objective is to ensure the participation of all members, DAOs must find ways to incentivize their members to participate in the governance process, despite the efforts and financial costs this might entail.

This is usually achieved by providing economic rewards to those who actively participate in the DAO—e.g. through the practice of “yield farming” rewarding users who provide liquidity to the system or through retroactive airdrops for all those who actively participate in the use or governance of a particular blockchain system.

The existence of a DAO does not imply that a project is completely decentralized, with no relationship to traditional legal entities. Among respondents to the questionnaire 75% are affiliated with a for-profit company and 30% are affiliated with a DAO. The responses from Uniswap provide an example: the Uniswap grants program is controlled by a smart contract, and can unilaterally disperse funds as long as four out of six members agree to the disbursement. One of those six voting members is a for-project company, Uniswap Labs.

Governance Attributes

Beyond the basic division between on-chain and off-chain mechanisms, three key attributes distinguish blockchain governance systems: the degree to which governance rules are formalized, how the project determines what actions are legitimate, and the extent to which decision-making is decentralized. These reflect the guiding values and norms of the project. The traditional view of blockchain advocates is that trustworthy systems should rely to the greatest extent possible the blockchain network’s software code, limiting formal roles for human actors; legitimacy is to be found solely in compliance with that code; and where activities are centralized, there should be ongoing efforts to distribute control (a process referred to as progressive decentralization). In practice, though, there are tradeoffs that often lead projects away from this vision. The questionnaire responses show how a variety of different communities respond to these pressures.

Rule Formalization

The frequent lack of formalized governance structures for blockchain projects is emblematic of the common belief that human governance is inherently prone to failure (because of errors, biases, or corruption) [24]. The extreme case is Bitcoin, which has no formal governance structure and no formally-empowered entities with oversight for the system. The absence of a defined governance structure is emblematic of the fact that the Bitcoin protocol is considered to be the only source of truth, which should not be undermined at any cost.

Indeed, the immutability of Bitcoin is regarded as a precondition for the proper operations of the system, which would lose all of its credibility if fundamental changes were made to its protocol (e.g. with regard to token issuance or overall supply) or its state (e.g. amending the history of transactions). Yet, even in extreme cases like Bitcoin, decisions to amend the protocol sometimes need to be made, albeit seldomly, in order to fix vulnerabilities or bugs, or as a means to address the scalability problem inherent in every blockchain system. Two major Bitcoin upgrades, Segwit and Taproot, made transactions more efficient and also added functionality that developers could build on. Bitcoin’s block size debate was particularly relevant in this regard because it showed that, even in a system that strongly rejects any type of formalized governance structure, vested interests may nonetheless come into play in order to push towards a particular solution that will benefit a particular category of actors.

While formal coordination is generally discouraged in blockchain communities, informal coordination among core developers has become a recurrent practice. Informal coordination (and even collusion) between the main mining pools operators, cryptocurrencies exchanges, and large commercial players cannot be entirely avoided. This can means that many key decisions are made behind the scenes by a small handful of powerful players.

On the opposite side of the blockchain-project spectrum from Bitcoin are permissioned distributed ledger technology (DLT) networks, with explicit member governance arrangements. These are often managed by a private company or a group of corporate entities which organize themselves into a consortium in order to manage a particular blockchain network. As opposed to public and permissionless blockchains like Bitcoin, whose off-chain governance often remains tacit and implicit, permissioned blockchains are administered according to a formalized set of rules that defines the whole set of rules, power dynamics and relationships that subsist amongst the consortium members. These networks come with a much lesser degree of technological guarantees (with regard to, e.g., the immutability, tamper- and censor-resistance of the network), but also with a much greater level of governability, as it is easier to achieve consensus amongst a multiplicity of network nodes when nodes are governed by a limited number of parties with somewhat aligned interests. Permissioned DLT networks favor speed, scalability, and adaptability amid changing circumstances, allowing for more efficient decision-making in a short time-frame, at the expense of stability and decentralization.

Our questionnaire asked for formally-recognized stakeholder groups, governance powers, and governance procedures, which are examples of formalized governance rules. As the responses for recognized groups show, there is a range of on-chain formalization. Algorand distinguishes different groups based on their interaction with project code. Conflux does not, but projects built on top of Conflux are given the freedom to may do so. MakerDAO determines control by token holding rather than direct interaction with the project, while USDC relies on an off-chain distinction – consortium membership – to determine power.

The range of responses demonstrates that, even when developers of blockchain systems promote minimization of human decision-making, they often create formalized rules for off- chain activity. This is a good illustration of h0w operational governance practices and norms, which the questionnaire captures, do not always correspond to the idealized pictures of whitepapers and developer blog posts. Our goal in this work is not to judge the choices projects make about when and how to formalize off-chain governance roles. However, these baseline explanations can offer a foundation for later comparative work.


Closely tied to the subject of rule formalization is the subject of legitimacy in blockchain governance. But given the number of governance permutations discussed thus far, what allows a governance decision to be perceived as legitimate? Interestingly, there is no single clear answer that unites projects. “Ratification by appointed entity” is at parity with “voting success” or with “adherence to vision” (a social contract between supporters and founders), as shown in Figure 10. A decision that is taken by an appointed entity in opposition to a community vote has the danger of being interpreted as illegitimate and therefore undermine the stability of the project.

Figure 10: Responses to Question 9, “What makes a governance decision associated with this project legitimate or illegitimate?”

The earlier discussion showing the extent of for-profit participants' existence in this space – providing development work such as Dynamic Ledger Solutions in the case of Tezos or driving implementation of applications – may be surprising to some given the stated goal of decentralization for many projects. As with blockchain-based governance, a project’s interaction with legally recognized entities can also evolve over time given market conditions or project visions.

Progressive Decentralization

A final important dimension of blockchain governance is that it is not static. It is not uncommon for blockchain-based projects to launch with centralized governance by a small group in charge of stewarding the initiative and/or a core team responsible for building the initial product. But as these projects mature and adoption grows to encompass a broader stakeholder group and a larger user-base, they often choose to decentralize their governance in a process called progressive decentralization [25] or, sometimes, exit to community [26].

Decentralization, or the appearance of it, contributes to the continued use and adoption of blockchain-based systems by third parties. First, third parties may not wish to be involved with an ecosystem that presents the risk of evolving into a closed infrastructure or walled-garden, controlled and operated by a centralized authority with its own vested interests. Second, third parties need to have enough guarantees that the system will not evolve in a way that excessively differs from current expectations, with little or no backward compatibility, thereby jeopardizing the long-term viability of third-party applications that depend on the system. Third, a centralized governance structure that does not give enough voice to contributors might generate a feeling of exclusion, which might demotivate them from further contributing to the system.

Fourth, regulatory pressures and incentives sometimes directly favor decentralization.

Evaluating whether a project is successfully moving towards decentralization is notoriously difficult to quantify. Figure 9 shows an example of this using questionnaire results for three distinct governance processes: Which entities can make a governance proposal, whether there exists a non-binding community vote on proposals, and whether there exists a binding community vote on proposals. These three processes represent an increasing ability to impact the underlying function of a project: merely introducing a proposal for a project has the least impact on a project, while undertaking a binding vote on implementation has the most.

Figure 9: Responses that shed light on the degree of decentralization in the project. (Left) Most projects theoretically allow anyone to submit an (on-chain) proposal to be considered for execution. (Center) Most projects have a platform where the community can vote on non-binding proposals, or sentiment checks. (Right) Fewer projects have a system in place for binding community votes in the mold of a direct democracy. The left figure is sourced from responses to Question 10, “Who has power to introduce governance proposals, and how does that process operate?”, while the center and right items are sourced from responses to Question 15, “Are there systems for non-binding signals or binding votes on governance decisions? If so, please describe them in detail.”

There is a clear pattern of increasing governance centralization as the process becomes more important: While over 70% of projects do not restrict proposals to only appointed entities (76% of projects allow anyone, token holders, or node operators to submit a proposal), only slightly more than 50% of projects allow even non-binding community votes, and binding community votes exists at only 40% of the projects. It should be noted that while the ability to make a binding vote at the community level is clearly more decentralized than one that is only non-binding, a non-binding vote allows for clear and public signal of the community interests relative to those of any official entity. A board that is not willing to enact a proposal that shows popularity by the non-binding community vote risks bringing the project into disrepute, bringing into question how much deviation there may be between types once projects achieve a certain level of visibility.

For example, Ripple Labs, a private for-profit company, is responsible for development of the Ripple payment protocol and exchange network associated with XRP ledger. Created in 2012, the company was mainly funded through the sale of the XRP cryptocurrency to a series of retail and institutional investors. In 2020, Ripple established the XRP Foundation as an independent non-profit organization designed to support the improvement of the XRP ledger infrastructure and to steward the establishment of a solid and dynamic community of developers, maintainers and validators. The foundation received a substantial donation from a variety of platforms (i.e. Ripple, Coil, and Gatehub) that rely on the XRP ledger for their operations. The goal of the foundation is to expand the XRP user base beyond banks and other financial institutions and to steward consumer-facing applications and XRP usage.

This in turn is relevant to the regulatory determination about whether a token constitutes a security or investment contract in the efforts of an identifiable issuer. A senior official of the U.S. Securities and Exchange Commission stated in 2018 that, despite the presence of the Ethereum Foundation and the fund-raising efforts of the 2014 token sale, Ethereum at the time appeared to be “sufficiently decentralized” to avoid classification of Ether as a security [27]. By contrast, the SEC brought suit against Ripple Labs, its co-founder, and its CEO at the end of 2020, arguing they had engaged in an unregistered securities offering of XRP [28]. The litigation is ongoing as of this writing.

For some projects, the particular implementation of governance can result in a push to centralization that is not obvious without further examination. For example, while Cardano had an initial “vouchersale,” the distribution was strongly concentrated in Japan. Alternatively, some aspects while transparent can be sufficiently complex to potentially obfuscate the governance structure without close examination. For example, while the Dash Trust is a Delaware company, its shares are owned by a trust located in New Zealand, owned by 6 trust protectors elected through masternodes, ultimately administered by a professional trustee located in Switzerland.


Our novel questionnaire dataset allows us both to make high-level comparisons and to systematically drill down into the complex narrative understandings of project participants. We show a birds-eye structure of different governance arrangements; how representative projects address the major types of governance challenges in the blockchain context; and how major mechanisms employed for governance, both off-chain and on-chain, are viewed by project participants. We also quantify how elements of governance are perceived by participants of the projects in our sample, and when such views are shared across projects (financial incentives for token-based governance) or diverge (what makes a governance decision legitimate).

Our approach provides a useful resource not only for researchers and other external evaluators of blockchain projects, but for the projects themselves. Indeed, at least one recipient of the questionnaire determined that they would rethink their governance arrangements in order to address the questions we posed.

Future research could expand the dataset both in scope and time. There are now thousands of operational blockchain projects. A broader sample could allow for stronger generalizations about governance patterns. For example, if a large majority of the 100 most valuable blockchain networks, based on token market capitalization, could be surveyed, that might form a basis for additional conclusions about that market segment. In addition, surveying the same project multiple times could form the basis for a deeper understanding of blockchain governance evolution patterns. We did not vary the questionnaire instrument at all during the course of this research, so that the data allowed for “apples-to-apples” comparisons. There may, however, be improvements that could be made or additional questions asked that would shed light on important questions we cannot currently address. An investigation of how governance practices at the surveyed projects have changed since the questionnaire was originally administered may also shed valuable light on the evolution of operational blockchain governance.

Appendix A: Blockchain Governance Assessment Questionnaire

This document was developed by a group of experts convened by the Wharton Cryptogovernance Workshop. It seeks to provide a common framework for blockchain networks, applications, and consortia.


  • Submission date.

  • Your name and contact information (optional)?

  • Which project, network, platform, or consortium are you providing answers for? (The term “project” is used generically in the rest of this document.)

  • What is your role (or the role of your organization) in the project, if any?

Project Description

  1. What are the purposes, goals, or scope of the project? If there are metrics to measure success of the project, what are they?

  2. What, if any, are the coordinating entities, and what are their functions? (For example, a foundation, consortium, software development corporation, DAO, etc.)

  3. How are participants and users of the project identified? (For example, by public/private cryptographic keypair, wallet number, government ID, etc.) Are there restrictions on who can participate? If so, how are they implemented?

Stakeholder Groups

  1. Does the project’s software code delineate groups with particular functions? (For example, those who can propose changes, arbitrate disputes, or vote on behalf of others.) If so, please describe them and their operations in detail. (For example, their powers, how participants gain access, how the groups interact with the network and each other, and whether there are mechanisms to add, change, or exclude groups.)

  2. Are there other important groups either constituted informally, specified through contractual arrangements, or based on geography/choice of law? If so, please describe in detail. (For example, their powers, how participants gain access, how the groups interact with the network and each other, and whether there are mechanisms to add, change, or exclude groups.)

Goals and Implementation

  1. What behaviors does the project seek to encourage, or discourage? How are such behaviors incentivized? (For example, financial benefits/penalties, belief in shared values, costs of project failure, or costs of exiting.)

  2. (For operational projects): How well are incentives and governance mechanisms functioning in practice? Are there metrics to measure the effectiveness of governance?

  3. Are there systems to pay for infrastructure, protocol upgrades, development work, network enhancements and/or other work deemed to be in the interest of the network? If so, how do they operate?

Governance Powers

  1. What makes a governance decision associated with this project legitimate or illegitimate?

  2. Who has power to introduce governance proposals, and how does that process operate?

  3. Who has policy-setting (“legislative") power to decide on proposals, and how does that process operate?

  4. Who has implementation (“executive”) power to execute proposals once decided upon, and how does that process operate?

  5. Who has interpretive (“judicial”) power to resolve disputes over application of a policy to a specific instance, and how does that process operate? What can the interpretive power be used to mandate?

  6. What checks and balances, or systems of accountability, exist among these governance powers?

Governance Procedure

  1. Are there systems for non-binding signals or binding votes on governance decisions? If so, please describe them in detail.

  2. Are there distinctions between decisions made by ordinary processes (for example, majority votes) and those which require extraordinary processes (for example, supermajority votes)? Or are there non-standard processes you would, or have, used in emergency situations? Explain as appropriate.

  3. Are there aspects that can never be changed through governance processes, short of a contentious hard fork of the network? If so, how is that ensured?

  4. Are there mechanisms that make changing the project easier or harder?

  5. What revisions to governance mechanisms have been made, or are under consideration, and why?

Catch-All Question

  1. If there are any significant aspects of the project’s governance that you have not described, please provide details here.

Appendix B: Questionnaire Respondents

  1. 0x Protocol

  2. Algorand

  3. BanklessDAO

  4. Bitcoin

  5. Cardano

  6. Chronicled

  7. Compound

  8. Conflux Network

  9. Corda Network

  10. Dash

  11. Decred

  12. EOS Mainnet

  13. Ethereum

  14. Filecoin Project

  15. Horizen

  16. iov42

  17. MakerDAO

  18. Tezos

  19. Uniswap

  20. USD Coin (USDC)

  21. VeChain

  22. XRP Ledger

  23. Zcash

No comments here
Why not start the discussion?