The practical function of governance in the Regen Network and a deep dive into how it is carried out
Governance is one of the most important tools belonging to blockchains in the Cosmos ecosystem. Governance allows stakeholders to make decisions which directly affect the way the chain operates. Since the launch of mainnet in April of 2021, our stakeholders and validators have participated in the governance process which included proposals for software upgrades, parameter changes, and spending funds from the community pool.
The basic principles of community governance are very simple. Anyone staking $REGEN is eligible to vote on and submit proposals. Proposals, including the process that leads up to the vote itself, are used to make changes to code & procedure, utilize Community Spend funds, elect community members to upgraded roles, and generally find consensus on questions facing the network.
Proposals are the backbone of community governance. Below is the life cycle of the average proposal, though not every proposal will go through every stage. In certain circumstances, an emergency proposal may need to be submitted, such as to fix a security vulnerability or a critical bug in the software. In these cases the earlier stages of the proposal process may be omitted.
While there are no official rules for submitting a proposal, Regen Network offers the below guidelines for maximum success. Proposals that do not follow these guidelines may be voted down on principle.
- When socializing a proposal, the forum post should include a rational for the proposal that weighs the potential pros and cons of the outcome and provides supporting documentation and examples when appropriate.
- The time between socializing the proposal and submitting the proposal will vary depending on the proposal and community engagement but generally a proposal should be brought to discussion at least one-week before submitting the proposal on chain.
Before an official proposal is submitted, it should first go through a community discussion period. This not only gets the community engaged in the topic before the one-week voting period, but also weeds out proposals likely to fail. The discussion period can also be used to gauge community sentiment regarding the finer details of the future proposal.
For example, before Proposal #3 (Increase Validator Seats) was submitted as an on-chain proposal, it was discussed here. The community member who submitted the discussion suggested increasing the number of new seats from 50 to 62, and asked if the community might be willing to increase that number even higher to 70 or 75. Ultimately, Proposal #3 increased the number of new validator seats from 50 to 75 as a direct result of this discussion.
A discussion must be posted to the Regen Network Commonwealth Discussions page in the proposal process, but community members may want to use Discord to engage with the community even before this official step.
Once the poll has finished, a dialogue can be created on Discord for further discussion. Like Commonwealth discussions, this can be a good opportunity for finding community cohesion.
After a proposal has been properly vetted by the community, it is ready to be submitted and sent to a vote as an on-chain proposal!
Depending on the end goal of the proposal, either a Text Proposal or a Community Spend Proposal should be submitted on Commonwealth. When submitting either proposal, a deposit of 200 $REGEN is required to send it to a vote. This can be done with a single wallet at the time of submission or split between multiple wallets. When split between multiple wallets, the deposit amount must be submitted in full within 14 days of the proposals creation.
Generally the deposit is returned to contributors after the vote has ended, though there are circumstances where those tokens are burned (destroyed to prevent future use). Deposits are burned if:
- The deposit period expires before reaching the minimum deposit of 200 $REGEN
- The proposal fails to reach quorum meaning 40% or more of all staked $REGEN did not vote
- Proposals were vetoed meaning 33.4% of voting power backed the ‘no-with-veto’ option
Getting the proposal out to the rest of the token holders is a very important part of getting a proposal passed. Even though there has been discussion on Discord and in the Commonwealth forum there may be some extra visibility necessary in order for validators and token holders to be made aware of the proposal.
A new proposal should be posted/shared on the Discord server, social media, and respective blogs or websites. This will ensure maximum visibility and participation in voting.
On-chain proposals are open for voting for a one-week period and require a 40% quorum in order for the final vote to pass or fail.
The voting power is determined by stake-weight (the amount of tokens a user has staked) at the end of the 14-day voting period and is proportional to the number of total $REGEN tokens participating in the vote. $REGEN tokens must be staked in order for them to count in the voting process as liquid tokens are not counted toward a vote or quorum.
While both active (validators ranking in the top 75) and inactive validators may cast votes, inactive validators voting power will not count towards the final vote. For this reason, it is important to determine whether or not the validator you have delegated to is in the active set, because your stake-weight may not be counted towards the vote if they aren’t.
Lastly, it’s also very important to note the ‘no-with-veto’ option. Even though a simple majority of 50% or greater is required, a minority group with just 33.4% or 1/3rd of the voting power can fail a proposal that would otherwise pass by voting ‘no-with-veto’ . It is important to pay attention to the voting details on Keplr which allow you to view the percentage of vote types as a whole in order to gain a good understanding of whether a proposal will be vetoed and a deposit consequently burned.
Assuming a proposal passes, the final step in its journey is implementation. This can include a distribution of allotted funds, a scheduled upgrade, a change in voting parameters, or a change/update in the codebase, etc.