4.3 VEME DAO Governance
The VEME DAO will follow a gradual decentralization approach over 3 stages:
Early days - during this period, the team is in complete control of the project, and no voting is done. This is because there will be bugs and events which require immediate hotfixes, and this cannot be done democratically.
Semi-decentralisation - during this period, the team is still in complete control of the project and can deploy hotfixes same as above, but for the non-urgent decision, it can take community input via a forum or even via off-chain voting like a snapshot - https://snapshot.page/#/
Complete decentralization - during this stage, the project is fully decentralized, and all decisions are made via a strict procedure, and all voting is done on-chain. The process is detailed below:
The process for suggesting and implementing a proposal, during phase 3, will follow closely UniSwap’s governance process, with tweaked parameters and an additional Tender step. Voting on the system will be done via quadratic voting where the voting power of an individual is determined as:
Where:
VP is the voting power of the individual
M is the staking based multiplier as described above
VT is the number of VEME tokens staked
Phase 1: Temperature Check
The purpose of the Temperature Check is to determine if there is sufficient will to make changes to the status quo.
To create a Temperature Check:
Community member (A) asks a general, non-biased question to the community forum about a potential change (example: “Should daily LP rewards be increased to 0.02%?”).
Voters vote on-chain to indicate their interest in bringing it forward to the next stage. Voting lasts five days, or until 5% of the voting is pooled back to the proposal.
If the proposal gains 5% of the pool backing, it moves to the next stage - consensus check.
Phase 2: Consensus Check
The purpose of the Consensus Check is to establish a formal discussion around a potential proposal.
To create a Consensus Check:
Community member (A) uses feedback from the Temperature Check post and creates a new poll covering the options that have gained support. This poll can either be binary or multiple-choice but should include the option “Make no change”, or its equivalent.
Community member (A) creates a new topic in the forum titled “Consensus Check — [Your Title Here]”. This will alert the community that this topic has already passed the Temperature Check. Community moderators should immediately remove any topics beginning with Consensus Check that have not passed Temperature Check. Community member (A) makes sure that the discussion thread links to the:
Original Temperature check thread
Original Temperature check poll
The new poll for the Consensus check
Community member (A):
Reaches out to their network to build support for the proposal.
Discuss the proposal and solicit delegates to vote on it.
Responds to questions on the Consensus Check topic.
Shares their viewpoint, although tries to remain as impartial as possible.
The proposal should also include an implementation standard for the suggestion:
What companies/individuals are eligible for the implementation process Is a POC required
Does the treasury partially or fully fund the POC?
What is the maximum budget for the implementation?
What are the deadlines?
For submitting a tender proposal
For the final deliverables
What is the penalty for not delivering the project:
Within the deadlines
With a sufficiently good scope
Voting lasts five days. Whichever option has the majority of votes wins and can be included in a Tender for Stage 3. A 67% pool quorum of the voting pool is required for the vote to be considered valid.
If the option “Make no change” wins, the Consensus Check topic should be closed by community moderators.
Phase 3: Tender
Each passed Consensus Check will be subject to a public tender for implementation. The tender begins after the Consensus check, and applicants can submit their proposals for implementation. Those parameters include (but are not limited to):
Bit for the implementation
Deadline
Success criteria
Request for penalty amount subsidy
Request for audit subsidy
This process, as long as defined in the Consensus check, and at the end of the period, a vote is initiated. The vote lasts for five days:
Any proposal that collects more than 25% of the votes is subject to financial compensation for the PoC / application (if explicitly specified in the consensus check parameters).
The proposals are selected and ranked in order of votes collected. The top proposal is the winner and becomes the “Implementation party”.
The implementation party has two days to stake any penalty deposits as defined in the Consensus check. Suppose the implementation party cannot provide this amount on their own. In that case, it can be delegated to them (penalty amount subsidy) by everyone who voted for their application (taken in proportional amounts to the vote).
If the implementation party does not satisfy the above conditions within the time period, the contract is awarded to the second runner-up. This process continues until one of the applicants meets the above requirements. If none of the applicants satisfies the condition, then step 3 repeats all over. If step 3 fails a second time, then the whole process reverts to phase 2, where Community member (A) should suggest new proposal parameters.
Phase 4: Governance Proposal
Phase 4 — Governance Proposal — is the final step of the governance process. The proposal should be based on the winning outcome from the Consensus Check and the winner of the Tender and can consist of one or multiple actions, up to a maximum of 10 actions per proposal.
To create a Governance Proposal:
The implementation party writes the code for the proposal. A professional auditor should audit all proposed codes. This auditing process will be paid or reimbursed by the community treasury (audit subsidy).
Once the proposal is active, a five-day voting period is started. Ongoing discussions will take place in the community forum. If the proposal passes successfully, a two-day timelock will follow before the proposed code is executed. If the proposal does not pass, one of two things happen:
The community can vote on a time extension for the implementation party to recalibrate their proposal.
The community rejects the proposal, any penalties defined are slashed from the implementation party’s deposit, and the Tender process begins anew.
Governance Glossary:
Governance token: An ERC-20 token that designates the weight of a user’s voting rights. The more Governance tokens a user has in their wallet, the more weight their delegation or vote on a proposal holds.
Delegation: Governance tokens holders cannot vote or create proposals until they delegate their voting rights to an address. Delegation can be given to one address at a time, including the holder’s own address. Note that delegation does not lock tokens; it merely adds votes to the chosen delegation address.
Governance Proposal: A proposal is a code that is executed by the governance contract through timelock. It can replace the governance contract, transfer token. Proposals are stored in the “proposals” mapping of the Governor smart contract. All proposals are subject to a 5-day voting period. If the proposer does not maintain their vote weight balance throughout the voting period, the proposal may be canceled by anyone.
Quorum: For a vote to pass, at least 67% of all delegated tokens must vote in the affirmative. The purpose of this quorum is to ensure that the only measures that pass have adequate voter participation.
Voting: Users can vote for or against single proposals once they have voting rights delegated to their address. Votes can be cast while a proposal is in the “Active” state. If the majority of voters vote for a proposal, the proposal may be queued in the Timelock.
Timelock: All governance actions are delayed for a minimum of 2 days by the timelock contract before they can be executed.
Last updated
