Proposal: Integrity Rule for In-App & Automated Voting

VeBetterDAO
21

@Morb Have you considered what will happen to the votes that the dApps already get through veDelegate as a result of auto-voting? Do the dApps have to un-vote them selves? If yes, a big percentage of those votes are from dormant/inactive users. What happens with all those votes? do they remain unused? Are they split equally to the rest of the dApps?

This also touches the “no Cast” on rule 3. Seems fair to not auto-vote without user consent but a lot of unused votes could be a downgrade to the ecosystem overall.

22

I agree with the underlying principle (no hijacking of user votes), but as it stands this proposal hits the wrong apps.

Rules 1, 3 and 4 are all user-burden: signed transaction for every change, UI must expose all endorsed dApps, default = abstain, forced equal redistribution. In practice:

  • A web2 user opening an app to recycle (or get cashback or whatever) / take a photo / scan something now faces a governance UI.
  • Apps that spent years perfecting mobile-first onboarding have to break their funnels.
  • Who pays the cost? The apps that bring real users. Who’s immune? The apps that never had a serious onboarding flow, because they don’t onboard anyone.

The proposal effectively rewards those who sit still and penalizes those who push users into the ecosystem.

Also, since VeDelegate supports social login now, it would be enough to link the user to veDelegate service if the user wants to know more or update those settings. I agree though that a “Learn more” section on those apps that explains where those rewards are coming from, what VeBetter is, how they can more actively participate it’s a must have.

It’s also treating the wrong symptom. The real problem on VBD today isn’t that apps “promote themselves”, it’s:

  1. Dilution: too many endorsed apps, per-app rewards keep shrinking.
  2. B3TR price in structural decline, zero buy-pressure.
  3. No link between distributed rewards and actual value delivered (new users, retention, on-chain tx).

The game today is “be in the top 5”, otherwise the B3TR you receive doesn’t even cover server and dev costs. Adding UI friction doesn’t move any of this, if anything, it makes things worse, because it raises the operating cost for the only people who are actually growing the pie.

Where I’m aligned:

  • Rule 2 (self-promotion bounds): pre-fill 100% for new users with no prior preferences, and capped pre-fill for existing users (weight ≤ any individual dApp in the user’s selection). This is a fair compromise, it lets apps participate in distribution
    without overriding what the user has already chosen.
  • Rule 5 (anti-bribery) and Rule 6 (fund neutrality): behavioral rules, not UI rules, and they make sense.

What I’d push to spend energy on instead:

  • Stricter endorsement criteria, to reduce dilution.
  • Allocation tied to objective value metrics (verified MAU, tx, retention) rather than who plays the voting mechanic best.
  • A real buy-pressure / utility / sink mechanism for B3TR.

But those should be food for thought for a separate discussion, which is a hard one, but that we need to have. The user-vote concern is legitimate, but it needs to be addressed without dumping the entire cost onto the apps that are holding the ecosystem up.

I have the feeling we are just playing here, adding rules on top of rules and making everything way to complicated on each iteration, instead of addressing and focusing on the real issues.

23

Good question.

Yes, it has crossed my mind, and I asked around privately for opinions and possible options, but no good solution came out of it. The short answer is - those votes gained through methods against the rules would stay as they are. If those are inactive users, their Vepasports would eventually loose voting eligibility (after 12 rounds).
If they are “lazy” voters, their impact can be addressed through different methods.

Even split between dapps is not neutral actually (as GAC pointed out), so I removed that part from the rules.

Unused votes might seem like a downgrade to the ecosystem, but on the other hand - unaware/“lazy” voters dilute the vote power of conscious voters.

24

Valid concerns and thoughts.

What encouraged me to start the discussion around in-app voting is not because I was bored and looked for ways to complicate things.

It stems from countless hours spent investigating on-chain data and seeing how lack of boundaries cripple the allocations and reduce the overall health of the ecosystem. The lack of morale when it comes to vote capture incentivizes apps to play dirty.

Offering in-app voting is a decision made by the dApps themselves. They don’t need to offer it at all. And governance is not forced on any vot3 holder. It is a decision, not an obligation.

Users are faced with governance only if:

  1. dApp decides to include in-app voting;
  2. User decides to participate.

In-app voting is not forced, onboarded users don’t need to participate in voting, therefore it is entirely up to the dApps themselves.

Same arguments as before - it is entirely up to the dApps themselves to include governance solutions or don’t, so costs are optional.

It is not a on dimensional result as the rules will apply to multiple scenarios. There are many variables to consider.

  1. VD wallets with ineligible vote preferences will no longer be able to vote for all apps equally, thus, less benefiting inactive/stale projects;

  2. dApps will no longer be able to set up voting wallets in behalf of users without their consent;

  3. No more overriding user vote preferences without their consent;

  4. Users are no longer funneled into 1 choice option.

All of these variables will contribute to more healthier allocations based on intent, rather than gamified in-app voting.

Apps already can add a “vote for us” section with links to governance page, Vedelegate, rather than funneling into 1 choice option.

Valid concerns/arguments, but not really the subject of this proposal. These can be addressed via other proposals and incentives.

I’m focusing on the problem I’m familiar with. I believe this contributes to healthier competition between dApps and more accurate voting results based on conscious decisions.

I believe even small improvements can benefit the DAO long-term, so I’m taking my shot with this proposal.

This proposal is not responsible for b3tr price, so the game you described would not change. As previously mentioned, in-app voting is optional, so dApps are not forced in any way to increase their operational costs.
But if they decide to, it should not come at the cost of voter autonomy and fair play.

I’m focusing on one thing at a time. Sure, it does not fall under the 3 points you mentioned, but I’m trying to contribute where I can.

25

I’d like to hear more thoughts on this from other participants in the discussion, especially dApp representatives.

26

I partially agree with @Dan on the last message, I think proposals should be more geared towards making the core dao dynamics better for the dApps and the end user and not imposing hard rules to the developers who try to develop products for the ecosystem. Think “adding” to the ecosystem rather than “removing” options from creators.

With that being said, dApp quality checks should be higher, and probably voting weights should take into consideration objectives metrics, not just user preference.

27

I agree with you in general - creating value is more important than imposing hard rules.

But when it comes to the rules outlined in my proposal, the motivation comes from seeing unethical behaviors from dApps themselves, making the competition unfair. Genuine, transparent projects are at a disadvantage. The weekly allocations are influenced by synthetic voters, in some cases who are not aware their capital is earning extra rewards in the background.
The lack of guidelines on the in-app governance incentivizes dApps to ignore the security and health of the ecosystem, in specific, farmers become active governance participants, reducing the voting rewards for genuine users and crippling the weekly allocations. Why would apps signal/ban farmers if they vote for the apps? This is not science fiction or theory, this is an ongoing problem.

Bear market is a great time to fix these fundamental problems so when the market takes off again, VBD ecosystem is healthier.

28

Integrity Rules: amendment to existing RuleBook for Apps

Proposal Summary

As VeBetter DAO grows, optimizing our governance interfaces is essential to ensure sustainable ecosystem health. This proposal introduces six structural rules for in-app voting, anti-bribery, and capital integrity. By setting clear standards for user consent and transparency, this framework protects user autonomy, fosters fair competition among dApps, and ensures that weekly allocations are driven by genuine user engagement.
This proposal ensures that all dApps, regardless of their size or interface mechanics, can compete fairly based on the true value they bring to the community.

Proposal Type

- [ ] On-chain Action

- [X] Text-only Proposal

Proposal Changes

- Removed: None

- Modified: None

- Added: Amendment to the RuleBook for Apps

Motivation

The motivation for this proposal stems from extensive ecosystem research into in-app voting behaviors and their impact on weekly voting rounds, and voter autonomy. Currently, the lack of standardized guidelines for voting interfaces creates an uneven playing field, where optimization tactics can overshadow organic user intent.

Detailed Specification

Rules are numerically structured to supplement the already existing RuleBook for Apps.

New proposed rules can be divided in 3 sections:

  1. In-app governance (Rules 5.1, 5.2, 5.3 and 5.4);
  2. Anti-bribery (Rule 6);
  3. Capital integrity (Rule 7).

In-app governance establishes clear baseline standards for dApps integrating in-app governance services. By regulating user interface design, self-promotion parameters, and vote redistribution mechanics, these rules prioritize user autonomy and ensure a transparent, level playing field for all ecosystem participants.

Anti-bribery section safeguards the integrity of the voting process by prohibiting conditional rewards. By restricting the use of manual incentives, localized multipliers, or gated perks tied to specific voting outcomes, these standards ensure that community support is earned through utility and project merit rather than compensation loops.

Capital integrity guidelines establish clear boundaries for the use of VeBetter DAO Treasury and weekly allocation resources. dApps are prohibited from using grant or allocation funding to influence weekly allocation rounds, while maintaining full exemptions to support and vote on governance proposals.

5. In-app governance

5.1. User-Affirmed Governance & UI

User Confirmation: Any modification of user vote preferences must be executed through a clear, user-signed transaction. Background updates without a dedicated user-confirmed transaction are prohibited.

Visibility of Choice: The UI must display all endorsed dApps, ensuring users can modify selections for any project before confirmation.

Opt-Out Requirement: dApps must provide a visible UI component to opt out of the governance service at any time.

Conversion Allowance: dApps may include a function to convert B3TR to VOT3 when a user initiates in-app voting as long as such transaction is disclosed and confirmed by the user.

5.2. Self-Promotion

dApps may prioritize themselves in the interface and pre-fill vote preferences as follows:

New Users: If no existing preferences exist, the dApp may pre-fill with 100% weight toward itself.

Existing Users: The dApp may add itself to the list, provided its pre-filled weight is lower than or equal to any individual dApp in the user’s new selection.

Rule 5.3. True Neutrality

If a dApp provides governance services and the user opts in without specifying preferences, or preferences become ineligible, the following defaults apply:

App Allocation: No vote shall be cast until the user explicitly confirms a selection through a signed transaction.

Proposal Voting: DAO-wide proposals must be set to “Abstain.”

Rule 5.4. Vote Redistribution

Weight Redistribution: If a dApp in a user’s preference becomes ineligible, its weight must be redistributed equally among the user’s remaining selected dApps.

Redirection Prohibition: dApps cannot redirect weight from ineligible projects to the host dApp or any project not explicitly included in the user’s most recent confirmed selection. If all projects become ineligible in the user’s selection, Rule 5.3 applies.

Vote modifying: dApps are prohibited from modifying a user’s existing vote preferences, including the addition or removal of eligible projects, except where explicitly required by the redistribution logic defined in Rule 5.4 (Weight Redistribution and Redirection Prohibition), and according to self-promotion described in Rule 5.2.

Exemption: Rules under section 5 apply to all in-app voting integrations unless limited by the functional logic of the native VBD auto-voter, as its automation and logic are subject to DAO governance and community contributions.

6. Anti-Bribery Measures

dApps may not offer manual rewards, “x2earn” multipliers, or any perks that assist in unlocking them if such incentives are conditioned on the user voting for that specific dApp.

7. Capital integrity

dApps are prohibited from using allocation and grant funding received from the VeBetter DAO Treasury to vote in weekly dApp allocation rounds.

Exemption: dApps maintain the right to use Treasury grant funds and allocation to support and vote on proposals.

Goals

  • Improving voter autonomy;
  • Creating a level playing field between dApps in vote acquiring;
  • Re-aligning weekly dApp allocations with voter intent.

Risk Analysis

Risk: Additional development costs
Implementation of these rules may introduce additional expenses for dApps that choose to update or maintain custom, in-app voting user interfaces.

Mitigation: Custom in-app voting interfaces are entirely optional features, not protocol-level requirements. dApps remain free to direct users to the native VeBetter DAO governance interface at zero cost. Any development expenses incurred are a localized business decision made by the dApp team to provide a customized user experience, rather than an infrastructure-mandated expense. The protocol ensures a free alternative by hosting the native governance portal and open source auto-voter, allowing any dApp to remain fully compliant without spending internal development resources.

Risk: Potential Reduction in Voter Acquisition
By restricting automatic pre-filling and un-disclosed vote loops, dApps may experience a decline in the raw volume of passive, automated voters routed through their platforms.

Mitigation: While nominal voter counts may adjust, the users retained will be high-intent, active participants who consciously choose to support the dApp. Eliminating passive, low-engagement voters improves long-term ecosystem stability and ensures that community metrics reflect genuine product utility rather than artificial interface routing.

Risk: Added friction to voting
Requiring a clear, user-signed transaction for every modification or preference setup and preventing automated defaults means users have to click and sign more often. This added friction might cause casual users to stop voting altogether in weekly rounds, leading to lower overall DAO voter turnout.

Mitigation: This risk is naturally offset by the Universal Exclusion, which protects the native VBD auto-voter. Users who experience fatigue can easily opt into the native protocol-level automation. Furthermore, the friction introduced is a feature, not a bug - it ensures that votes represent high-intent, conscious community decisions rather than passive clicks.

Risk: Enforcement requires manual oversight
Because these rules govern the frontend user interface of independent dApps, checking for compliance cannot be fully automated on-chain. This creates an ongoing monitoring burden for the community to ensure no one is breaking the interface rules.

Mitigation: Because the dApp environment is competitive and transparent, project teams naturally audit one another. If a dApp violates the rules to gain an unfair advantage, fellow builders and community members can easily publish proof and initiate a blacklisting proposal. VeBetter DAO has seen multiple community proposals to remove projects breaking the rules.

Success Metrics

The success of this proposals will be determined by 2 off-chain metrics:

  1. Responsiveness of the dApps;
  2. Community oversight.

Enforcement and grace period

Grace period: Affected projects enter a formal 4 round grace period after the proposal is marked as complete to comply with the new rules.

Enforcement of the new rules relies on fellow project and community oversight.

Community Engagement

The discussion over these new rules have been ongoing for 2 months on Discord and Discourse, involving active community members, dApp representatives and Vechain developers. Author has modified the rules based on the received feedback, making sure they align with the majority of the participants of the discussion.

Conclusion

This proposal focuses on a simple shift: ensuring that VeBetter DAO treasury funding follows authentic user choices. By introducing clear boundaries for in-app interfaces, anti-bribery measures, and capital usage, we replace passive or manipulated voting loops with explicit user intent.

The benefits of these updates are straightforward:

  • True User Autonomy: Users regain full visibility and control over their voting power, with no unexpected background updates or hidden default choices;
  • A Level Playing Field: Honest dApps will no longer be at a disadvantage against aggressive interface optimization tactics or synthetic voting loops;
  • High-Integrity Treasury Distribution: Weekly allocations will more accurately reflect genuine community engagement and project utility, rather than exploitative automation.

References

Existing RuleBook for apps
Discourse discussion
Discord discussion

Community Framework Requirements

Maximum Implementation Budget: 11 500 B3TR

Development Timeline: 2 voting rounds (for GitHub PR submission, text integration, and VeChain Foundation technical review).

Author Information

- Name: Morb

- Contact Information: @morbidejs at X and Discord, morbidejs@gmail.com

- Vechain address: 0x0a9ac69482cf54862d4928f7db01f1056e7c1d21

29

Added a new section.

30

Proposal is live and looking for your support!

31
32

@Dan @VeChain-Grant-Team

Could you please forward to whoever is responsible to mark the proposal as “complete”?

Thanks!