VePassport Activity Threshold Optimization to reduce impact of inactive voters

[Morb]

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 ~40% of voters.

Proposal Type

- [X] On-chain Action

- [ ] Text-only Proposal

Proposal Changes

- Removed : None

- Modified:

1. VeBetterPassport contract 0x35a267671d8EDD607B2056A9a13E7ba7CF53c8b3 parameters:
   action score thresholdPoPScore from 300 to X
   round window roundsForCumulativeScore from 12 to Y

2. 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: Currently 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:

a) Sensitive - 5 actions in the last 4 rounds (5/4 - 1.25 actions/round);
b) Middle-ground - 7 actions in the last 6 rounds (7/6 - 1.16 actions/round);
c) Sustained activity - 10 actions in the last 8 rounds (10/8 - 1.25 actions/round).

Requiring at least one action more than the round count closes the loophole where purely weekly, non-sustainability rewards can maintain voting eligibility just by matching the round cadence, forcing to inject an extra, irregular action each cycle, which stands out against a steady weekly pattern instead of blending in as normal activity.

Impact simulations

This table shows the potential impact each VePassport adjustment would make looking back 10 rounds. Retained user numbers are based on the VePassport simulator. Voter count and % in the brackets show retained voters with proposed modifications.

Total voter data - VBD stats, retained voters - simulator. Expected margin of error ~1%.

VePassport simulator.

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.16–1.25 actions/round - averaging little more than one sustainable action per week, 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 power to genuine ecosystem participants.

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

Subject to updates based on the course of this discussion.

Conclusion

According to simulator projections, roughly 40% 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:**

[Morb]

This proposal draft is subject to change based on the course of discussion and shared opinions by the participants.

Open question: Which parameter set achieves the most impact, without introducing too strict rules?

Recommended modifications

5 actions in 4 rounds. The simulations show the difference between different proposed sets of modifications have a similar impact (59% to 60.6% retained voters). While this being true, the 5/4 preset is the most sensitive to changes in voter behavior.

Example - inactive voter

Voter has enabled automated voting. The user leaves the DAO (stops using apps). Currently 3 actions in 12 rounds threshold prolongs impact of such voter for up to 12 weeks. The recommended 5/4 preset would reduce potential negative impact of such voters 3 times (from up to 12 rounds to only up to 4 rounds), increasing the quality of voting signals.

The recommended set requires 1.25 actions on average per round, while the current parameters require 0.25 actions/round. The quality of voting signals is increased, while keeping the action count realistically achievable for non-frequent app users.

Example - impact simulations for different voter groups

Round 115
Total voters: 9713
Parameters: 5 actions in 4 rounds
Disqualified: 4140

Quadratic Funding (QF) impact

Disqualified excluding lock-2-earn terms: 3406
QF impact

Disqualified regular VeDelegat voters: 2141

QF impact

Disqualified dirct voters (VeDelegate and lock-2-earn terms excluded): 1265

QF impact

Disqualified lock-2-earn terms: 735

QF impact

Simulator

Created specifically for this proposal to project potential impact each parameter change would have on valid Vepassport holders (both, all valid Vepassport holders and active voters only).

All wallets window - shows all eligible Vepassport holders (voters and non-voters), general information.
Voter impact - shows impact on voters who participated in voting rounds, actual impact.

Min distinct apps - currently, no such setting exists when checking for Vepasport voting eligibility. Introducing this setting would require updating the Vepassport contract and is out of the scope for this proposal. Added for general research purpose.

Click on any round bar to access detailed stats.

Detailed stats consist of voter groups:

All - with live parameters;
Disqualified - non-eligible current voters;
Eligible - retained voters;
GM-Exempt - Proof of Investment exemption (live parameter);
veDelegate - all current voters with VD staking wallet;
Lock2Earn - all current voters with l2e terms;
Direct - all manual voters.

As always, proper research would not be possible without the Wallet Watcher, intelligence layer built by Reheat.

[GreenAmbassador]

I am personally against this since it does not consider how my application operates.

Actions on my platform can take 30/60 minutes, it simply takes way longer than snapping a quick picture every day. The recommended parameters would probably result in users of just my platform won’t be able to ever vote anymore. Especially since I would also then have to have more than one new course release every week, that is not sustainable.

Simply said, this proposal passing in its current form would be the end of my platform.

Requiring at least one action more than the round count closes the loophole where purely weekly, non-sustainability rewards can maintain voting eligibility just by matching the round cadence, forcing to inject an extra, irregular action each cycle, which stands out against a steady weekly pattern instead of blending in as normal activity.

This is the root issue that imo needs to be fixed, add to the rule book that non-sustainability rewards should not count towards the actions required to keep an account alive.

If you adjust your proposal:

1. so non-sustainbility rewards no longer count towards an voting action
2. consider that the duration/impact of each action is not equal
3. adjust the parameters to be closer to the current settings and way less aggressive (and there will be less need for this if we implement (1).

I would be able to support this proposal

[Morb]

Additional impact on historic rounds with 5a/4r settings.
Graphs indicate Quadratic Funding weight of disqualified voters.

Round 114
Disqualified: 4241

Round 113
Disqualified: 4249

Round 112
Disqualified: 4118

Round 111
Disqualified: 4163

Round 110
Disqualified: 3472

Round 109
Disqualified: 4509

Round 108
Disqualified: 4553

Round 107
Disqualified: 4668

Round 106
Disqualified: 4581

[Morb]

Hey,

There are many floating variables from round to round impacting voting results - VD’s 1k+ wallets mirroring their navigator, Sunny’s navigator with ~6m vot3, mass signaling of voting farmers (Veducks). So, the effect and who gets affected the most will change. And past performance does not guarantee future results.
This proposal is about what is the best net-positive impact on the whole ecosystem. Yes, some apps will lose, some will gain.

@GreenAmbassador

1. so non-sustainbility rewards no longer count towards an voting action

This is already addressed here feat(contracts): X2EarnRewardsPool V9 - separate sustainable from bonus rewards by Agilulfo1820 · Pull Request #3398 · vechain/vebetterdao · GitHub

Maybe best if we ping @dan and ask what is the progress there.

@GreenAmbassador

2. consider that the duration/impact of each action is not equal

This is absolutely true. And to address this it would require firstly looking at dApp security levels. Out of scope for this proposal.

@GreenAmbassador

3. adjust the parameters to be closer to the current settings and way less aggressive (and there will be less need for this if we implement (1).

5 actions in 4 rounds or an action per round + 1 every 4 rounds I’d say is a very low barrier of entry to be eligible for voting. But it is noted.
Do you have other settings in mind? The simulator allows to quickly see the impact any modification would make.

And to address Terrademia case in specific.

Yes, this proposal would significantly reduce the amount of eligible ~1.5k managed wallet users with auto-voter and Terrademia as the only app they vote for. And it would not be possible to maintain this eligibility long-term considering sub 1 new course/week.

On the upside - your managed wallet users are welcomed to explore other apps. I think it would be a big benefit to the whole ecosystem if we gained 1.5k multi-app users.

Other option would be to introduce 1 new course weekly. Yes, I understand, the quality bar for your courses is high and takes time to develop. Maybe sourcing a writer/researcher from the DAO is an option for the future? We have many capable community members.

Also, the QF impact from to round changes, it is a variable, not a fixed state. In some rounds you win, in some - lose. Same as with other apps. I think the main question here is - what is best for the DAO as a whole long-term? We might lose less active voters, but the vote power of active participants increases.

But everything you said is noted and those are valid concerns. It is understandable you’re looking for what’s best for your users and Terrademia.

[Morb]

I looked closer at managed wallet system on Terrademia platform.

These are the findings.

Round 115

Users with auto-vote enabled, votes and proofs only on Terrademia platform: 1435

Terrademia automatically enabled auto-voting and set vote to 100% for the platform.
Source: Managed Wallets - Docs

What is mentioned in the managed wallet docs is supported by on-chain activity.
Managed wallet transactions are clustered in short time-frames.

Example transaction from the screenshot: 0xe11d236597762e0a3a56471c4db530ee54ae4a35ec39a311641355453858e84f - Vechain Transaction

Managed wallet impact can be witnessed by looking at historic support for Terrademia. Out of 1435 voters in round 115, only 15 voted in round 100.

Source: veDelegate.vet

While there are nuances and technical differences, this setup is similar to VD’s l2e terms, Evearn, BYB (delisted).

VD - l2e terms with no vote preference vote for VD with 100%, disclosed in the docs
Evearn and BYB - undisclosed voting for the host platform (user creates an account, there’s a VD wallet spun up with set 100% for the host app)

Terrademia uses different technical approach - instead of VD, they utilize the VBD auto-voter for managed wallets. If a user chooses a managed wallet, Terrademia automatically toggles on the auto-voter and sets the vote 100% for the platform. And this is clearly disclosed.
Important: recently they updated managed wallets to comply with Integrity Rules
Source: Full account control

It is unclear what will happen to vote preferences of managed wallets created before this update went live.

Votes coming from managed wallets set up before the update are biased towards the host app. These votes don’t represent “what’s best for the ecosystem”, but “what’s best for the platform”. The decision to participate in the governance was not explicitly made by the user of managed wallet. While the waiver of governance rights were disclosed, such voting activity does not represent the decision of an individual. Rather it’s a legal way how to manage one’s governance.

Because managed wallet votes reflect self interest of the host rather than users assessment of the ecosystem, reducing the impact coming from such votes achieves the goal of the proposal to increase quality of voting signals. The proposed settings were not previously planned to target this specific setup, but this case shows modifications to Vepassport can have a broader effect.

[Morb]

After some comments from Orbit, Sanne and Genesis, a new average of 1 action/round was proposed as it is more relatable and easy to explain “do 1 action per round”.

How does 4/4 sound? It is less aggressive compared to 5/4, while still sensitive to a user leaving the ecosystem or lacking participation.

While it will not address the weekly rewards not tied to sustainable actions, there are other mechanics to tackle that.

[Morb]

Reheat added new data to the simulator - Quadratic Funding impact.

To view impact on allocation:

1. Click on any round bar;
2. Click on App Allocation (QF);
3. Modify parameters and switch rounds in top left side;
4. Click on metrics to view the impact in ascending/descending order.

Description of each metric

• Baseline share - QF share with current (live) settings;
• Proposed share - QF share with modified settings;
• Share shift - QF share difference (from the total pool);
• Relative % - the relative gain/loss of the share in QF pool;
• Supporters retained - voters retained with modified settings/voters with live settings and % of retained voters;
• Allocation shift - visual representation of allocation impact.

Simulator does not show exact allocation with modified parameters and does not factor in Dynamic Base Allocation.
The max cap of QF is 18% - overflow above 18% goes to DBA pool. If none of the apps reach the 18% ceiling, there is no overflow, thus no DBA. This is an existing mechanic and not a subject of this proposal.

Small-support apps can show 0.00% share shift purely due to rounding to two decimals, while their relative % still reflects the underlying nonzero change.

[Morb]

After public discussion on Discord and Telegram, it was suggested to focus on a 1 action per round average, specifically highlighting structurally different concept - eligible to vote in round n, if action ≥1 in round n-1.

Current simulator projections don’t have this specific Proof of Participation formula. The closest I could get is a 1/1 scenario, where the lookback window is 1 round, disregarding if it is round n or n-1 (previous). While not an exact copy, it gives at least some sense on the impact.

Voter retention

New projections with different modifications with a 1 actions/round average.
Round 117 - not finished, so the data is not entirely accurate. Will update the table once a new round starts.
Round 113 - Mugshot leaderboard rewards

What immediately stands out:

• 1/1 is significantly more volatile compared to other modifications (r117 excluded)
  
  
• Volatility decreases the wider the lookback window - 7.15% for 4/4 and 5.41% for 12/12;
• In round 113 1/1 saw it’s highest retention, meanwhile the rest of the modifications did not see any significant change;
• In round 110 1/1 saw it’s lowest retention, meanwhile other modifications - their highest retention (reason unknown, will be investigated).

Allocation impact

The most interesting part is the allocation impact. While not the target of this proposal, VePassport parameter modifications impact specific scenarios and voter behavior.
As 12 dApps recently got delisted, historic data regarding allocation impact does not represent an accurate scenario, and we’re yet to see a full voting round without delisted projects.

VeDelegate lock-2-earn terms

As VD l2e terms send one weekly proof, there’s a significant difference when action average >1. With 1a/1r average, VD loses ~5% in allocation. Moving this average above 1, the relative shift of VD’s allocation skyrockets , consistently hovering above -50%.
This highlights the specific setup how voting eligibility is maintained for l2e terms.

Biggest hit on managed wallets

Data indicates, no matter the proposed modifications, consistentt hit is taken by apps with managed wallet systems - Terrademia and Evearn. Their average loses are around ~20%, in some cases reaching staggering -40% relative shift.
This clearly showcases the flaws of reliance on setups where voting is not explicitly initiated by the user.

---

[Morb]

Simulator got updated with round 117 data!

This is the first realistic glance at allocation shift after the delisting of 12 dApps.

Round 117, 4 actions in 4 rounds

Retained voters: 6548 (69%)
Note: 18% allocation cap not reached (no DBA)

Proposed allocation share

Relative % lost

Relative % gained

[Morb]

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:

1. VeBetterPassport contract 0x35a267671d8EDD607B2056A9a13E7ba7CF53c8b3 parameters:
   action score thresholdPoPScore from 300 to 400
   round window roundsForCumulativeScore from 12 to 4

2. 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:**

[Morb]

Proposal is seeking community support.

VePassport Activity Threshold Optimization to reduce impact of inactive voters...

[Morb]

Saved voting rewards

117

Disqualified: 2940 voters
Voting rewards: 81 700 b3tr (8.42%)
Excluding l2e: 64 000 b3tr (6.60%)

118

Disqualified: 2808 voters
Voting rewards: 79 700 b3tr (8.22%)
Excluding l2e: 61 100 b3tr (6.30%)

119

Disqualified: 2709 voters
Voting rewards: 73 300 b3tr (7.56%)
Excluding l2e: 60 700 b3tr (6.26%)

Average

Disqualified voters: 2819
Voting rewards: 78 233 b3tr (8.06%)
Excluding l2e: 61 933 b3tr (6.38%)

[Morb]

fix(skills): update VePassport participation threshold to 4 actions in 4 rounds (#40)

fix(docs): update Proof of Participation threshold to 4 actions in 4 rounds (#8)

feat(frontend): add VePassport activity threshold announcement banner and modal (#3579)