I have to disagree with you on only voting for apps you use and especially receiving less. The point of the DAO is to bring sustainability driven apps that encourage growth in the DAO. For example: there are some apps that I think are great but that I can’t use perhaps due to the fact it doesn’t fit lifestyle per se but it’s something that truly has an impact. What wrong with supporting an app that helps the DAO? I think most ppl DONT vote for apps they don’t use and that corners apps that perhaps are great but don’t get enough support. You shouldn’t be penalized for supporting a worthy app. If anything you’re helping the ecosystem. To me that’s a closed minded mentality that stalls growth and innovation. IMO anyway.
1 Like
Overall I think lessening the rewards for abstain by 2 thirds is significant enough get a double take from those lazy voters. And like @Virus.exe.zip stated as well, manual voters(myself included) should be recognized as active voter regardless of percentages allocated. Being that out of 10 new apps let’s say, 2-3 are probably legit. However if no new apps come on for a while or I don’t like nor use the newer apps then I don’t think I should be forced to change percentage unless it warrants it. OR perhaps instead of making it weekly change to perhaps every 2-3 weeks(bout the time it takes for new app to come into the DAO). Or Mayb something can be attached to voters that distinguishes active from lazy by more habits then just changing the percentages.
Navigators phase sounds good to me and I could see why it could go hand in hand with the first phase to help bridge the gap to achieve some of the first task but I rather myself NOT delegate with my spare vot3 as I already have a vedelagated position. I don’t think I’m half lazy though bcuz still have to check for proposals. And I also go thru every couple of weeks.
Mayb some type of alert can be implemented that reminds/encourages ppl to reestablish their positions on apps. But idk if that will encourage sincere behavior but it will result in forced behavior or loss of rewards.
1 Like
ok thanks for explaining!
- Technically it’s very hard to distinguish - manual or by programs. Smart contract is not able to tell the difference.
- The purpose is not to pin down people to do manual vote only but to motivate people to explore more, make responsible votes, monitor application performance and etc.
- Again, the idea is to drive to Navigators who is motivated to spend more time to study and cast the votes representing people. Put those two steps together to think.
- in terms of “dead wallets” - Distinguishing is even harder but at the same time, you cannot diminish the voting power since they are token holders.
- In terms of Abstain votes, check my replies to others.
Actually, if you do manual voting every week, it should be fine categorized as Active Votes - because you will change your voting power (amount Vot3), that counts of change.
How? Is the change in the number of Vot3 also seen as proof of an active voter rather than a lazy one?
But doesn’t every wallet that leaves its tokens on vedelegate vote with more Vot3s from week to week because it receives voting rewards every week?
Then the whole proposal doesn’t make sense, or am I missing something?
1 Like
Yes, good point. For example, on L2E your previous round rewards contribute to voting power for the next round, changing the allocation weight automatically.
My comment on Phase 1: The abstain option should remain available when voters choose it intentionally. The Governance Intent Multiplier already provides a simple mechanism to discourage unnecessary abstentions, and it could be strengthened with an additional multiplier linked to proposal comprehension.
Voters could be asked to answer a short set of multiple‑choice questions about the proposal. These would require only a click and would confirm that the voter has actually read and understood the content. The proposal owner would prepare these questions, ensuring they are straightforward for anyone who has reviewed the proposal. The owner would then include the four questions and their correct answers directly in the submission form.
Then the system will calculate the % of correctness (0/25/50/75/100 for 4 questions) and the corresponding multiplier.
Reward would be = base x governance intent multiplier x correctness multiplier
The correctness multiplier could replace/complement the freshness multiplier
Note on the Freshness Multiplier: It adds unnecessary burden on those who already vote consistently every week. Since the goal of the proposal is to reduce lazy voting, this mechanism ends up penalizing the most engaged participants instead. It feels like imposing a fine on everyone because of a single offender.
1 Like
Keep it in mind - the “change” needs to be easily identified by Smart Contract. It’s not that easy to have complicated metrics including % of votes.
Again, eventually the proposal is to rely on Navigators and the rules applies to Navigators as main focus who are much more trusted to cast active votes and monitored by community.
In terms of VeDelegate, then we need to convince VeDelegate to be Navigator (it’s an obvious candidate for sure). Right now, VeDelegate just be passive to do the action from users - but most of users choose “default” and do nothing active - that would be main difference.
I would lean more to start from simple first other than giving too much burden to the system from the beginning. Remember - we are talking about Smart Contract here.
Thank you very much for taking the time to respond and for the detailed clarifications. I really appreciate the way you broke down the different scenarios around abstention and governance intent — it helped me better understand the rationale behind the proposals.
Your explanation of how the two phases are meant to work together, especially the role Navigators can play in addressing lazy voting while preserving individual choice, adds important context. The emphasis on flexibility for delegators and the ability to switch or reclaim voting power at any time is particularly reassuring.
Overall, I find these changes thought-provoking and well intentioned. I’m genuinely curious to see how they evolve in practice, and I’m motivated to continue engaging and supporting improvements that strengthen governance quality and long-term participation within the ecosystem.
Thanks again for the time, transparency, and open discussion.
We have had some discussions on this proposal over on the vebetterdao discord server, but I figured I’d sum up my thoughts here.
Firstly, I fully agree with the diagnosed issue - we have a lot of accounts that auto-vote for one reason or another, both on dApps and as automatic abstains cast by automation solutions like veDelegate.
I have some concerns with the suggested implementation though. Firstly, on addressing lazy voters, when you define an Update:
I’m reading this like you’d redistribute the VOT3 allocated to your selected dApps. Given that the voting contract simply takes in an array of appsIDs and your VOT3 weight (there’s no parameter for “% of total”), how do we differentiate from compounding VOT3s earnt from either the voting rewards themselves, or from X2Earn dApps? If you vote with 1000 VOT3 one week, you’d most likely vote with more than 1000 VOT3 the following week, meaning the dApps’ weights are changed without user intent.
Is the solution to calculate the ratio of weights (e.g. 4 dapps with 100vot3 spread evenly is the same as 4 dapps with 110 vot3 spread evenly)? I assume it is, but a clarification would be good. If we are purely looking at the VOT3 weights themselves, these would constantly change, making the solution ineffective.
On problem 2: I think we have to clarify what the proposal would actually accomplish here. This solution would reduce the voting rewards given to abstain voters, but it will not ‘improve optics’ or the signal-to-noise ratio. The 50-60% abstains will most likely remain. Looking at the three most recent proposals voted on:
- Grant transparency proposal has 24317 abstains (in the sample I have).
- Out of those, 24247 are cast by veDelegate - 99.71% of total abstains.
- GronCard grant proposal:
- 11372 abstains, 11263 coming from veDelegate - 99.04% of total abstains.
- Cosmic climb:
- 11278 abstains, 11177 coming from veDelegate - 99.10% of total abstains.
Out of the abstains from veDelegate, 50%+ are voting with less than 100 VOT3. This leads me to believe that abstain votes are not users electing to abstain but rather one of the following:
- Accounts setting up in-app automatic voting in any of the dApps that utilize veDelegate’s integration. These typically do not have any idea that the action spins up a staking wallet that auto-votes abstain for them.
- lock2earn terms setup by users who did it for the APY on L2E, forgetting that they also have to vote on proposals. Each term (up to 5 per ‘main’ account) is one abstain vote.
So while yes, the voting rewards for them will go down, but I don’t expect any of the expected outcomes from the proposal to occur. Not because they willingly accept the loss but because the account abstain voting simply doesn’t know it happens.
A better solution to improve optics is to simply disregard abstains in any discussions. Adjust the frontend on governance.vebetterdao.org to simply collapse/hide the abstains and just weigh for/against vs each other, or alternatively adjust the contract to accept a source parameter that would include VeBetterDAOor veDelegateas the source of the vote, making it easy to filter out ‘automatic abstains’ to improve optics.
I’m fine with the solution, it will lead to higher voting rewards on people taking part in governance, but I don’t think the messaging and expected outcome behind the proposal is accurate.
For phase 2, I like it but I think it needs more discussions before a proposal is made on it. Phase 1 is definitely tied into Phase 2, but they should not go up for voting at the same time in my opinion. Phase 2 needs more time to make it the best it can.
Thanks for the proposal and discussions @SunnyLu!
2 Likes
To Reheat:
The ultimate purpose is to make the voting power be active and responsible.
As citizens, you can choose to be active or you choose some people you trust to cast active votes for you to make your voting power active.
In terms the first part, actually the definition of “active votes” need to be updated due to some technical constraints and I will update the proposal ASAP - the idea is to start from simple but can be iterated later based on results and feedbacks. But ultimately, the solution relies on Navigator who has capability and willingness to cast active and responsible votes.
In terms of token distribution, the purpose never changes - the community with token (voting power) is the one to make the decision how to allocate the tokens for the best of ecosystem growth.
In terms of “abstain”, I have replied to multiple people and I will repeat here again:
- I still believe abstain is the option we shouldn’t take out from the users
- The reward change will drive users to move to Navigator who will make the part of voting power useful and valuable other than just being “lazy”
- Yes, there will be still some (or even many) lazy votes out there who don’t want to make any changes - but I believe VeDelegate can be motivated to be the Navigator as well - then the voting power from those “lazy votes” can be useful and valuable through VeDelegate.
Thank you all for the feedback and comments. Based on the discussion, the proposal has been updated as follows:
Proposal Summary
This proposal introduces a two-phase upgrade to VeBetterDAO governance aimed at improving voting signal quality, capital allocation efficiency, and ecosystem adaptability.
- Phase 1 refines incentive structures to better reward active participation and explicit governance intent.
- Phase 2 introduces a voluntary delegation framework that enables transparent Navigators to curate weekly allocations and improve governance expertise at scale.
The proposal preserves user sovereignty, minimises participation friction, and strengthens governance outcomes as the ecosystem grows. All numerical values referenced herein are intended as initial parameters and may be adjusted through future governance proposals.
Rationale
Current governance participation demonstrates high nominal engagement but comparatively low effective signal quality. In practice:
- Weekly allocation voting frequently remains unchanged across multiple rounds.
- New or high-performing dApps face structural disadvantages in discovery and capital allocation.
- Governance proposal voting exhibits high abstention rates, limiting decision clarity.
These dynamics indicate a misalignment between governance incentives and meaningful participation. This proposal addresses these issues through targeted incentive refinement and optional delegation, without introducing custodial risk or centralised control.
Detailed Specification
Phase 1: Introducing Freshness & Governance Intent Multipliers
Objectives
Phase 1 aligns reward distribution with active governance behavior by:
- Encouraging regular reassessment of weekly voting configurations.
- Differentiating between active decision-making and passive participation.
- Improving the informational value of both allocation voting and proposal voting.
Weekly Voting: Freshness Multiplier
Problem
Static voting configurations weaken weekly allocation voting as a signaling and discovery mechanism, leading to inefficient capital distribution.
Mechanism
A Freshness Multiplier is applied to weekly allocation voting power based on how recently a voter updated their voting configuration.
Valid updates include adding and/or removing one or more dApps.
*Configurations that evenly distribute voting power across all available dApps do not qualify as valid updates.
Example: A user who adds a new dApp, removes an existing dApp, or does both within the same voting round is considered to have made a valid update.
| Update Frequency | Multiplier |
|---|---|
| Updated every round | 3.00× |
| Updated every 2 rounds | 2.00× |
| No update for ≥ 3 rounds | 1.00× |
*All multiplier values are initial parameters and subject to governance adjustment.
Expected Outcomes
This mechanism is expected to:
- Incentivise ongoing evaluation of dApp performance.
- Improve visibility for new and high-quality dApps.
- Restore weekly voting as an active governance signal.
Governance Proposal Voting: Governance Intent Multiplier
Problem
Governance proposal voting currently exhibits high abstention rates, resulting in limited governance signal despite high participation counts.
Mechanism
A Governance Intent Multiplier adjusts proposal voting rewards based on expressed intent:
| Vote Type | Multiplier |
|---|---|
| For / Against | 1.00× |
| Abstain | 0.30× |
*Abstain remains a valid option but receives reduced rewards.
*Multiplier values are initial parameters and may be updated via governance.
Expected Outcomes
This mechanism:
- Encourages informed participation.
- Improves signal-to-noise ratio in proposal outcomes.
- Aligns rewards with explicit governance decisions.
Phase 2: Introduction of the Navigator Role
Phase 2 introduces a voluntary delegation framework through which citizens may delegate their weekly voting decisions to trusted, transparent, and accountable Navigators acting on their behalf.
Objectives
The delegation framework aims to:
- Reduce inertia-driven voting behavior.
- Improve allocation consistency and quality.
- Enable informed, transparent curation at scale.
- Maintain decentralisation and user sovereignty.
Roles and Responsibilities
Navigators
Navigators are public voting agents who manage delegated voting power on behalf of citizens. Their responsibilities could be divided into system-enforced requirements and community-monitored expectations, reflecting the different enforcement mechanisms available.
System-Enforced Requirements
These responsibilities are objectively measurable by the protocol and enforced through system or smart-contract logic:
- Maintain the minimum required stake in the Navigator Pool;
- Participate in required weekly allocation and proposal voting, including updating voting configurations, on behalf of citizens.
*Failure to meet these requirements will result in automatic penalties or deactivation, as defined by protocol rules.
*The auto-vote feature will serve as the foundation for Navigator tooling, enabling a simplified user interface and reliable vote execution.
Community-Monitored Expectations
The following responsibilities are not fully enforceable by smart contracts and rely on ongoing community oversight and peer monitoring, including by other Navigators:
- Maintain a public profile describing voting philosophy and strategy (e.g. retention-focused, growth-focused, impact-focused);
- Publish historical voting behaviour;
- Provide full and timely conflict-of-interest disclosures, including compensation, token allocations, or advisory relationships with any dApp;
- Monitor, review, and publish a Navigator Report at least once every two rounds, covering, where applicable:
- Allocation rationale;
- Strategy changes;
- dApp performance insights;
- Recommendations for high-quality or newly emerging dApps.
These expectations are intended to support transparency, accountability, and informed delegation, and may be evaluated through community discussion and governance processes.
Citizens
Citizens may delegate voting power under the following guarantees:
- Delegation is initially limited to one Navigator per wallet per round, in accordance with technical constraints;
- Delegation can be withdrawn at any time, but will only take effect at the start of the subsequent round;
- Full ownership of B3TR is retained;
- Citizens receive standard voting rewards, subject to multipliers;
- Navigator fees are automatically deducted from citizens’ weekly rewards.
Navigator Onboarding, Activation, and Accountability Framework
Navigator Onboarding and Activation
Navigators are onboarded through a defined application and activation process designed to ensure transparency, accountability, and informed delegation.
Onboarding Process
Prospective Navigators must submit an application through a designated interface, providing at minimum the information necessary for citizens to make informed delegation decisions, including:
- A public profile and identifier;
- Voting strategy and principles;
- Full conflict-of-interest disclosures;
- Wallet address used for governance participation;
- A fixed Navigator fee rate (initially set at 20%);
- Public references (e.g. social or community links).
*Applications are publicly visible to support transparency and informed delegation.
Activation Parameters
To become active, Navigators are required to meet protocol-defined activation conditions intended to align responsibility with delegated influence.
Navigator delegation capacity is bounded by a stake-based mechanism, designed to:
- Limit excessive delegation concentration;
- Align long-term incentives;
- Provide economic accountability.
The required stake is deposited in B3TR and calculated as an amount equivalent to 10% of total delegated B3TR, subject to the following bounds:
- Minimum Stake:
- 50,000 B3TR;
- Corresponding to delegations up to 500,000 delegated B3TR.
- Maximum Stake:
- An amount of B3TR equivalent to 1% of total circulating VOT3 supply;
- Corresponding to delegations up to an amount of B3TR equivalent to a maximum of 10% of the circulating VOT3 supply.
*All staking and delegation requirements are fulfilled through deposits of B3TR tokens, which will be available as voting power for the Navigators.
*Specific thresholds, caps, and enforcement mechanics are subject to implementation design and may be adjusted through governance.
Dynamic Enforcement Logic
- If a Navigator’s delegation exceeds the allowed capacity, any additional delegations will remain inactive until capacity is restored.
- If required conditions are not met for a sustained period (e.g. seven consecutive days), the Navigator will be automatically deactivated.
- Upon deactivation, all delegations immediately cease to have effect.
*This mechanism ensures delegation remains bounded and responsive without requiring manual intervention.
Fee Handling and Locking
Navigator fees are derived from delegated voting rewards and are subject to a protocol-defined lock period.
- Fees are calculated automatically;
- Fees are locked for a fixed number of rounds (e.g. four);
- Fees become claimable only after the lock period expires.
*Fee locking aligns Navigator incentives with sustained performance rather than short-term behavior.
Rewards Distribution
- Navigators receive the predefined fee portion of delegated rewards.
- Citizens receive remaining rewards based on:
- the voting power delegated to the Navigators and actively used for voting;
- Applicable multipliers.
- Delegation does not alter base reward mechanics beyond the Navigator fee.
Accountability, Slashing, and Exit Conditions
Slashing Principles
Navigators are subject to protocol-enforced penalties designed to deter negligence and misconduct.
*Slashed funds are redirected to the VeBetterDAO Treasury.
Minor Infractions
Minor infractions that are objectively verifiable on-chain may be enforced automatically and may result in predefined penalties.
Severe Misconduct
Severe violations include, but are not limited to:
- Governance manipulation or bribery;
- Vote buying;
- Undisclosed paid relationships with dApps;
- Attacks on governance or protocol integrity.
Investigation and Enforcement Process
Potential cases of severe misconduct are subject to a governance-led investigation process designed to ensure fairness, transparency, and due process.
Key principles include:
- Community and peer monitoring as the primary detection mechanism.
- A defined investigation process, to be specified during implementation and subject to governance oversight.
- Public disclosure of findings prior to any final enforcement decision.
- Governance-based resolution, where major penalties (including removal or significant slashing) are determined through a formal governance proposal.
*The specific thresholds, procedures, and enforcement mechanics for investigations are intentionally left flexible to allow for careful implementation, iteration, and future refinement through governance.
Resignation and Exit
- Navigators must provide advance public notice prior to resignation.
- A final voting period may apply before exit.
- Stake and locked fees become withdrawable only after exit conditions are met.
- Re-entry requires a new application.
Initial Rollout Considerations
The mechanisms introduced in this proposal are intended to be deployed progressively and iteratively, subject to implementation readiness and governance oversight.
In particular:
- Phase 1 mechanisms may be introduced with monitoring periods to assess participation behaviour, governance signal quality, and unintended effects before any parameter adjustments.
- Phase 2 delegation features may be rolled out in stages, including initial limits on delegation capacity, Navigator onboarding, or feature availability, to ensure system stability and operational safety.
- Certain parameters or enforcement mechanisms may be introduced in a simplified or conservative form during early iterations, with additional safeguards or refinements added over time.
These rollout considerations are non-binding and intended to provide flexibility for careful implementation. All changes, adjustments, or expansions remain subject to governance approval and community review.
Conclusion
This proposal establishes a coherent, phased upgrade to VeBetterDAO governance.
Phase 1 refines incentive structures to align rewards with active participation and explicit governance intent, strengthening the quality and responsiveness of both weekly voting and proposal decision-making.
Phase 2 introduces an optional delegation framework through which transparent Navigators may exercise voting power on behalf of citizens, improving allocation quality and consistency while preserving decentralisation, user sovereignty, and non-custodial participation.
Together, these phases address current governance inefficiencies without increasing participation friction or centralising control. The framework improves governance signal integrity, supports fairer and more adaptive capital allocation, and creates a foundation for scalable, accountable governance as the ecosystem grows.
This proposal is designed to be iterative and governance-driven, allowing parameters and mechanisms to evolve over time while maintaining clear principles of transparency, accountability, and user choice.
2 Likes
Further Clarifications to the Proposal
Auto-Vote Feature
The auto-vote feature will serve as the foundation for Navigator tooling, enabling a simplified user interface and reliable vote execution. This feature is intended solely for operational convenience on a per-round basis, and Navigators are still expected to actively and responsibly update voting decisions.
Minor Infractions
Minor infractions that are objectively verifiable on-chain may be enforced automatically and may result in predefined penalties, initially set at 5% of the staked funds. These parameters remain subject to adjustment through governance.
Severe Misconduct
In cases of severe misconduct, applicable penalties will be proposed and decided through governance and may result in slashing of up to 100% of the staked funds, depending on the severity of the violation.