December 13, 2018 . 5 min read
Governance is poised to be one of the most important topics in crypto in 2019. As major institutions and enterprises circle round the industry, they are increasing the stakes of the conversation. To inspire the confidence and trust required for that set of actors to get involved, protocols have to be able to answer questions about the rules that make protocols function, how those rules are enforced, and how those rules adapt.
We’ve previously articulated the challenges we believe current models face: efficacy and finality issues in off-chain systems and plutocracy and populist issues on-chain. In this third session of our governance peer review, we preview our proposed model - a decentralized republic based on checks and balances. We’ve broken it into four sections:
The Storecoin Model Of Checks & Balances Governance
Storecoin is building a zero-fee payments protocol for the public internet. We believe that: 1) For cryptocurrencies to live up to their true potential to increase trade and commerce, they have to be accessible to today’s leading enterprises, and; 2) Governance is key to that accessibility.
Governance is the rules engine for Storecoin’s zero-fee payments protocol. Sitting at the center of consensus, economics and security, governance provides a mechanism to coordinate and evolve the protocol.
Our checks-and-balances model is inspired directly by the framers of the US constitution, who knew change needed to be possible to evolve to new circumstances, but sufficiently difficult to avoid radical reactive swings as leadership changed hands.
The key features of this model include:
Separation Of Powers: The roles and responsibilities of Storecoin’s governance are divided across four branches - the Decentralized Workers, Executive, Judicial and Security -described in the “Parties” section below. The actors who make up each branch have different incentives, creating a check on one another so that no category of participant in the network can drive the ecosystem too far towards their exclusive benefit.
No ‘Fed’: Cryptocurrencies are defined in large part by monetary policy, such as inflation and miner rewards. In Storecoin, there is no governance body able to unilaterally change these policies (such as the United States Federal Reserve). Instead, policy changes are subject to checks and balances - proposed by one branch (Judicial), voted upon by another (dWorkers), and approved or vetoed by a third (Executive).
One-Entity-One-Vote: Token- or stake-based on-chain voting systems engender plutocracy where the richest stakeholders determine protocol direction. This can be because votes are delegated or because you have to purchase tickets or stake a certain amount to vote. Voting in Storecoin is a one-entity-one-vote approach, verified by KYC/AML and ensuring that governance is not simply a rubber stamp on the interests of the largest economic stakeholders.
Articulated Change Process: Well-functioning governance requires that the participants understand how change happens and how they can shape the direction of that change. We’re committed to a full articulation of the change process, public review and ratification of the governance system, and simple user-friendly interfaces that make it easy for the Storecoin community to participate in governance.
Enforceability: For any governance rules engine to function, it needs to be able to enforce those rules. Entities such as nodes that formally join the Storecoin ecosystem commit themselves to certain roles and responsibilities, as well as penalties if they fail to comply. These penalties include things like slashing of stake for nodes who fail to upgrade to the latest software when changes passed through governance are implemented and the firing of an Executive Director who fails to promptly ensure the implementation of changes that have reached consensus.
Storecoin’s governance is split into four different branches: the Decentralized Workers (dWorkers), Executive, Judicial and Security Branches. The community of $STORE holders do not vote, but are able to exert their voice by proposing changes.
The dWorkers are the voters in the Storecoin system. Any $STORE holder can propose a feature change and crowdfund proposals to achieve the minimum funding threshold required to be added to a formal ballot. When this happens, the measure moves to a dWorker vote.
The dWorkers branch has four chambers: Validators, Messagenodes, Masternodes and dSecurity Guards (dGuards). Validators run full nodes to validate the p2p consensus. Messagenodes run full nodes to host data for the p2p consensus. Masternodes provide infrastructure for scaling. dGuards are focused on the security of the network. Each group has its own voting chamber, akin to the US Senate and the House.
Masternodes, Messagenodes and Validators are self-selecting (subject to a KYC process) based on their willingness to stake and work on the Storecoin network while dSecurity Guards are hired (or rehired) each year by the Chief Security Officer.
The Executive Branch delivers the changes approved by the dWorkers Branch. It consists of an Executive Director, who can serve for a maximum of 8 total, non-consecutive years, and who has the power to ratify or veto measures passed by the dWorkers, plus a team of developers. When a change is voted on through governance, this group has a specific time window in which to deploy the change to code. If a measure is vetoed, it returns to the Decentralized Branch (dWorkers) for another vote in which a larger majority than during the initial vote on the proposal is required to overcome the veto.
With regard to changes other than feature change requests, the Executive Branch can also propose monetary policy to be reviewed by the Judicial Branch, and has a role in determining the approach to severe security threats and loss of funds issues.
Additionally, the Executive Branch recommends appointments to the Judicial Branch, which are confirmed by the dWorker Branch, and helps hire the Security Branch officials. The Executive Director is appointed, reports to and can be removed by the Judicial Branch, with appointment approved via dBranch vote.
The Judicial Branch is charged with the long term health of the network, focusing on monetary policy (inflation, worker compensation, etc.), compensation for governance participants and compensation for network activity. In the case of an emergency where there is a significant loss of funds, the Judicial Branch also plays a role in setting the security level and determining the course of action. The Judicial Branch is also nominate the hiring of the Executive Director and the Chief Security Officer, confirmed via dWorker Branch vote. The Judicial Branch is comprised of a group of impartial directors who do not hold other roles in the Storecoin ecosystem, as well as the Govnodes who run the infrastructure for decentralized governance.
The Security Branch is responsible for the overall security of the network, including detecting potential security flaws and proposing solutions. They are led by a Chief Security Officer (CSO) who can serve for a maximum of 8 total, non-consecutive years. Security dGuards are hired and fired by the Security Branch, but vote within the dWorkers Branch. The CSO is nominated by the ED, reviewed by the Judicial Branch and then finally approved by a dBranch vote. They are removed the same way.
Change Process Across Categories
Storecoin change proposals are organized across four categories:
Feature Change requests are requests to update the protocol, such as increasing the number of dGuards or changing what percentage of votes need to be “yes” to approve governance measures. They can be proposed by any Storecoin token holder for a small fee (designed to limit spam).
When a proposal is made, it must garner sufficient support before it can be added to a voting ballot. This happens through a funding process that allows each proposal 90 days to reach a staking threshold that increases as total market capitalization increases, enabling the community to focus on the most important measures.
Once a change has reached the funding threshold it is added to the next ballot to be put up for a vote. Voting occurs at least once quarterly. Voting is one identity: one vote and enforced through KYC validation.
Voting is a process of sequential votes from the different chambers who comprise the dWorkers branch. Voting proceeds through from Masternodes to Validators to Messagenodes, finally to dGuards. Quorum requires 50% of each chamber +1. Different chambers have different voting thresholds to pass a measure. Measures only proceed when they pass each chamber and only need to fail one chamber for the measure to fail overall. dWorkers who do not vote on at least 3 of the 4 annual ballots incur penalties in the form of burning of their stake.
When a change proposal is accepted, the Executive Director has 14 days to either ratify or veto the proposal, and the Storecoin Core Team has a standard 12 months to develop and deploy the ratified change.
If a proposal that has passed the Decentralized Branch is vetoed by the Executive Director, it is returned to the dBranch for re-vote 7 days after the veto, where it must receive an increased majority to be passed again. If the Executive Branch refuses to implement an approved change within 12 months, they can be fired by the Judicial Branch for cause.
Monetary Policy Changes
Monetary policy changes are changes to key economic factors such as compensation amounts for network actors or changing the overall inflation rate. The Judicial Branch meets quarterly to review and propose changes to monetary policy.
Unlike Feature Change requests, monetary policy changes do not require a funding commitment or have a minimum staking threshold to be added to the official ballot. Proposals from the Judicial Branch are immediately added to the next ballot voting.
Once a proposal has been made, voting follows the same process as Feature Change requests. Because there is no "Fed" in Storecoin, even monetary policy changes must be approved by the dWorker and Executive branches.
Leadership changes are changes to the Executive Director role or the Chief Security Officer role, as well as to Judicial Branch board members. These changes can be for the nomination of a new ED or CSO, or a recommendation asking for their impeachment, and do not require funding but are put straight on the next ballot.
Severe Security Flaw
Severe Security threats are marked algorithmically or by the Judicial Branch. When they occur, the Executive Branch (with help from the Security Branch) can propose a protocol change to the Judicial Branch, which that branch then votes on. If that Judicial vote passes, the protocol change goes to the developers of the Executive Branch to enact. This is all done without a vote by the Decentralized Branch, as taking a proposed change through the full governance process would not allow Storecoin to address an emergency network issue in time.
The Severe threat level lasts only 30 days, after which, any change must proceed through the standard process. If after 30 days, no decision can be reached on how to proceed, the Judicial Branch may request a vote to extend the Severe threat-level period but that must be passed by the dBranch in a manner similar to all other governance voting processes.
How Changes Are Deployed
Once a change is voted upon and approved by the dWorkers Branch and ratified by the Executive (or, in the case of severe security threats, a solution proposed by either the Executive or Security brand is finalized and decided upon by the Judicial Branch), it becomes the job of the Executive Branch to turn that solution into deployable code.
The mandate of the Executive Branch is not only to turn voted-upon changes into code, but to do that on a prompt timeline. When a vote is approved, the Executive Branch has a specific time window within which they need to deliver the code. If they fail to deliver within that window, the Judicial Branch can fire the Executive Director without cause (in other words, without a vote). This creates positive execution pressure on the ED and the Executive Branch as a whole. If the Judicial Branch thinks the Exectuive Branch is under performing, they can recommend the ED be fired before the deliver window has eclipsed - but that firing must be put to a governance vote.
When the code is ready, it goes through a specific review process including: 1) formal code review by the implementing organization; 2) open review with the community; 3) deployment to testnet; 4) production deployment.
Unlike other public blockchains, in which upgrade to new software by the nodes is optional - even in the case of severe security holes, new software is automatically pushed to the dWorkers. When Masternodes, Messagenodes and Validators formally join the Storecoin network by going through KYC/AML, they agree to this push-based model. Those who don’t upgrade can be penalized by having their sake slashed. This slashing is not carried out by another branch, but is automated and carried out by the software, with an available appeal process for a node that believes it was slashed by mistake. This push-based model for node software updates does not threaten decentralization, as all of the changes that are ultimately pushed are the result of a democratic governance process.
An important piece of decentralization is powering the governance process with a dedicated decentralized infrastructure. For Storecoin, this includes a Governance app with end-to-end encryption and best-in-class security, as well as a decentralized computing and storage network of dedicated Govnodes.
Storecoin’s Governance app includes interfaces for messaging, sharing ideas, and voting. The app that runs this essential governance application will be hosted on a decentralized network of machines called Govnodes, rather than by a centralized Storecoin Inc. nonprofit server. There are two reasons for this: first, it safeguards that there is not one point of failure that could bring down the governance network. Secondly, it protects against Storecoin Inc. intentionally cutting off governance communication of Storecoin network actors, censoring communication or halting the people-led governance process.
Govnodes are part of the Judicial Branch rather than the Decentralized Branch in order to separate the mechanism for voting and the voting itself. A Govnode is a non-voting role to retain impartiality. Govnodes must remain anonymous to prevent collusion, and any nodes caught gossiping will be immediately expelled from the network and blacklisted.
Individuals or entities can run a Govnode by staking an amount of Storecoin determined by the current security threat-level. The number of Govnodes at a particular time will be based on the current security threat-level, with more Govnodes available at times of a higher security risk and lower at less risky times.
Three key features make up the Storecoin Governance App experience:
This post is meant to provide a primer on the Storecoin Governance System. To get more involved in our Peer Review process through our Governance Working Group, review what we’ve published so far or email [email protected]
Nothing herein is intended to be an offer to sell or solicitation of offer to buy, STORE tokens or rights to receive STORE tokens in the future. In the event that STORE conducts an offering of STORE tokens (or rights to receive STORE tokens in the future), STORE will do so in compliance with all applicable laws which may include the Securities Act of 1933 and the rules and regulations promulgated thereunder, as well as applicable state and foreign law. Any offering for sale to US Persons in a regulated transaction will be pursuant to a registration statement qualified by the Securities and Exchange Commission, or an applicable exemption from the registration requirements.