Article

State of Crypto Governance: Part III - Governance of Layer 1 Networks

Humanode Core

06 Jun 2024 • 24 min read

After establishing the theoretical foundations of various governance perspectives related to blockchains and their ecosystems in the previous parts, we will explore several case studies of projects and approaches within this space. While it is not feasible to cover all aspects of governance for various blockchains comprehensively in this report, our discussion will focus on the most distinctive governance features of these projects. We will begin with a selection of layer 1 crypto networks and Decentralized Autonomous Organizations (DAOs), followed by layer 2 DAOs and DAO/dApp frameworks that facilitate easier composition.

Bitcoin – Layer 1 DAO

Bitcoin, also known as "A Peer-to-Peer Electronic Cash System," is recognized as the first Decentralized Autonomous Organization (DAO). It operates as a distributed network where peers with similar incentives provide a form of digital cash or digital gold that is resistant to censorship, without the need for central control or intermediaries.

The community adheres to a libertarian value system that prioritizes decentralization, heavily influenced by Austrian Economics. Social consensus supports a disinflationary monetary policy, which is considered sound money.

The separation of powers among developers, miners, and users prevents any single group from imposing decisions on the others unilaterally. Consequently, Bitcoin is a stable yet slow-evolving network.

Trustlessness is a key aspect, with the ethos being: 'Use Bitcoin without trusting anything but the open-source software you run.'

Nonetheless, software modifications are necessary, leading to the requirement for governance (led by humans) of the infrastructure.

Bitcoin governance involves managing the rules for transaction and block verification and achieving a shared understanding of what Bitcoin represents.

As a DAO, Bitcoin raises the complex issue of how a leaderless, autonomous organization is governed and adapts to a changing environment. Bitcoin's governance system functions, though not without its controversies, serving as a prototype for subsequent DAOs and inspiring various innovative designs that will be discussed in detail later.

The primary software used by Bitcoin nodes and miners, Bitcoin Core, is hosted on a GitHub repository controlled by a single entity, identifiable only by an email address and login credentials at https://bitcoin.org/.

Bitcoin.org itself is co-owned by pseudonymous GitHub users Cøbra, also known as Cobra-Bitcoin, and theymos. Originally, it was registered by Satoshi Nakamoto, the author of the Bitcoin whitepaper, using anonymousspeech.com according to theymos.

The independent Bitcoin Foundation, established by early developers and enthusiasts and based in Washington DC, along with the Bitcoin exchange Paxful, sponsors the site.

Nevertheless, it is important to note the disclaimer on the website: Bitcoin.org is not the official website of Bitcoin. Just as no one owns the technology behind email, no one owns the Bitcoin network. Therefore, no one can officially represent Bitcoin or speak on its behalf with authority.

Additionally, the site explains: 'Bitcoin is governed by all its users globally. While developers enhance the software, they cannot impose changes in the Bitcoin protocol as users are free to choose which software version to run. To maintain compatibility, all users must adhere to software that follows the same rules. Bitcoin functions effectively only with a complete consensus among all users. Thus, both users and developers are highly motivated to uphold this consensus.'

Technically, the maintainers of the Bitcoin GitHub repository are tasked with integrating new code into the main repository, but only after it has undergone extensive review and testing (handled by currently five developers, the latest of whom was chosen at an invite-only meeting of core developers and added to the maintainer list by existing ones).

This leads to several important consequences:

User influence on core development decisions is minimal beyond advocacy on social media. Nevertheless, the concept of a user-activated soft fork (by users operating full nodes) is often cited as evidence that users ultimately control the definition of Bitcoin.

Andreas Antonopoulos stated, 'Bitcoin conducts an election every 10 minutes—to determine the most difficult and valid chain, but it also involves nodes selecting which validation rules they support. This consensus involves five key groups: miners, developers, wallet providers, exchanges, and merchants. Think of it as a 4-of-5 multi-sig setup—if one tries to deviate from the consensus, they risk losing rewards.

The figure presented above illustrates the Bitcoin network in a state of equilibrium. A key point emphasized is the ultimate control users possess over the network. They exercise this control by choosing their mode of interaction with the network through various economic nodes. These include full nodes, as well as interfaces with the fiat financial system like exchanges, or with the marketplace through merchants, which are the points where Bitcoin's economic value is realized. Mining nodes, primarily motivated by profit, tend to follow where the economic value leads. This concept is further explored with examples such as the UASF (User Activated Soft Fork) and the influence of full nodes in shaping consensus.

Bitcoin Governance Process

The Bitcoin governance process, though not formally codified, operates as follows:

Proposals

Any individual, whether a protocol researcher or not, who identifies a potential improvement or solution, can share their proposal with the community. This sharing can take place via several platforms such as the bitcoin-dev mailing list, a white paper, or a Bitcoin Improvement Proposal (BIP). Notably, almost all soft forks in Bitcoin's history have proceeded through the BIP process.

Implementation

Proposals that receive positive peer review and community support are then coded into tangible changes by the proposer and their peers. These changes must be approved by the maintainers of the Bitcoin Core (which represents approximately 99% of nodes) to be merged into the main codebase. However, if a proposal is viewed as controversial or contentious, it often remains unresolved. While anyone can create a fork of the codebase to implement changes, these typically need significant backing to become viable alternatives, as seen with Bitcoin Cash (a hard fork). Certain changes, like SegWit, require a hard fork to implement.

Bitcoin generally opts for soft forks due to their compatibility with older versions of the software, contrasting with hard forks, which create completely new coins and are not backward compatible.

Deployment

Once modifications are made to the client software, it's crucial to persuade users to adopt the updated version. Nodes such as block explorers hold significant influence since many users rely on light clients and delegate validation responsibilities to these full nodes. In scenarios involving contentious hard forks, exchanges play a pivotal role as they determine which version of Bitcoin corresponds to the BTC ticker symbol, although their decisions are moderated by the actions of other exchanges.

MASF (Miner Activated Soft Fork)

Miners can signal their support for soft forks on-chain using their hash rate (utilizing BIP-9, which includes version bits with timeout and delay features). Miner support is continuously gauged, serving as an indirect measure of broader community consensus. A 95% signal threshold was established not as a voting mechanism but as a safety measure to prevent chain splits. It is intended to aid in coordinating the transition. While soft forks do not require immediate updates from all nodes, it's imperative for miners to adopt the new rules to avoid mining blocks that would be rejected by updated nodes.

However, this system allows a minority of the hash rate to veto an upgrade, affecting the entire network potentially. Given the somewhat centralized nature of mining, where a few pools dominate block creation, this can stifle updates. As mining becomes more decentralized, we might see even greater resistance to upgrades due to this inertia.

Historical and Alternative Activation Methods

Before adopting miner activation norms, Bitcoin used methods like flag date and block height activation, which rely on economically significant nodes, such as wallet providers, updating their software. This incentivizes miners to conform, as the newly installed client software will automatically transition to the new ruleset on a set date or block number. This approach is known as a UASF (User Activated Soft Fork). Importantly, non-mining full nodes play a crucial role in transaction validation and governance by randomly propagating valid blocks throughout the network, emphasizing their influence in the ecosystem.

User-Activated Soft Fork (UASF)

The example of a User-Activated Soft Fork (UASF) during the contentious debate over Segregated Witness (SegWit) and SegWit2x demonstrates a pivotal moment in Bitcoin's scaling discussions. SegWit, proposed in 2015, aimed to store signature data in a separate side chain to conserve space within the 1MB block limit, which would allow for more transactions and address issues of transaction malleability, although these technical details are outside the scope of this paper.

Under normal circumstances, the activation of SegWit (BIP-141) would require the signaling support of 95% of miners. However, a majority consensus among miners was not achieved, partly because it was argued that SegWit's increased capacity could lead to lower transaction fee revenues for miners. Moreover, SegWit was seen to diminish certain advantages for ASICs (Application-Specific Integrated Circuits), which are specialized pieces of mining hardware—particularly opposed by Bitmain, a leading ASIC manufacturer.

In response, a developer introduced BIP-148 in March 2017 on GitHub, marking it as a User-Activated Soft Fork to coerce miner support for SegWit. If unaddressed, BIP-148 would lead to the rejection of blocks mined by those not signaling support for SegWit, set to automatically activate on August 1st. Miners failing to signal for SegWit would face not just the loss of mining rewards but also wasted electricity costs, as their blocks would be disregarded by nodes enforcing the new rules.

At the Consensus 2017 conference, over fifty businesses within the blockchain space reached a compromise that would lower the SegWit activation threshold from 95% to 80%. In return, they agreed to work on a hard fork that would double the block size within six months, dubbed SegWit2x. This agreement came two months after the introduction of BIP-148 as a user-led initiative.

On June 14, 2017, Bitmain released a multi-language blog post titled “UAHF: A contingency plan against UASF (BIP148).” The UAHF (User-Activated Hard Fork), primarily advocated by Bitmain, a minority among users but significant in the mining sector, eventually led to the creation of Bitcoin Cash. Should BIP-148 be activated, Bitmain proposed to protect miners of non-SegWit blocks by initiating their hard fork.

Early in June 2017, James Hilliard introduced BIP-91 to reconcile BIP-148 and SegWit2x, allowing New York Agreement signatories a graceful compromise. By mid-July, this proposal gained enough community and mining support to activate the original Segregated Witness (BIP-141) with over 95% consensus.

Enforcement

The decentralized peer-to-peer network of fully validating nodes independently verifies that transactions adhere to agreed-upon rules and are included in valid blocks. Nodes will not propagate blocks that violate these rules. Miners, meanwhile, perform a "proof of publication" function with proof-of-work to order transactions, deciding which valid transactions are included in the blockchain. Most miners within a mining pool do not operate full nodes due to cost, relying instead on the pool operator for validation—a process that has become somewhat centralized.

Theoretical and Practical Implications of Decentralization

Ideally, each user would operate an "ideal full node" that accepts all protocol-compliant blocks and rejects all others. However, the practical effectiveness of this model depends on maintaining a large, diverse group of such nodes to prevent collusion. This scenario underscores the critical importance of maintaining a highly decentralized network in terms of both node count and demographic/geographic diversity.

Asymmetries in Incentives and Technological Progress

In Bitcoin governance, incentives are not perfectly aligned. Miners may advocate for changes that increase potential transaction fees, while developers focus on enhancements that sustain or increase Bitcoin’s value. Economic incentives for developers are minimal; new developers have little direct financial motivation to work on Bitcoin, leading many to start new projects or create their own tokens. This situation has resulted in a cycle of increasing power concentration among a small group of early core developers, slow technological progress, and a conservative approach. However, this conservative stance and the simplicity relative to smart contract platforms are often lauded for maintaining high security standards in Bitcoin.

Comparison with Other Blockchain Projects:

Other blockchain initiatives, particularly those incorporating on-chain governance, aim to create systems that are more dynamic and responsive to changes, contrasting with Bitcoin's more static model.

Ethereum – Layer 1 DAO

Ethereum uses a structured process for updating its protocol, centered around the Ethereum Improvement Proposal (EIP). Here's how it works:

Proposal Creation: Developers or teams within the Ethereum community draft EIPs.

Community Debate: The wider Ethereum community discusses these proposals extensively. The proposals might be revised and debated several times until there is a general agreement among the most engaged community members.

Coding and Testing: Once a proposal is agreed upon, developers write the necessary code. This new code is then audited for security and tested on Ethereum's test network (testnet) to ensure it works correctly without risking the main network.

Implementation: After successful testing, the update is added to Ethereum’s software, available in the public code repository. It is then up to the individual node operators in the Ethereum network to decide to update their systems with this new version.

Activation: The changes proposed in the EIP are only considered a part of Ethereum once enough nodes have adopted and are running the updated software.

This method ensures that upgrades are thoroughly vetted and supported by the community before they are implemented.

Vitalik Buterin, the creator of Ethereum, remains a pivotal figure in its governance due to his respected status within the community. However, he and the foundation are consciously working to decentralize authority to prevent any single points of failure and ensure a more distributed influence. Buterin advocates for a conservative approach to the development of Ethereum's base layer (L1), emphasizing stability and reliability over agility and rapid innovation.

Ethereum's development increasingly mirrors the open-source "bazaar" model, characterized by radical transparency and high community engagement. This openness draws a significant number of community members and experts to actively tackle key research and development challenges. The community communicates frequently through the foundation, involves 62 contributors to the Eth2 specification, supports 9 independent client implementations, and engages in discussions on platforms like ethresear.ch. All development calls are open and live-streamed.

Community norms and precedents, established during critical events like the DAO hack, guide collective actions, although debates continue to address differing viewpoints. The technical roadmap and established governance processes now carry substantial legitimacy, making any deviation from the set path challenging.

Moreover, Ethereum governance is shaped by the interactions among diverse stakeholder groups, discussion platforms, and procedural frameworks.

Stakeholder Groups in Ethereum

Formal Stakeholders:

Ethereum Foundation: Manages the proceeds from token sales and allocates grants, also overseeing the core go-ethereum GitHub repository.
ConsenSys: A dapp development studio established by Ethereum co-founder Joe Lubin.
Parity (formerly Eth-core): Founded by Gavin Wood, the author of Ethereum's technical yellow paper.
Infrastructure Providers: Includes services like Infura, Metamask, and MyCrypto, which offer querying services and user interfaces. These platforms are crucial as they represent significant nodes through which many users interact with the blockchain.

Informal Stakeholders

Core Developers: Mainly those working on client software like geth from the Ethereum Foundation and Parity.
Fellowship of Ethereum Magicians: A technical council open to all participants, focusing on the technical aspects of Ethereum.
Cat Herders: A project management team created in 2019 to assist in administrative and coordination tasks.
EIP Editors: A group of five who oversee the formal correctness of Ethereum Improvement Proposals (EIPs), without making judgments about the content.
Application Developers: Teams incentivized through ETH (often via ERC20 tokens) play a significant role in protocol governance, more so than miners and VC-backed startups typically do in Bitcoin.
Miners/Validators: Those who are responsible for confirming transactions and maintaining the blockchain.
Investors: Individuals or entities that provide capital with the expectation of future financial returns.
Informational Resources: Ethhub and Ethresearch serve as key websites and forums for Ethereum-related information.
The Wider Community: Encompasses all other participants and stakeholders in the Ethereum ecosystem, including users and enthusiasts.

Processes and Mechanisms

Many in the Ethereum community are wary of formalizing processes, fearing that such structures might become targets for manipulation or corruption, such as hostile takeovers or the exploitation of inevitable gaps in any contract, where not all circumstances can be anticipated.

The EIP Process

One of the more formalized aspects of governance is the process for Ethereum Improvement Proposals (EIPs), outlined in EIP-1. This process is connected to ongoing discussions about the sources of legitimacy in Ethereum governance. Some community members believe that core developers derive legitimacy from their participation in the EIP process, which is open to all and follows established rules. Though the debate is not settled, another point often made in favor of the EIP process's legitimacy is its widespread use and the successful precedent set by similar processes in other projects.

Ethereum Improvement Proposals (EIPs)

EIPs function similarly to Bitcoin Improvement Proposals (BIPs), which themselves were inspired by Python Improvement Proposals. An EIP should provide a clear technical specification of the feature and the rationale behind it. The author is tasked with building consensus within the community and documenting any opposing views.

Source: Consensys

Decred Layer 1 DAO

Decred is a digital currency with a hybrid consensus mechanism, designed to be self-governing where stakeholders vote on rules and project decisions in proportion to their stake.

On-Chain and Off-Chain Voting

On-chain voting involves validating blocks and changes to consensus rules. Off-chain voting focuses on proposals made through Politeia, a specific governance platform. The proof-of-stake (PoS) system operates alongside proof-of-work (PoW) mining, making attacks costly relative to the project's market cap and reducing the risk of PoW miner collusion. PoS participants also safeguard the network against unwanted forks, majority attacks, and behaviors like mining empty blocks. The token issuance is allocated as 30% to stakers, 60% to miners, and 10% to a community fund. This distribution model addresses the criticism often directed at pure PoS systems, where wealth concentration can lead to disproportionate power ("the rich get richer").

Ticket-Holder Voting

Each ticket grants the holder one vote, usable for approving or rejecting proposed consensus changes and Politeia proposals. To obtain tickets, DCR holders must lock their funds for an average of 28 days, ensuring commitment and complicating the planning of attacks due to the random duration of lock-ups, which can extend up to 128 days. Purchasing tickets in bulk to influence decisions increases both ticket and Decred prices, which offers additional protection against hostile takeovers.

On-Chain Protocol Upgrade Process

The upgrade process begins with a Decred Change Proposal (DCP), similar to Bitcoin's BIPs. Developers then release new software incorporating these changes. Both PoW miners and PoS participants must upgrade their software. Voting starts once specific thresholds are met. An upgrade requires the support of 75% of all non-abstaining votes to be locked in. After approval, the rest of the network has about four weeks to update their nodes before the upgrade is implemented.

Politeia – Off-Chain Proposal System with On-Chain Anchoring

Politeia is Decred’s off-chain proposal system that utilizes on-chain anchoring to prevent opaque censorship, allowing proposers to verify the timestamp of their submissions. While moderators remove spam, these actions can be cryptographically validated post-removal. This system enables ticket holders to vote on work proposals from community members aiming to expand the network. Anyone can submit a funding proposal to be voted on by stakeholders. Currently, 10% of block rewards fund a treasury, which is expected to soon transition to DAO control. Presently, the treasury is managed centrally by Decred Holdings Group LLC, which holds the keys to the multi-sig treasury address.

Implementation of Proposals

Once approved through the Decred Contractor Clearance Process, contractors can submit monthly invoices for their work, reviewed by treasury auditors. The transition of treasury control to the stakeholders is planned via the Decred Autonomous Entity (DAE), which will be renamed to DAO to align with broader cryptocurrency terminology. This change avoids association with the infamous Ethereum TheDAO hack.

Is Decred’s Governance Considered Plutocratic?

Decred’s token-weighted governance system has sparked discussions about its plutocratic nature, potentially allowing wealthy stakeholders disproportionate influence. Decred developer Luke Powell clarifies that Decred’s aim is not to govern society but to function as a global store of value. He argues that labeling a cryptocurrency network as a plutocracy implies an incorrect view of such platforms as societal governance systems, rather than mechanisms for coordinating digital commodities.

Governance Context and Implications

The framing of governance within Decred, as explained by Tezos in a comparison, suggests that "corporate governance" is a more apt analogy than "national governance." This perspective is crucial in evaluating the appropriateness of a governance system. However, if a system, while autonomous, impacts external parties negatively (e.g., through carbon emissions from PoW), defending such governance in isolation becomes challenging without considering a higher-level, democratically legitimized governance framework.

Tezos – Layer 1 DAO

Tezos is a blockchain that can update itself without needing to split into different paths (hard forks). It uses a system where all token holders can participate thanks to its proof-of-stake consensus mechanism. This mechanism allows for smart contracts that are formally verified for security and correctness.

On Tezos, there's an established process on the blockchain itself for making changes to the protocol. This process includes proposing upgrades, selecting which proposals to move forward, testing them, and finally implementing them seamlessly. The Tezos team views their governance model as more akin to how a corporation is managed rather than a democratic system, focusing on structured, hierarchical decision-making.

Proposal Mechanism

Tezos uses a unique proposal process where participants, known as "bakers," vote on protocol upgrades. Bakers need to hold "rolls," with one roll equivalent to 8,000 Tezos tokens—a change from the original 10,000 required before the Athens upgrade. These bakers are motivated to participate actively in governance to maximize their rewards and influence.

The proposal process follows several stages:

Proposal Period: Each baker can submit up to 20 proposals. To manage the volume, only elected bakers can propose, and other community members can encourage a baker to propose on their behalf. Bakers then vote on these proposals, and the most supported proposal moves to the next stage.
Exploration Vote Period: Votes are counted based on the number of rolls each baker holds. A proposal needs to meet a dynamic quorum—adjusted by past participation rates—and secure an 80% supermajority to advance.
Testing Period: Once a proposal passes the exploration vote with the required supermajority, it enters a 48-hour testing phase on the main network, intended to avoid confusion. Because this period is short, more extensive testing usually continues on a separate testnet.
Promotion Vote Period: After thorough testing, bakers vote again, weighted by their rolls. If the proposal achieves the minimum quorum and another 80% supermajority, it is implemented as the new main-chain protocol. If it fails, adjustments are made to the quorum for future proposals based on a specific formula, and the cycle starts anew.

This structured approach ensures regular updates and incorporates bakers' feedback directly into the governance process, aligning their interests with the network's evolution.

Source: https://medium.com/tezos/amending-tezos-b77949d97e1e

Dash – Layer 1 DAO

In Dash, governance decisions are made by a Decentralized Autonomous Organization (DAO) composed of masternodes. Each masternode gets one vote (yes, no, or abstain) on each proposal. If a proposal is approved, it can be implemented by Dash’s developers. For example, in early 2016, Dash’s Core Team proposed increasing the block size to 2 MB, and the masternodes reached a consensus to approve this change within 24 hours. This contrasts sharply with Bitcoin, where prolonged debates over block size have led to community divisions and blockchain forks.

The DAO also allows Dash to fund its development independently. Unlike other projects that rely on donations or premined funds, Dash allocates 20% of each block subsidy to finance its own growth. When a block is mined, 80% of the subsidy is shared between the miner and a masternode, while the remaining 20% accumulates over the month. During this time, anyone can submit a budget proposal. If a proposal gains net approval from at least 10% of the masternode network, it is funded at the end of the month through a "superblock" using the reserved 20% of block subsidies. This system enables Dash to self-finance by earmarking a portion of block rewards for approved projects.

Proposals and Contractors

Contractors on the blockchain can include developers, outreach professionals, team leaders, attorneys, or others appointed for specific tasks. Proposals usually start as preliminary posts on the Dash Forum to gather community feedback and suggestions. Suppose the proposer believes the proposal has a good chance of success. In that case, they formally submit it on the blockchain as a governance object, accompanied by a 1 DASH fee to deter spam and ensure only serious proposals are considered.

Masternode operators have several tools available to help them review and vote on these proposals. For a proposal to be approved, the number of 'yes' votes must exceed 10% of the total masternode count when the votes are counted. If the funding requests from successful proposals exceed the available block subsidy, those with the highest number of 'yes' votes are funded first, leaving less popular proposals unfunded. This voting and funding process repeats monthly, with the total amount of Dash available for proposals decreasing by about 7.14% each year, in line with the reduction in the overall block subsidy.

Is Dash's governance effective?

Dash introduced a unique self-funding model that divides block rewards among three key groups: masternodes, miners, and a treasury. Both masternodes and miners receive 40% of the rewards. The remaining 20% goes to the treasury, which funds future development projects for Dash. Masternodes also have a critical role in determining the direction of Dash's development, as their votes decide which projects get funded and which directions to pursue.

Cosmos – Layer 1 DAO

Cosmos is a Layer 1 Decentralized Autonomous Organization (DAO) that consists of a network of independent, scalable, and interoperable blockchains. Each blockchain within Cosmos is required to set up its own network of validators and has the autonomy to govern itself. The central component of this network, known as the Cosmos Hub, is built using the Cosmos Software Development Kit (SDK). The Hub facilitates token transfers and aims to enable the exchange of arbitrary messages between these independent chains, referred to as "zones." This structure is designed to strike a balance between allowing blockchains to operate independently while still enabling them to communicate and collaborate, simplifying complex interactions, and fostering cooperation among the various blockchain communities within Cosmos.

Cosmos Hub Governance

In the Cosmos network, anyone can submit a proposal, but it requires a minimum deposit to move into the voting phase, where Atom holders (the native token of the Cosmos Hub) can vote.

Deposit Period

A proposal must gather at least 512 Atoms as a deposit within two weeks to be considered for voting. This deposit serves as spam protection. Anyone can contribute to this deposit. If the proposal is successful or fails to move to the voting phase, the deposit is returned. However, if the proposal enters the voting phase and then fails, the deposit is transferred to a community fund.

Voting Period

Atom holders have two weeks to vote on proposals using their staked (bonded) tokens. The voting options are "Yes," "No," "No with Veto," or "Abstain." Validators who have tokens delegated to them can vote on behalf of their delegators, although delegators have the option to vote independently in a manner similar to liquid democracy.

Tallying Results

For a proposal to pass, it must meet these criteria:

Quorum: At least 40% of the total staked tokens must participate in the vote.
Simple Majority: More than 50% of the voting tokens (excluding those that abstained) must be "Yes" votes.
Veto: Less than 33.4% of the voting tokens (excluding those that abstained) can be "No with Veto" votes.

Implementing the Proposal

Once a proposal has passed the voting phase, it must be implemented by the validators.

Polkadot - Layer 1 DAO

Polkadot enhances the way blockchain networks collaborate by providing shared security and enabling interoperability. It uses on-chain governance to update protocol rules without needing hard forks, by modifying runtime modules that define how the network processes transactions. This system applies to both relay chains and parachains.

Relay chains are the main network structure that enables different parachains—parallel-running blockchains—to interact with each other. These parachains can execute specific functions and communicate with other parachains based on their unique runtime modules.

Unlike Cosmos, another blockchain protocol known for its approach to interoperability, Polkadot’s governance can directly influence parachains, for example, by removing a parachain if it’s deemed malicious. However, each parachain can have its own independent governance and economy. Typically, the governance of the relay chain focuses on maintaining the overall protocol rather than managing the specific details of individual parachains.

If a parachain is harmful, the relay chain governance has the authority to remove it. Conversely, if a beneficial parachain cannot afford a slot within the relay chain ecosystem—since securing a slot requires bonding tokens—the governance can choose to grant it one.

Referendum Process

A referendum is a type of proposal in Polkadot's system that can alter the entire protocol's code through a privileged function call in the runtime. This process can change the protocol significantly, usually requiring a hard fork in other blockchain systems.

In Polkadot, all protocol changes must be approved through a stake-weighted referendum. A majority of the network's stake, often a 2/3 majority, is required to enact changes. Stake is determined by the amount of tokens held, multiplied by the length of time they are locked. This system allows smaller stakeholders with a long-term commitment to have a greater influence compared to larger stakeholders who may not want to lock their tokens for extended periods.

An enactment delay is included to allow stakeholders who strongly disagree with a proposal to exit by selling their stake before the change takes effect. The stakes of those who voted in favor are locked for at least the duration of this delay.

There are four main ways to submit proposals:

Publicly Submitted Proposal: Any token holder can propose changes and stake tokens on these proposals. Others can also stake tokens, and the proposals with the most stake are voted on at regular intervals.
Council-Submitted Proposals: Similar to a corporate board of directors, the council consists of stakeholder delegates. Council members, elected by approval voting for a 12-month term, can submit proposals either through a majority without any vetoes or unanimously. The council can also cancel a referendum in uncontroversial, last-resort situations, such as discovering a bug late in the upgrade cycle.
Proposals Following a Prior Referendum: These are proposals made as part of enacting changes approved in a previous referendum.
Emergency Proposals by the Technical Committee: Addressing urgent issues, these proposals are submitted by the Technical Committee and must be approved by the council. The Technical Committee is made up of teams that have successfully developed or specified the Polkadot runtime or its environment. Emergency proposals have a shorter enactment delay and can be added or removed by a simple majority vote of the council.

Adaptive Quorum Biasing

Adaptive Quorum Biasing adjusts the required majority for a proposal to pass based on how the proposal was initiated and the voter turnout (measured by stake):

Public Referendum: This requires a positive turnout bias. A supermajority is needed to accept a proposal, but as more stakeholders participate, the required majority decreases until it approaches a simple majority.
Council with Unanimous Support: This involves a negative turnout bias. A supermajority is necessary to reject a proposal, and as participation increases, the required majority to reject it decreases towards a simple majority.
Council with Majority Support: A simple majority is sufficient to accept a proposal.

Spontaneous Subject Committees

To quickly gauge stakeholder sentiment, spontaneous subject committees use random sampling of the stake-weighted voting population. This method aims to determine approval or rejection confidently and swiftly, allowing proposals to be fast-tracked or dropped based on the committee's findings. This process helps manage the flow of proposals, especially when dealing with less contentious issues, by freeing up resources for more debated matters. Voters in these committees are compensated, considering their turnout in decision-making.

Challenges and Risks

Communities managing blockchain infrastructure have experimented with various governance systems, ranging from informal to formal and from loosely coupled off-chain processes to tightly integrated on-chain systems. Voting is a crucial method for understanding community sentiment and consolidating individual preferences into a collective decision. The key issues in blockchain governance include:

Eligibility to Vote: Typically, in permissionless blockchain systems, the right to vote is primarily held by token holders, as achieving a fair "one-person-one-vote" system is challenging without a proper decentralized identity management system or a centralized KYC (Know Your Customer) processes or it being vulnerable to sybil attacks.
Coupling of Voting Results to Protocol Changes: A significant consideration is how directly voting outcomes influence protocol changes. There's a strong debate about the default behavior of client software in full nodes, which play a critical role in enforcing consensus rules, as seen with the User-Activated Soft Fork (UASF).

To prevent Sybil attacks considerations are being implemented:

A system where every stakeholder proves that they are a unique individual.
Stakeholder’s interest in the ecosystem remains intact. This could be achieved by incentivizing the decision-making process.

There's also discussion about whether stakeholders should be required to opt-in to accept new rules or need to opt-out to reject them. Opting in tends to favor changes because of the coordination around the proposed change, acting as a strong focal point. However, this setup means that non-mining full nodes or users running full nodes without significant token holdings lack a robust mechanism to influence decisions about upgrades like token holders can.

Requiring full nodes to actively opt-in to protocol changes can serve as a vital counterbalance, ensuring a broader representation of stakeholders. This approach, however, may favor maintaining the status quo, potentially leading to stagnation. On the other hand, tightly coupled on-chain voting compels nodes to implement changes as decided by token holders, unless they choose to opt-out and potentially fork, which can be challenging to coordinate.

Conclusion

As the blockchain landscape continues to evolve, the governance models of Layer 1 Decentralized Autonomous Organizations (DAOs) such as Bitcoin, Ethereum, Tezos, Polkadot, Cosmos, and Dash play crucial roles in their ecosystems' stability, adaptability, and success. Each system, with its unique approach to governance, illustrates the challenges and complexities of managing decentralized networks. From Bitcoin's conservative, miner-dependent model to Ethereum's influential core developers, and from Tezos's on-chain governance to Polkadot's sophisticated multi-stage consensus mechanism, the governance models shape how decisions are made and how responsive these platforms are to the needs of their users.

Most Layer 1 blockchains adopt a more flexible and experimental governance approach than Bitcoin's conservative model. Many projects, especially those built on Ethereum, use on-chain governance that allows token holders to vote directly on proposals. This can include innovative methods like liquid democracy, Decentralized Autonomous Organizations (DAOs), and quadratic voting, making decision-making more inclusive and dynamic.

In contrast, Bitcoin’s governance model is deliberately slow and change-resistant, prioritizing stability and security. Decisions are made off-chain by a consensus among developers and miners, a system that preserves Bitcoin’s foundational principles and its role as a digital store of value.

Blockchain governance typically addresses a broader array of issues such as protocol upgrades, community projects, and venture funding through treasury management. This contrasts with Bitcoin governance, which focuses mainly on network security and protocol stability. These differing approaches reflect the distinct goals of each ecosystem: Bitcoin aspires to be a decentralized, censorship-resistant 'digital gold.' At the same time, Web3 aims to build a fully decentralized internet of value and services.

The risks and challenges associated with these governance models—such as ensuring broad participation, maintaining transparency, and managing the centralization of power—highlight the need for continuous innovation and adaptation. These challenges also underscore the importance of designing governance systems that not only address current technological and community needs but are also flexible enough to adapt to future demands.

As blockchain technology matures, the effectiveness of its governance will largely determine its long-term viability and success. Thus, the exploration of these governance models provides valuable insights into the strengths and limitations of decentralized decision-making processes. For stakeholders in these networks, understanding these governance models is essential for participating effectively and shaping the future direction of these technologies.