4. Management
4.1 Operating environment
Main chain and DAO operating system
The DAO contracts are deployed on an EVM-compatible chain, currently, Polygon is the option. The DAO can migrate to a different chain when necessary. The operating system of choice is a custom-built interface to display information about proposals, manage communication systems (links to Discord, show when calls are taking place, etc.), and the ability to vote on proposals.
10% of the total VEME DAO income stream is redistributed amongst VEME NFT holders. The distribution mechanism is based on how many votes an NFT gave out of the total amount of possible votes to hand out for that month. For example, when 10 proposals got pushed to the DAO and a VEME NFT voted (yes/no) on 8 of them, they will get 8/10 out of the total amount they would be able to claim for that month; resulting in metric incentivizing participation. Currently, DAOs are still coping with participation issues; this mechanism intends to heavily boost participation, handing out staking rewards based on the involvement. Unclaimed rewards go into the treasury.
Communication and alignment
In the end, it's up to “Governance and Operations” to decide on this matter, however, the current suggestion is to use the following setup:
Organizational:
Weekly meetings to communicate, organize and take actions between VEME NFT holders, pods, and VEME the company.
Operational:
On-chain voting for incoming VEME proposals with regards to treasury management or protocol management. Consider pod funding, monetary policy management (on a protocol level), or protocol advancement proposals.
Off-chain voting for deciding on smaller measures not inflicting treasury management or protocol management. Examples could be about support toolery choices, which events to do where etc.
4.2 Voting model
VEME’s DAO will be governed through NFTs. It uses an innovative model designed by The Development DAO which uses on-chain metadata to keep track of several metrics tied to these NFTs. These metrics will determine payout per NFT, the NFT vote’s heaviness and in future releases auto access to conference calls and other sorts of tiered access tied to the NFT based on its participation.
Initially, the DAO will kick off with 1 to 1 voting on NFTs. Later on, weighted voting per NFT can be implemented with each NFT becoming a stronger voter based on levels of participation in the previous month(s). A stake-weighted voting model based on participation in the previous month allows for creating a lighter vote for when an unused NFT is sold to another party; to give an onboarding experience, they being incentivized to learn about the ecosystem and actively vote to increase their vote’s weight and $VEME stake payout. Upon NFT transfer the vote’s ``heaviness” built up in the previous month(s) would reset to zero.
The heaviness of a vote can move from 1 to 3 upon fully participating over the course of 2 months. From here a vote’s heaviness moves in a trailing fashion, meaning the first month’s performance gets removed and the last month’s performance gets added.
As it has turned out, simplicity is key in DAOs. Serious UI/UX issues in voting models have surfaced over the past years, making complexity (difficult UI, too many choices, etc.) the main killer for DAOs.
Quorums for participation with voting deadlines can be set initially by the DAO. If the agreed-upon parameters, based on previous experience, don’t fit the DAO’s needs, voting parameters can be re-proposed.
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
