Governance
Anyone holding VOT3 is a member of the DAO and can take part in voting events. VOT3 is the VeBetterDAO’s governance token, required to vote, and obtained by swapping from B3TR at a 1:1 ratio. All members can vote on proposals, participate in governance discussions, and access the Treasury, with the only minimum requirement of holding at least 1 VOT3 token. This ensures we can foster an inclusive, engaging environment for everyone.
Governance Stabilization Period and Initialization
At launch, VeBetterDAO will adhere to an initial set of governance rules until it has run for one year without any technical interruptions. The Stabilization Period is critical for ensuring the long-term efficacy and viability of VeBetterDAO. To prevent exploits during the Stabilization Period, VeChain Foundation maintains the ability to pause & restart B3TR token minting, only in the case of an exploit or other major issue. Once the requirements of the Stabilization Period have been met, community stakeholders can maintain or deprecate this functionality through governance.
Proposal Submission
Proposals are the backbone of any DAO, and the community is a key part of the proposal process. VeBetterDAO will maintain a forum for proposal submission, discussion, and voting. The forum will feature a dashboard detailing voting results, historical records, and proposal details. For a proposal to reach the final stages and be implemented, it must go through a predefined process, including initial forum-based community discussion, and a community ‘temperature check,’ before on-chain voting and implementation.
Community support
Every time a proposal is created, a deposit threshold of VOT3 tokens, calculated upon the total supply of B3TR, is calculated and must be met for the proposal to become active.
This deposit functions as a temperature check—if the community believes the proposal is worth considering, they can contribute a certain amount of VOT3. If enough VOT3 is deposited (reaching the threshold) before the end of the waiting period, the proposal becomes active; otherwise, it is automatically cancelled.
Users can withdraw their VOT3 deposits once the proposal is cancelled or the voting period starts.
While tokens are locked for supporting the proposal they cannot be used to vote in allocation rounds or other proposals. This means that if we are in Round #2 and you support a proposal that will start in Round #4 you won't be able to access those tokens/vote in Round #3 and Round #4.
Governance Process
The governance process is the following: propose → vote → execute if succeeded.
Let's break it down:
Everyone can create a proposal. When creating a proposal, the user specifies a description and an action to be performed on proposal success. The action can be: - Call the function x() of the contract with address 0x00000 with the following parameters. - Call multiple functions of different contracts with different parameters in a specific order. - Do nothing. E.g.: “Let’s add feature X”. Even if the outcome is “YES” there is no on-chain action to perform immediately because it needs off-chain developers' involvement. Proposals are aligned with the allocation rounds voting periods, so the proposer must also specify the round when the proposal should become active.
After the proposal is created, there is a waiting period before the proposal becomes active (can receive votes). During this waiting period, there is a temperature check and the community must fund the proposal with VOT3 tokens. Each proposal has a deposit threshold to reach, and if this threshold is not reached, then the proposal gets automatically cancelled. During this waiting period, the proposal can be cancelled by the user who created it or by an admin of the DAO.
Once the proposal is active, a snapshot of the total supply of VOT3 tokens and balances of each VOT3 holder is taken and used to calculate individual voting power, and VOT3 holders can vote AGAINST/YES/ABSTAIN for that proposal. Each proposal will remain active for the duration of the round. When you cast your vote, all 100% of your voting power will be used.
Once the voting period is over, if the quorum is reached and the majority voted in favour, the proposal is considered successful and can proceed to be executed. A Timelock is used for this operation, which adds a delay to proposal execution.
Quorum
Quorum is 30% of the total supply of VOT3. All types of votes (yes, no and abstain) are considered when calculating if quorum is reached.
Voting rewards are distributed regardless of what type of vote was cast.
Vote Outcome
If a quorum is not reached then the proposal is considered defeated.
If a quorum is reached then "yes" and "no" votes are counted, if "yes" votes are more than "no" votes then the proposal is considered succeeded.
Voting rewards are distributed regardless of the vote outcome.
Execution
The VeBetterDAO's Governance contract can execute actions on all contracts deployed on the VeChainThor blockchain, provided the respective contracts permit those actions.
We added a timelock to governance decisions, this allows users to exit the system if they disagree with a decision before it is executed. We are using OpenZeppelin’s TimelockController in combination with the GovernorTimelockControl module to achieve this. To execute a proposal, it first needs to be queued to Timelock contract and wait a specified amount of time before being able to execute it.
Initially, only selected admins will be able to execute proposals.
Vote Delegation
For DAOs that use the Governor contract (as we do), only delegated tokens can participate in voting. What does this mean for you, a token holder?
You must set up delegation if you want to participate in governance votes. This includes delegating to others or voting yourself.
If you wish to vote on proposals directly, delegate your voting power to your own address. Or, you can delegate your voting power to another community member and let them vote on your behalf.
Currently, we have an auto-delegation feature in our smart contract that will automatically delegate to you when you convert B3TR to VOT3 or someone sends you VOT3 tokens. However, this auto-delegation feature is not enabled for smart contracts, so if you are writing a smart contract that wants to receive VOT3 tokens and participate in governance you will need to manually delegate. This needs to be done only once.
Quadratic Voting
Quadratic Voting (QV) is a method used to re-calibrate voting power within the VeBetter DAO, specifically for the B3TR Governance model. Unlike traditional voting mechanisms that may disproportionately empower large token holders, QV modifies this by determining voting power based on the square root of the number of VOT3 tokens held. This approach ensures that while voting power increases with more tokens, it does so at a diminishing rate.
The formula shown below reduces the influence larger stakeholders might have, promoting a more balanced and fair decision-making process.
Each voter casts their vote as FOR, AGAINST, or ABSTAIN on proposals, with the effective weight of these votes directly linked to their recalculated voting power. This structure not only aligns with standard quadratic voting practices but also ensures governance is more reflective of the wider community preferences.
Linear Voting
By default, QV is enabled for all voting rounds. However, governance and admins can choose to disable QV, switching to linear voting. In linear voting, voting power is directly proportional to the number of VOT3 tokens a user holds.
Important Note: If QV is disabled by an admin during an ongoing round, the change will only take effect starting from the next round.
Upgradeable parameters
The following parameters can be updated by governance:
Quorum: currently set at 30% of total VOT3 supply
Deposit Threshold: percentage of the total supply of B3TR tokens that need to be deposited in VOT3 to create a proposal, currently set at 2%
Voting Threshold: the minimum amount of tokens needed to cast a vote, currently set at 1
Minimum Voting Delay: the minimum delay a proposal must be in a PENDING state before voting can start, currently set at 3 days
Timelock Minimum Delay: time to wait before a proposal can be executed after it was queued
Voting Period: While this value can be updated in the governance contract, it must be equal to or shorter than the Emissions Cycle. To extend the Voting Period beyond the current cycle, you must first update the Emissions Cycle duration.
Enable / Disable Functions Restrictions: if disabled there isn't any restriction on what contracts and functions can be called when creating a proposal
Whitelist Functions: if function restrictions are enabled then whitelist a target and function
Last updated
Was this helpful?