Formal governance has always seemed of secondary, often tertiary, importance in blockchain projects, an item to be dealt with at an undetermined time in the future when a host of other factors has magically aligned. Lately, however, the trend has been forward-leaning. Dash and Cardano, as well as my own project Decred, are a few of the projects that have prioritized governance from the start. I am excited by this development because after seeing Bitcoin’s progress slowed due to infighting, we finally seem to be taking the necessary steps to become a mature industry.
In previous articles, I talked about setting up a cryptocurrency project. This time, I’m going to focus on running one. I will draw from my own experience, with the understanding that like disaster insurance, you can’t wait until your roof is being blown off to think about protection.
Here are five things to get you moving — and keep moving — even if you are late to the governance game:
1. Choose Your Consensus Algorithm Carefully
The type of consensus algorithm you choose for your cryptocurrency will play a central role in how your governance system works.
Setting up governance with proof-of-work is difficult, because the miners are not required to hold coins in the system, so they have no investment.
Proof-of-stake works best because everything is good to go. Unlike competing models, the coin holders maintain the system. Their chance to create a block or vote on the validity of a block is weighted based on how many coins in the system they own. It is easy to extend that to voting on protocol changes as well.
The downside is that implementing a secure proof-of-stake system can be difficult, because if the chain forks, there is nothing to keep coin holders from validating blocks on either branch to earn transaction fees in both directions. Proof-of-work was specifically designed to get users to mine a single chain.
At Decred, we chose a hybrid proof-of-stake/proof-of-work system because it offered the best of both worlds. Proof-of-work allows you to create a distributed timestamp, which adds to the security of the blockchain, while proof-of-stake cuts a straightforward path to governance.
2. Start Simply with Hard-Fork Voting
Now that you have the basis for your governance system set up, what should users vote on? We started with hard-fork voting because we knew, based on the context of Bitcoin, that what stakeholders care most about are the consensus rules, which are the foundation upon which all blockchains are built.
To implement hard-fork voting, we adopted an approach that draws on Bitcoin Improvement Proposal (BIP) 9, originally developed to allow miners to vote on multiple soft forks by allowing users to flip a version bit in the block header.
In its original form, BIP 9 requires 95% of the hash power in a 1,000-block rolling window to be behind a particular version for the consensus rule changes to occur. The problem is getting a near unanimous vote on anything is almost impossible.
In the case of Decred, we decided to change that to 75% approval. We extended the voting to stakeholders. In Decred, stakeholders first need to signal they know there are new items, called agendas, to vote on. Like Bitcoin, we encoded the consensus changes in advance, but unlike Bitcoin, we made the change optional based on the results of stakeholder voting.
So, basically, in Decred, there are three phases to voting:
1. Proof-of-work miners and proof-of-stake stakeholders upgrade their software and begin voting. Votes are tallied for 4 weeks.
2. After that period, another 4 weeks pass before any agenda items voted on by 75% or more of users are activated on-chain.
3. Any agendas items that did not receive more than a 75% yes or no vote roll over to the next 4 week voting period, and so on, so those items are given roughly a full year for consideration.
3. Is the Action On-Chain Or Off?
The big question is should all your voting be done on-chain? Most people would agree consensus voting should be performed in a censorship-resistant medium because those are the most important to a project.
Additionally, you also want the protocol upgrades themselves to be tied into the voting. In other words, you don’t want to put a major software change up for a vote and then say, “Trust us, we’ll implement it later.” Instead, ensure those votes activate the software change automatically.
But do you need to do all voting on chain? Probably not Due to the high redundancy of data stored on-chain (every node in the system keeps a complete copy of the ledger), it does not make sense to store all governance decisions on-chain. Less important decisions, like voting on whether or not to fund a user-submitted proposal, are probably best handled off-chain.
With our project, we plan to develop another layer of governance to apply to contractors that perform work for the project, so we can have a system for resolving issues in a way that doesn’t turn into a stakeholder popularity contest.
4. Manage Incentives and Delegation
Once you start implementing governance, you will likely run into a host of other considerations. For example, how do you incentivize people to vote? Should you delegate voting to other people?
For us, the issue of incenting people to vote was neatly taken care of by the hybrid consensus mechanism we adopted from the outset Every time a stakeholder votes and that vote is included in a block, the stakeholder receives a reward.
Some governance systems use delegated proof-of-stake, where if a user does not want to vote, they can select someone else to vote in their place. I personally think that creates a system where ignorance flourishes. By delegating votes, we revert to the typical nation-state model of sovereignty, where the person who looks good in a suit or says things people want to hear ends up having all the say.
I consider the delegated governance model to be horribly broken since it often empowers those least fit to actually lead, e.g. superficial and two-faced people. If someone thinks this is a good model, they can obviously implement it without too much difficulty, but that is not what we chose for Decred.
In terms of what to vote on, once you conquer hard-fork voting, the world is your oyster. But other important topics for voting may be how to spend money in your treasury, what new projects to put effort into developing, who to hire as a full-time developer, and so on.
The key is to be sure to outline a roadmap for governance, post that roadmap online, and keep working toward the goals you set. After all, you want users to have as much faith in your governance system as you do in them. Such good faith is the best governance of all.