Blockchain governance: takeaways from nine projects

This post examines what blockchain governance is, elaborates on its importance, describes the governance model of seven Blockchain projects (Cosmos, DFINITY, Qtum, Decred, Tezos, aeternity, Dash, Bitcoin, and Ethereum) and concludes with resulting takeaways.

What is governance

Governance refers to all actions such as decision-making processes that are involved in creating, updating, and abandoning formal and informal rules of a system. These rules can be code (e.g. smart contracts), laws (e.g. fees for malign actors), processes (what must be done when X happens), or responsibilities (who must do what).

In the Blockchain space, there are three broad types of such rules which translate to different areas where blockchain governance is needed; blockchain or network governance, project governance, and fund governance.

Blockchain or network governance

Blockchain or network governance is needed to achieve network mining consensus through special algorithms. Typical algorithms are Proof-of-Work (PoW), Proof-of-Stake (PoS) and a hybrid of these.

Funding governance

Funding governance regulates how projects manage collected funds. Among other things funding governance defines:

• Funding source: Defines the funds’ source, i.e. where do funds come from (e.g. a cut of mining rewards)
• Funding amount: Defines how much funds are collected (e.g. 10% of all mining rewards)
• Funds Administrator: Defines who collects, spends, and keeps the funds
• Fund usages: Defines what should be done with the funds
• Reporting process: Defines how the fund usage should be communicated to the outside (e.g. through quarterly financial statements)

See Decred’s Funding governance for an example of Funding Governance

Project governance

Project governance deals with all topics related to the technology (i.e. the code), blockchain/network governance, funding governance, and meta-governance (i.e. changing the governance process itself). Technology-related topics include, among other things, blockchain parameters (e.g. changing block size or gas prices), fixing bugs, or adding new features.

Governance as a mean to achieve efficient change

The biggest motivation behind Blockchain governance is the goal of efficient change. In other words, the ability to fix issues as fast as possible and change where change is needed. These issues can be of all kinds. Among other things, it includes changes to blockchain parameters (e.g. block size) but also the recovery of lost coins due to hacks.

Having said that, there are several reasons underlying the goal of efficient change.

Quick updates enable enterprise and mass market end-user use cases

Governance is especially needed in blockchains with enterprise or end-user use cases. If it takes too long to fix an issue, people will abandon the service or won’t participate in the first place. Furthermore, changes can divide the community and lead to even more uncertainty and hesitation to participate.

Conceptually, this is where centralized applications are advantageous; although they are decentralized within (different hierarchies and decision makers in a centralized corporation), they act as a centralized entity with a defined chain of command and common goals. The CEO can make very quick decisions and has the final word; what she decides must be followed. This stands in sharp contrast to the blockchain space where decision making is decentralized, people will depart if they dislike the decisions and different agents (users, miners, developers) have different goals and incentives. For instance, Monero’s update to become ASIC-resistant, developers where happy, but ASIC miners, seeing their profits shrink, less so. Furthermore, the hard fork that followed resulted in four different versions of Monero, essentially splitting the community.

Blockchain governance mitigates indirect dependence on incumbents

Companies such as Facebook, Amazon, Netflix and Google(FANG) determine their rules*. This includes also publicly criticized things such as the use of personal date. The argument is that nobody must use FANG if they disagree with their approaches. Whereas that is true in theory, in reality abandoning those services is cumbersome due to their power and thus dependence on them. As I have argued in “Bitcoin, Blockchain, and Cryptoassets: discussing bubbles vs. discussing socio-technical systems“ Facebook and Co. are more than just an app, they are systems that are deeply integrated into our social and business lives. For instance, whereas one must not use Google for advertising or Facebook for communication, there are little solid alternatives left. As a consequence, people are indirectly obliged to use them.

Publicly accessible and governable Blockchains could mitigate that indirect dependence. Everybody who is interested in how those systems are set up, could purchase the respective tokens and suggest changes including changes in regards to how personal data is handled.

Governance as a competitive advantage

Given the fact that most Blockchain projects are open source, copying them is trivial. Thus, the biggest competitive advantages for blockchain projects stem from the community’s size and speed of adaption. The more supporters a project have and the quicker the developers can react to issues and competitors, the greater the chances of survival.

Whereas governance model cannot prevent the above-mentioned problems from occurring, they can drastically speed up solving them.

Generally speaking, there are two approaches towards blockchain governance; on-chain and off-chain.

On-chain governance Cosmos Network, DFINITY, Qtum, and Tezos

The following section looks at the governance model of Cosmos, DFINITY, Qtum, Decred, Tezos, Bitcoin, Ethereum, in more detail. Furthermore it provides a consolidated list of takeaways

Governance models takeaways

• In cross-chain projects, multiple governance models can be used (see Cosmos).
• Malign changes are inevitable. Thus, having a roll-back process in place is crucial
• A blockchain’s own token is very useful in incentivizing good behavior, although not a perfect solution (e.g. shorting the market is still possible)
• Liquid democracy can prevent voting centralization but still includes many voters (e. g. DFINITY)
• Governance models can be improved through algorithmic decisions (e. g. DFINITY)
• An expensive proposal process can hinder innovation because proposals are avoided due to high costs. Finding the right balance between preventing spam and hindering innovation remains experimental.
• Validating the identity of submitting entities and their proposals remains cumbersome and expensive. The irony is that Blockchain is supposed to remove exactly this counterparty risk. (see DFINITY)
• Categorizing proposals (e.g economics, or policy) is helpful for refining the governance process (see DFINITY)
• Hard and soft forks are unavoidable but they must not be used for all changes
• Requirement-based governance (approving proposals only if specific actors — e.g. stakers or developers — have voted) is useful for refining the governance model (see Qtum)
• Governance models can range from zero to full automation and have all kinds of variations in between (see Qtum)
• The design of governance models must account for voting thresholds and define how many votes are required to achieve a change. (e.g. Tezos)
• Governance models can start as off-chain and move on-chain over time
• Off-chain governance model can be complex (but not necessarily complicated) (e.g. Decred)
• Transparency in regards to governance rules (e.g. application requirements) and outcomes is crucial for off-chain governance (see Decred)
• Meta-governance, i.e. how to govern or change the rules that make up the actual governance matters (e.g. Decred)

Cosmos: individual governance for each blockchain in cross-chain projects

Cosmos is a blockchain network in which multiple independent blockchains can be connected to each other. Those blockchains connected to the Cosmos network are called zones. Each such zone has its own governance and within these zones validators and delegators (see below) vote on proposals. These proposals can be blockchain parameters (e.g. block size) and adaptions to Cosmos’ constitution, among other things. Similar to DFINITY (see below), Cosmos supports roll-backs.

• Validators: Validators are nodes with positive voting power that can vote for agreement on the next block.
• Delegators: Delegators are indirect validators. Analogous to a liquid democracy (or delegative democracy) delegators transfer their tokens and thus voting power to validators. Those validators then vote with their own tokens and the tokens lent to them. Delegators can withdraw their tokens from validators at any time. This is similar to DFINITY’s automatic voting (see below).

Takeaway: In cross-chain projects, multiple governance models can be used.

Open questions

• Cross-chain governance: How will cross-chain governance be regulated?
• Coordination costs of multiple governance models in cross-chain settings: Will one governance model across multiple blockchains in a cross-chain setting make the whole system more or less efficient and would rather a unified governance model suffice?

DFINITY: Governance through the Blockchain Nervous System (BNS)

DFINITY is a Blockchain that distinguishes itself, among other things, by having algorithmic governance. DFINITY’s tokens are called dfinities.

Essential to DFINITY’s blockchain is its so-called Blockchain Nervous System (BNS). In order to implement a change in DFINITY, each proposed change must go through four steps.

1. Proposal submission
2. Voting
3. Proposal evaluation​
4. Proposal implementation

Proposal submission

Proposals, which fall into different categories such as „Economics“, „Policy“, or „Protocol“ are submitted by paying a submission fee. If the proposal is adopted, this submission fee is returned. This fee should prevent spam and encourage high-quality proposals.

Voting

In DFINITY Neurons (entities that have voting power; see below) vote on the submitted proposals.

DFINITY’s Neurons

In DFINIY Neurons are voting entities and are run by people using a dedicated software. Everybody can create a neuron by making a financial deposit using dfinities. This deposit regulates the neuron’s voting power. The higher the deposit, the more voting power the neuron has. Deposits can be withdrawn after a minimum of three months (duration is possibly subject to change). Deposits should incentivize good decision making; bad decisions carried out by the BNS might lead to bad network performance, in turn lowering the tokens’ value and thus the deposit’s value. Moreover, deposits are used to calculate reward. Neurons that vote are rewarded dfinities. The reward height is proportional to the deposit; the higher the deposit the higher the reward.

Neurons can vote manually or automatically.

Manual voting by manually issuing votes
The user running the neuron software can vote on proposals. For voting, she may choose between „Adopt”, „Reject”, and “Pass”. The significance of the user’s vote depends on the neuron’s deposit.

Automatic voting by following other neurons
Automatic voting is similar to liquid democracy. In this scenario, the users’ neurons copy the decisions made by other neurons. Users can configure a “follow list” for which proposal type (e.g economics, policy, or protocol) to follow which neuron’s vote. The rationale behind this delegation is that users lack expertise in certain areas and therefore give their vote to users of whom they believe that they have the right expertise. For instance, a user decides that she doesn’t want to vote on economics-related proposals because she lacks the right knowledge. Therefore, she gives her voting power to a user of whom she believes will make the right economics related decisions. In each automatic voting decision the algorithm follows the vote of the most powerful neuron in a cascading matter. That means that if the most powerful neuron from the user’s follow list has not voted, the vote of the next neuron will be copied and so on.

Proposal evaluation

In this evaluation stage, the proposal’s issues and solutions are evaluated. DFINITY has implemented three steps for this evaluation:

1. Establishing legitimacy: Here the involved entities conduct a background check to ensure that the proposal and the originator of the proposal are legitimate. This step is cumbersome, very manual, and can even include live phone contact.
2. Problem evaluation: In this step it is validated whether the issue identified in the proposal is really a problem.
3. Solution evaluation: Finally, the proposed solution’s code is evaluated. The code is checked to ensure that it will fix the problem and that it won’t affect other parts of the system.

In all of these three steps the parties doing the research are rewarded by DFINITY’s BNS. This reward, however, must be paid by the entities submitting the proposal. The whole process can be expensive.

Proposal implementation

For implementation, DFINITY’s Blockchain Nervous System distinguishes between two different proposal types, namely active and passive ones.

• Passive proposal: A passive proposal equals changing the telemetry of the system (e.g. mining reward). In this case, the new information is updated on the BNS smart contract. This is similar to Qtum’s Decentralized Governance Protocol (see below).
• Active proposals: Here DFINITY’s BNS changes things outside its own smart contract. For such amendments, special code is required which DFINITY has added to the EVM (Ethereum Virtual Machine). One example for active proposals is the termination of certain malign smart contracts.

Built-in versioning system

One rationale behind the deposits required to create neurons is to mitigate malign behavior. If a participant votes for malign proposals and these proposals are implemented, the network will suffer. In turn, the dfinities and thus the malign actor’s dfinities suffer. (this incentivisation doesn’t, however, account for malign actors trying to short the market). Nevertheless, bad proposals that harm the network in a substantial way might get implemented (knowingly or not) anyway. To mitigate fatal changes, DFINITY has integrated a versioning system. With this versioning system users can reverse malign changes through hard forks. Furthermore, neurons that voted for that malign proposal are terminated during this fork.

Takeaways

• Malign changes are inevitable. Thus, having a roll-back process in place is crucial
• A blockchain’s own token is very useful in incentivizing good behavior, although not a perfect solution (e.g. shorting the market is still possible)​
• Liquid democracy can prevent voting centralization but still includes many voters
• Governance models can be improved through algorithmic decisions
• An expensive proposal process can hinder innovation because proposals are avoided due to high costs. Finding the right balance between preventing spam and hindering innovation remains experimental.
• Validating the identity of submitting entities and their proposals remains cumbersome and expensive. The irony is that Blockchain is supposed to remove exactly this counterparty risk.
• Categorizing proposals (e.g economics, or policy) is helpful for refining the governance process

Qtum: hybrid governance and wide automation governance spectrum

Qtum, a Blockchain focused on enterprise use case, takes a hybrid approach towards Blockchain-governance consisting of hard or soft forks and the so-called Decentralized Governance Protocol (DGP).

Qtum’s blockchain governance model

Hard/soft forks, hotfixes or both

Qtum uses hard and soft forks — as many other projects — for new features and significant changes. In addition to hard and soft forks, Qtum has developed the so-called Decentralized Governance Protocol (DGP) to fix specific blockchain parameters (e.g. block size or gas prices). Deploying hotfixes instead of more complicated hard or soft forks entails a couple advantages. Most notably, hotfixes do not disrupt the user experience; agents (stakers, node operators, users) do not need to download new software or intervene in any other way. However, in certain instances both types might be used. For instance, in the case of problematic gas prices for certain operations (higher prices for processing blocks than creating them — this scenario can be used to attack the network) DGP will temporarily increase the prices for the problematic operations to mitigate malign attacks on the network. A fork will then fix the operation’s underlying problem.

Process of Qtum’s Decentralized Governance Protocol (DGP)

Changing certain blockchain parameters through a dedicated smart contract

Qtum’s Decentralized Governance Protocol (DGP) consists of four steps.

1. Proposal creation: Governing parties make a proposal to change parameters
2. Voting: Governing parties vote for or against the proposal
3. Implementation or rejection: If vote threshold is reached, the proposal is implemented
4. Archiving: Proposal data is stored in a standardized format on a particular storage. Thus, the proposal can be accessed without executing the DGP.

Design variations can be made along the vote sources (i.e. who has voted) by differentiating between users, miners, and developers. This allows for a requirement-based governance process where, for example, a change can only be implemented if 100 users, 10 miners, and 50 developers have voted for the change.

Governance spectrum: from full to none human involvement

In Qtum, the governing parties are either people or smart contracts. The nature of these governing parties is important because depending on whether it consists of people or smart contracts it takes different positions along the governance spectrum.

Qtum’s blockchain governance spectrum

• No code: On the far left of the governance spectrum Qtum’s governing parties consist primarily of people. Those people would propose changes, vote on them, and implement them.
• No people: On the far right of the governance spectrum the governing parties consist primarily of code, i.e. smart contracts. In this scenario, there are different smart contracts for different tasks. Some would monitor the blockchain for technical issues, some would create the proposals, others would vote or take care of collecting votes from other smart contracts, and yet others would finally implement the proposals leading to what Qtum calls a „self-aware“ Blockchain.

Between those two extremes of full and zero human involvement lies a range of variations in regards to the human/machine distribution.

Takeaways

• Hard and soft forks are unavoidable but they must not be used for all changes
• Requirement-based governance (approving proposals only if specific actors — e.g. stakers or developers — have voted) is useful for refining the governance model
• Governance models can range from zero to full automation and have all kinds of variations in between

Tezos

Tezos is a blockchain that distinguishes itself by having built-in on-chain governance.

In Tezos, there are two general triggers for protocol changes.

1. Stakeholders voting
2. More complex variations: protocols can only be changed if verified by a computer that they meet certain properties.

Either way, changes are implemented in so-called election cycles

Four election cycles until implementation

These election cycles last for about three months and consist of four quarters, each representing a different process in the governance model:

1. First quarter — Approval voting: During the first quarter protocol changes are submitted and stakeholders can approve the suggested protocols.
2. Second quarter — Voting: Stakeholders vote on the protocol that has received the most approvals in the previous quarter. Each type of decision (pro, against, abstention) counts as a vote.
3. Third quarter — Implementation or rejection: If the quorum is met and 80% of stakeholders voted in favor of the change, the change is implemented on the testnet. Else, the change is rejected. The quorum starts with 80% but is updated after each vote based on the quorum reached in the current election cycle.
4. Fourth quarter — Possible Go-Live: In this quarter stakeholders vote again. If the quorum is met and if the change receives 80% pro-votes, the protocol, currently running on the testnet, is updated onto the mainnet.

In the first twelve months of Tezos’operation, the Tezos foundation will have a veto power to mitigate any issues that might arise due to the yet untested governance model.

Takeaway

• The design of governance models must account for voting thresholds and define how many votes are required to achieve a change.

On-chain governance: aeternity and Dash

• aeternity: The aeternity blockchain uses prediction markets for their governance.
• Dash: Dash, a currency with focus on privacy (see Privacy coins vs. coins with a privacy feature: analysing privacy coins and Market map privacy coins, protocols, and platforms: cryptos bringing privacy to blockchain for more on privacy coins) relies on the so-called Decentralized Governance by Blockchain (DGBB) for governance. The DGBB uses masternodes for voting.

Decred: (temporary) off-chain governance through Councils

Decred, a currency with focus on privacy (see Privacy coins vs. coins with a privacy feature: analysing privacy coins and Market map privacy coins, protocols, and platforms: cryptos bringing privacy to blockchain for more on privacy coins) relies (currently) on off-chain governance. In the future, the decision making will be moved on-chain.

Crucial to Decred’s governance process it the Decred Assembly which votes on changes. The Decred Assembly consists of so-called Assembly members. Those Assembly members are selected by the Admission Council. This Admission Council is one of initially three Councils (more can be added over time, see Creation Council below). These Councils are split based on their function:

Admission Council

The Admission Council votes for admissions into the Decred Assembly. Assembly members are selected regardless of age or nationality but must pass the following restrictions:

• applicants must receive 60% or more votes from the Admission Council members
• applicants must have been involved in Decred for a certain time
• the work of the applicant and its impact on Decred must be deemed worthy by the Admission Council.

Creation Council for creating new Councils

The Creation Council’s has a meta-governance responsibility, namely the creation of new Councils

Attrition Council for terminating Councils and Assembly members

The Attrition Council is responsible for terminating Councils and Assembly members. The framework for terminating members is as follows:

• 60% or more members of the Attrition Council must vote in favor of termination
• members are terminated if they do not fulfill one’s duties for the respective Council(s) or the Assembly itself
• members that conduct in ways that harms Decred without trying to undo are terminated

Furthermore, Decred has set up a maximal resolution time of 365 days. This means that all issues must be resolved by vote within a maximum of 365 days.

Takeaways

• Governance models can start as off-chain and move on-chain over time
• Off-chain governance model can be complex (but not necessarily complicated)
• Transparency in regards to governance rules (e.g. application requirements) and outcomes is crucial for off-chain governance
• Meta-governance, i.e. how to govern or change the rules that make up the actual governance matters

Off-chain governance: Bitcoin and Ethereum

Bitcoin and Ethereum use off-chain governance where the Bitcoin Improvement Proposals (BIPs) and Ethereum Improvement Proposals (EIPs), respectively are submitted, discussed in online meetings and if agreed upon implemented.

Notes

*edit thanks to Júlio Santos