VePassport Activity Threshold Optimization to reduce impact of inactive voters
Proposal Summary
VeBetter DAO dApp allocations are impacted by passive voting patterns. Due to structural flaws in the current design, account voting eligibility can be artificially maintained, allowing inactive users to skew weekly dApp allocations away from genuine ecosystem engagement.
This proposal seeks adjustments to the VeBetterPassport action score and round window parameters to reduce the impact of these flaws. By updating minimum activity thresholds, it ensures voting eligibility requires continuous, genuine participation and keeps allocations aligned with the governance decision of active users.
Based on historic voting activity, proposed changes would remove ~30% of voters.
Proposal Type
- [X] On-chain Action
- [ ] Text-only Proposal
Proposal Changes
- Removed : None
- Modified:
-
VeBetterPassport contract 0x35a267671d8EDD607B2056A9a13E7ba7CF53c8b3 parameters:
action scorethresholdPoPScorefrom 300 to 400
round windowroundsForCumulativeScorefrom 12 to 4 -
Relevant VeBetter DAO documentation and Frontend
- Added: None
Motivation
The motivation for this proposal came from on-chain research on how inactive user voting eligibility is artificially maintained through monthly/weekly participation in governance and prolongation of voting activity through automated voting.
This proposal brings the opportunity to improve the quality of allocation results steered by genuine participation, reduce drainage of voting rewards to inactive wallets and voting automation services.
Detailed Specification
2 separate terms are used in the proposal - VeBetterPassport, when referencing smart contract 0x35a267671d8EDD607B2056A9a13E7ba7CF53c8b3,
and VePassport, when referencing the feature. This mirrors how DAO’s own documentation handles it.
A positive outcome of the proposal would require updating 2 parameters of the VeBetterPassport- action score thresholdPoPScore and round window roundsForCumulativeScore. Currently, for an eligible VePassport it is required to have at least 300 action score (3 actions) in the last 12 rounds.
Note: All VBD dApps are assigned a LOW security score yielding 100 score per 1 action for VePassport Proof of Participation. Any changes to how this is handled is out of the scope for this proposal.
All available dApp security levels:
NONE: 0 points
LOW: 100 points
MEDIUM: 200 points
HIGH: 400 points
Any potential future modifications to dApp security levels might require rebalancing of action score for VePassport Proof of Participation.
Current settings: 300 action score (3 actions) in the last 12 rounds (3/12 - 0.25 actions/round)
Recommended parameter settings: 4 actions in the last 4 rounds (4/4 - 1 action/round)
During the discussion of the proposal it was determined pairing action count with round lookback window is a much more easier concept to describe to new users - maintain 1 average action per round. 4 round lookback window allows to reduce the negative impact of inactive users by 3 times - from up to 12 rounds to 4 rounds, meanwhile maintaining a reasonable threshold for genuinely active users.
Impact simulations on voters
This table shows the potential impact VePassport adjustment would make looking back 12 full rounds. Retained user numbers are based on the VePassport simulator.
Voter data - Wallet Watcher, retained voters - VePassport simulator
VePassport simulator.
Impact simulations on app allocations
Highlighted impact simulations are for the 3 most recent full rounds. Round 117 was the first round no longer impacted by recently delisted 12 projects. Voter behavior is not static, hence the results vary from round to round.
Round 117
Round 118
Round 119
Documentation and frontend updates
Updates and optimization to documentation and frontend where exact parameters of Proof of Participation are referenced.
Goals
- Improve the quality of allocations
- Reduce the impact of voters with artificially maintained voting eligibility
- Increase the impact of participation
- Reduce the impact of inactive users
Risk Analysis
Risk: Not every investor is looking to participate in the VBD through dApp usage. Proposed VePassport parameter updates raise the bar of participation and increase the risk of reduced buy pressure.
Mitigation: Can be offset through Proof of Investment. A level 2+ (Moon) GM NFT holder is an eligible voter disregarding their participation (dApp usage) - Moon+ holders don’t need to use dApps at all to be eligible to vote and earn voting rewards. For users who do choose the participation route, the new bar remains realistic: it moves the requirement from 0.25 actions/round to 1 action/round - not a demanding threshold for a genuinely active user.
Risk: Reduced voter activity.
Mitigation: Artificially maintained VePassport voting eligibility and extended voting activity of inactive users distorts the results of allocation rounds. Reducing the impact of such participants gives more voting weight to genuine ecosystem participants and increases the voting quality.
Risk: dApps might lose votes.
Mitigation: While some dApps might lose votes, the overall quality of allocations will increase as genuine participants will have higher impact on governance decisions.
Success Metrics
- Reduced amount of voters who no longer participate in the ecosystem
- Re-aligning allocations with genuine voting decisions
Community Engagement
The proposal was discussed on Discord, Telegram and Discourse since 19th of September by multiple participants of VeBetter DAO ecosystem. The proposed modifications were updated to align with the overall opinion of the participants of the discussion.
Conclusion
According to simulator projections, roughly 30% of eligible voters do not actively use dApps, skewing funding allocations toward inactive participants. The proposed adjustments improve voting signal quality while keeping thresholds realistic.
References
Vepassport parameter simulator
Discourse discussion
Discord discussion
VeBetterPassport contract
VePassport documentattion
Community Framework Requirements
Implementation budget: 50 000 B3TR
Development Timeline: 2 voting rounds for updating referenced documentation and Frontend. The timing of parameter modifications is determined solely by the UPGRADER_ROLE holder.
Author Information
- Name: Reheat, Morb
- Contact Information: @ReheatVet @Morbidejs
- Vechain addreses: 0x7e64b0B68e2C353641681a5cb16d4c021f2dBaC6 0x0a9ac69482cf54862d4928f7db01f1056e7c1d21
**Date:**













