On-chain governance is a system for approving community pool spends, and managing and implementing changes to the Secret Network blockchain. Rules for instituting changes are encoded into the blockchain protocol. Developers and community members propose community pool spends or changes and each validator and delegator can vote on whether to accept or reject the proposed spend or change.
For technical documentation and secretcli commands click here
Governance starts with a proposal submitted to the blockchain. Anyone can submit a proposal as long as they have the SCRT to pay for the transaction and an initial deposit of at least 1 SCRT. To submit a proposal you need secretcli (the command-line interface tool for Secret Network). Technical documentation on governance and the use of secretcli can be found here.
There are 3 types of proposals. A text proposal that can be used to measure community support for an idea or concept. A parameter proposal to change parameters of the blockchain, and a spend proposal to use the funds of the community pool.
When a proposal is submitted it enters the deposit stage. The deposit stage lasts for a maximum of 7 days. In the deposit phase, anyone in the network can deposit SCRT into the proposal. When the deposit reaches the threshold (100 SCRT) the proposal continues into the voting stage. If by the end of the deposit stage the threshold is not met. The proposal is denied and the deposits are returned.
Note: The deposit phase can be as short as a few seconds. Reaching the threshold pushes the proposal into the voting stage immediately.
Note 2: Deposits are also returned at the end of stage 4 if the proposal wasn't rejected with a veto (in case of veto the deposit is burned).
As the proposal enters the voting stage Validators and Delegators in the network can vote on the proposal. The voting stage lasts for 7 days. By the end of the 7th day, a minimum number of votes has to be submitted for the proposal to reach quorum. If the quorum is not met the proposal is denied. The quorum threshold is 33,4% of all staked SCRT.
There are 4 types of votes one can cast: "Yes", "No", "No with veto", and "Abstain".
"Yes", signals you are in favor of the proposed community pool spend or change.
"No", signals you are against the proposed community pool spend or change.
"No with veto", signals you are against the proposed community pool spend or change.
No with veto only requires a threshold of 33,4% for the proposal to be rejected, in which case the proposal deposit is burned.
"Abstain", signals you aren't in favor or against the proposed community pool spend or change, and will accept the outcome of the vote. Voting abstain contributes to quorum.
Note: Validators can vote with the staked SCRT of all their Delegators. However, if a Delegator votes themselves his/her staked SCRT is subtracted from the voting power of the Validator. As a result a Delegator automatically votes with the Validator, but has the option to vote differently.
As the voting stage comes to an end the tally is made. This happens automatically on-chain. Here are the possible outcomes.
The proposal is denied if:
Quorum =< 33,4%
The proposal is accepted if:
Quorum => 33,4%
Staked SCRT voting "Yes" > 50%
Staked SCRT voting "No with veto" < 33,4%
The proposal is rejected if:
Quorum => 33,4%
Staked SCRT voting "No" or "No with veto" > 50%
Staked SCRT voting "No with Veto" => 33,4% (results in the burning of the proposal deposit (100 SCRT))
Note: to calculate the percentages for "Yes", "No", and "No with veto" staked SCRT voting "Abstain" is excluded from the calculation.
When the proposal has been accepted it is implemented. What the implementation entails depends on the type of proposal that was made.
Text Proposals
A text proposal, sometimes referred to as a signaling proposal, usually seeks to find community support for an idea, concept, schedule, or policy. The implementation is usually detailed in the text itself. It could mean we accept a certain standard within the community, or it could mean a detailed spend or parameter change proposal will follow for a future vote.
Parameter Proposal
When a parameter proposal is accepted the change is automatically executed on-chain. The change is effective immediately after the proposal passes.
Spend Proposals
When a spend proposal is accepted the "ask" is automatically transferred to the recipient address that was detailed in the proposal. The implementation depends entirely on the proposer and is usually detailed in the description of the proposal.