Applied Consensus Governance for Open Source Cryptocurrency Projects
Introduction
This paper will build on my previous discussion of consensus governance mechanisms for open source cryptocurrency projects. I will propose theoretical governance models as well as concrete implementations of those models. The implementations will largely use provable, on chain, mechanisms to control project governance.
Factions
There are several factions that traditionally emerge in any cryptocurrency project.
Miners: The traditional role of miners is to trade capital for chain security and earn an ROI in the process. This is fulfilled when the chain uses a proof of work security mechanism to secure the blockchain. Miners also provide liquidity and a source of new issuance via the mining process which can be inflationary, deflationary or neither.
Users: In most projects, the users are simply investors looking for an asset store of value. In some projects the chain may have value mechanisms, such as computational ability, data storage, NFT tokenization, smart contracts, etc. Those value mechanisms may be consumed by users as well. Generally users obtain the currency for asset appreciation or consumption of the chain utility.
Stakers: For proof of stake projects, the stakers provide chain security via staked (escrowed) assets which are at-risk for loss if the stakers fail to perform. In return, stakers earn rewards either in transaction fees, as set block fees or other mechanisms which may be inflationary, deflationary or neither.
(Core) Developers: In nearly all projects there is some set of people who are working on the core source code to improve it. The “core” is usually the source for the full node, although it may also include mining clients, wallets or other tools depending on the size and maturity of the project. Developers in this sense could be a loose knit group of people who commit code frequently, a single person with a side project that they want to have included or a highly organized group of employees working on an extension for commercial gain.
Foundation: Most projects have a non-profit foundation which serves as a vehicle to kick start the currency (someone has to be the first full node and miner!). The foundation may also exist to nurture the project and curate / highlight achievements and milestones. The foundation can prepare a roadmap and set certain strategic goals. Finally, the foundation can elect independent advisors to serve on a security review council to provide sign off on proposed code changes.
Commercial Entities: If the project becomes successful enough, third party commercial entities may spring up around the project to create for-profit products and services outside of the core software functionality. In some cases (perhaps most?), commercial entities will seek to control the developers and exploit the core
Consensus governance requires that everyone have a voice in proportion to their incentive to move the project forward in a positive way. This is of course very subjective. In theory, all parties should be motivated to increase the value of the project/currency. However, in some cases, some parties may disproportionately benefit from a proposal at the expense of others. That party may claim it is for the “greater good” when in reality they are acting out of self interest. In order to survive and thrive, the system must have an egalitarian process for reconciling contentious changes. Nearly all crypto projects in existence today lack such a process, and as a result, changes are thrust upon the project by a small number of people, usually those who created it, despite objections from one of more of the other factions. Another concern is that commercial entities can simply “throw money” at the project by hiring scores of developers to take over the agenda and move the project in a direction which only benefits those commercial entities, at the expense of other factions.
Theoretical Governance Mechanics
Governance is invoked when someone asks for change.
The mechanism to request change should be well documented, easy for anyone to request and built in to the platform natively. Anyone should be able to propose change, regardless of which faction they are in, including no faction at all.
Once a change has been requested, there should be a time period for discussion, perhaps clarification of the change, withdrawal, modification and so on. All of this should be built in to the platform.
If the proposal “survives” the discussion period it moves on to the voting period. The voting period should be long enough for people to become aware of it but not so long as to prohibit innovation or allow insecure systems to exist. Voting should be based on number of units of currency held and cannot be transferred (e.g. if a coin has voted on issue #73, it cannot be sent to someone else to vote on that issue again).
If after voting, the proposal has passed, the foundation will be authorized to act upon the proposal, if possible. Some proposals may not be actionable, so it will be incumbent on the proposer to ensure that the proposal is viable, although this will likely be vetted in the discussion phase, or if not, it will simply not pass.
Using this type of process for change management provides for the highest degree of transparency, ease of participation and incentivizes those with most at risk to make decisions which are correlated to positive outcomes from the project.
Side Chain 1…POW + POS = Better
This topic is necessarily subjective, however it is my position that a hybrid system of proof-of-work and proof-of-stake is superior to either alone.
POW miners are greedy capitalists. They invest at-risk capital for a return based on market conditions. They also provide high levels of security because of their at-risk fiat capital and the inherent “buried block” security mechanism. POW miners also serve as a natural balance to existential market factors (the Elon Musk Tweet syndrome) by flocking to currencies that are overvalued compared to their hash rate, until a natural equilibrium re-establishes.
POS stakers are the opposite of miners. They believe in the long term viability of the project and are willing to clear transactions for their committed capital. POS systems have inherent stability and lower environmental footprints. However, they falter on security because of the nothing-at-stake problem. There are no clear cut resolutions to this issue, although it may be possible to punish stakers who mine alternate chains, that would almost certainly have to be subjective and only leads to further centralization of control.
The better alternative is a POW/POS hybrid, where miners create blocks that solve a computationally difficult problem and then randomly selected stakers vote on those blocks to accept them and issue rewards.
Side Chain 2…Role of the Dev Fund
Many projects disavow the developer fund or foundation as “too centralized”. Cryptocurrencies which claim fair issuance often cite “no dev fund” as one of their features.
A dev fund with no governance is simply a kickback. This is indeed antithetical to fair issuance. However, I believe a dev fund, with proper governance, is critical to a project’s success, provided that other pieces of the governance model are present.
The dev fund serves as a reserve pool to enact governance. Think of it as a tax levied on all factions in return for utility services rendered. In this construct, the foundation holds the pool of funds available to incentivize developers or third parties to perform work on behalf of all voting factions. The dev fund is the mechanism by which governance is exacted.
Applied Mechanics of Governance
Step 1: A change is proposed. The proposed change is entered into the blockchain using the wallet software. Anyone can propose a change regardless of if they hold any currency or none at all. The change is automatically assigned a number and is accessible, via the blockchain and wallet, to all other users of the wallet (whether they have currency or not).
Step 2: The change proposal is scheduled for discussion. Using the wallet software, and recorded on the blockchain, the discussion between all other users of the wallet software will occur. Any user with the wallet software may view or contribute to the discussion. During this time the proposer may withdraw their change request at which point it will be marked as cancelled.
Step 3: The change proposal is scheduled for voting. The proposal will be available for voting for some period of time. Users’ votes are cast for or against using the wallet software and are recorded on the blockchain. Anyone using the wallet software may view the status of the votes at any time. Votes are cast in proportion to currency held and may only be cast once per proposal.
Step 4: The change proposal is ratified or denied. Based upon the number of votes cast and the rules of voting, the change proposal either passes or fails.
Step 5: If the change proposal has been ratified, the foundation takes action (if possible).
This process works when all of the involved factions are fairly compensated for their contribution and are incentivized to increase the value of the project. A true egalitarian, anonymous and automatic process allows for fair consensus governance that harmoniously moves the project to higher value.
To incentivize all the factions, and provide for a dev fee reserve, the block and fee rewards must be crafted in a certain way:
Some % to miners for contributing to the POW security
Some % to stakers for contributing to the POS security
Some % to the foundation for a reserve fund to execute governance
Some % burned to offset inflationary effects of mining/staking (if desired)
So, for each block mined, there should be a fixed reward, plus transaction fees for the use of the block utility, which are paid out in some proportion (not necessarily fixed) to the above list.
Examples
Example1
Joe is a commercial wallet developer. He has created a new wallet for CoinX which he wants to have included on the foundation’s website, coinxcoin.com. Joe’s wallet offers several new features such as the ability to swap other currencies, two factor authentication, etc. Joe enters a proposal onto the blockchain “Post Joe’s wallet on the foundation website”.
Assuming this proposal passes, the foundation will post a link to Joe’s wallet on the foundation’s website. This posting may be subject to verification of the wallet software by the security council for any malware.
Example 2
A group of currency holders wishes to have the currency listed on ExchangeX a cryptocurrency exchange. There is a 100EUR application fee and, if accepted, a 10,000EUR listing fee. The group enters a proposal onto the blockchain “The foundation shall convert sufficient funds in the dev reserve to 100EUR to apply to ExchangeX to list the currency on their exchange, shall make application to ExchangeX to list the currency, and if approved, shall convert sufficient funds in the dev reserve to pay the 10,000EUR listing fee”
If this proposal passes, the foundation liquidates 100EUR worth of dev fee funds, applies to ExchangeX, and if approved, liquidates 10,000EUR worth of dev fee funds to get listed on ExchangeX.
Example 3
Alicia is an independent developer who has created an extension to the full node software which allows for an optimization in the protocol that reduces node to node bandwidth. Alicia enters the following proposal on the blockchain “Merge pull request 3527 which allows for optimization of network protocol”.
If this proposal passes, the PR will be merged onto the main branch of production code and binaries will be built, subject to signoff of the security council.
Example 4
ChenLi is a developer working for a commercial enterprise which makes hardware wallets. This enterprise wants to incorporate CoinX into their wallet, however they are not sure if there will be an ROI due to CoinX being in its infancy, and therefore they want to cost share some of the developer expenses. ChenLi enters the following proposal on the blockchain: “The foundation is authorized to pay USD $5,000 to CompanyY LLC for the purpose of cost sharing the development of a hardware wallet. Further details can be found at this URL: xxx”
If this proposal passes, the foundation will convert sufficient funds in the dev reserve to pay CompanyY LLC for their work on the hardware wallet.
Example 5
Joachim is a user of CoinX. He believes the burn % per transaction is too low and that CoinX has become inflationary. He submits the following proposal to the blockchain: “The foundation is authorized to pay Coinx 50,000 as a developer bounty to perform programming to increase the burn % from X to Y”. After discussion the bounty is changed to CoinX 100,000.
If this proposal passes, the foundation will issue a developer bounty to change the burn % from X to Y. It is likely that the “core developers” will work on this to jointly split the proceeds, however any developer may claim the bounty if they are the first to submit an accepted pull request.
Important Point 1: The role of the security council is strictly to rule on security issues. The security council may not reject a change request or code merge based on any perceived reduction of value of the project or any subjective measure. A rejection by the security council must be accompanied by a clear finding of malicious intent by the developer for a code change with detailed analysis.
Important Point 2: The role of the foundation is entirely ministerial. The foundation is bound to act on any proposal which passes so long as the foundation is capable of acting on it. Code changes must be merged (if approved by the security council). Funds must be expended if the vote has passed. The foundation has no authority to second guess the voting user base.
Important Point 3: Requests for changes to the core full node functionality should follow a templated proposal which is easily accessible so that there is no confusion about how to issue developer bounties and what the conditions of acceptance are. This will avoid any appearance of favoritism or insider dealing.
Conclusion
I have presented a theoretical and practical framework for consensus governance of open source cryptocurrency projects which aligns all factions with higher value of the chain, provides for clear and egalitarian governance, does not favor any one faction over any other and resists the influence of outside forces.