Proposal: Integrity Rule for In-App & Automated Voting

VeBetterDAO
1

Initial version of proposal. Will be updated upon receiving community feedback.

The Problem

Several dApps are utilizing “auto-voting” and “in-app voting” (also called as staking, earning more, boosting rewards) features to capture user voting power for themselves, leading to:

  • Undisclosed Management: Creating VeDelegate accounts for new users and auto-allocating votes to the host app without explicit consent.

  • Lack of choice: new users are funneled into 1 app choice, stripping away the opportunity to make a conscious governance decision.

  • Hidden/undisclosed vote preferences: Existing VeDelegate users` vote preference is set to the host app without explicit consent.

Proposed Off-Chain Rule Amendments

To improve the quality of voting decisions, I propose the following updates to the VBD Rulebook:

1. Prohibition of Self-Preference and Pre-Selection

Apps are prohibited from setting or resetting a user’s voting preference to themselves—either in part or in full—or to any specific combination of apps. Users must maintain full autonomy over their delegation at all times.

2. The “Neutral Default” Standard

If an app provides a “one-click” staking/voting feature and the user does not manually select a preference:

  • The vote must be distributed equally among all currently endorsed apps in the ecosystem.

  • This ensures “passive” liquidity supports the entire DAO rather than a single entity.

3. Anti-Bribery Measures

Apps may not offer rewards, multipliers, or exclusive features conditioned on the user voting for that specific app. Rewards must be based on verified sustainability impact, not governance “kickbacks.”

Risk Analysis: Current Methods

Auto-Voting (Managed)

Funds managed without consent; Dilution of vote power of conscious voters, users have no autonomy over their delegation.

In-App Voting (User-Led)

Users are funneled into “earning” without knowing their vote is being harvested; Manipulation of existing VeDelegate wallets.

Implementation Pathways for dApps

To comply with these rules, dApps would need to:

  1. Equal Distribution: Default all automated voting to be split equally across all endorsed dApps.

  2. Conscious Choice UI: Update the interface to display all eligible apps, requiring a manual user selection.

  3. Removal: Disable auto-voting/managed voting features entirely.

Examples

Allowed

  1. Prefilled vote preference, while having all eligible apps in the UI.

  2. No voting UI, vote preference set to all eligible apps equally.

  3. A user subscribes to voting services, but has not set voting preference; apps are allowed to change the vote preference to all apps equally if it requires them to provide the service user has subscribed to.

  4. A reward multiplier for active participation in governance without limitations on vote preferences.

Not allowed

  1. Undisclosed vote automation of a new user.

  2. Vote automation of a new user, disclosure not clearly visible during the setup of an account.

  3. User subscribes to a voting service without setting a vote preference, app is not allowed to change their vote preference to any combination of apps, unless the preference is set to all apps equally.

  4. In-app voting UI provides only a selection of eligible apps.

  5. In-app voting UI provides only an option to vote for 1 app with a selection of percentages/vote weights.

  6. A reward multiplier for voting for specific app/s.

Discussion & Enforcement

This proposal is intended to spark a conversation between the community and dApp owners.

  • Grace Period: A recommended 4 rounds for apps to update their UI/logic.

  • Monitoring: Community-led monitoring of on-chain data and manual UI audits.

Enforcement: Non-compliant apps may face a governance proposal for removal from the ecosystem.

3 Likes
2

Just a few first thoughts by myself.

I think it should be:
User lands on app #1 → enables staking/autovoting → the app checks “is this user voting for any other app?”
No → sets 100% for itself
Yes → adds itself, without removing any of the previous apps

All the apps in the list gets proportional voting.

The user must be able to change those settings (in veDelegate), without the app touching updating them without the consent (again) of the user.

I wouldn’t make it too hard honestly because I can get why an app, that has this “staking” solution and its successfull bring those votes to themself, at the end of the day the app deserves it. For example: I create an app that works also outside veworld; I publish it to the store and it gets 10K users, that use only my app, which has staking. It’s ok in my opinion that those users vote only for my app. But once one of those users joins veworld, uses another app that also has staking, then my app and that app should split his vote.

In-app voting UI provides only a selection of eligible apps.

In-app voting UI provides only an option to vote for 1 app with a selection of percentages/vote weights.

It makes sense, but until there is some way (even by redirecting to another website, vedelegate, or some other place) to change those options, I wouldn’t make it mandatory that they must be “in app”. Just because each app is different, and this could add complexity for users that do not undestand those concepts.

1 Like
3

Hey, @Dan

Appreciate the comment. A lot of detail needs to be considered regarding what you said.
In overall I agree with you - apps onboarding new users to the DAO should be rewarded and encouraged for their efforts.
I do want to emphasize the reduced friction in governance participation should not come at the cost of users’ autonomy over their decisions.

It sounds logical on the surface, but there are a lot of nuances to consider.

To fully reply to this, we need to look at the current in-app voting infrastructure.
In most cases (apart from 2 I’m aware of) in-app voting is a form of integrated third party service (Vedelegate).

When a user initiates in-app voting:

a) with existing VD account - vote preferences are overwritten;
b) without a VD account - VD account is created in behalf of the user, vote preference is set for the user.

A user with an existing VD account is:

a) owner of an account (regular wallet) who has full access to VD dashboard to change his vote preferences (if no preference is set by the user, VD sets it to themselves);
b) social login contract, no access to VD dashboard, not able to adjust his vote preferences.

So, in your scenario, when an app is checking “is this user voting for any other app?” and answer is NO:

We’re strictly looking at new users with social login contracts or a regular wallet without a VD account.

If it’s a:
social login contract, we end up with the reason why I made this proposal in the first place - user has no autonomy over his vote preferences, he is funneled into a 1 choice option, in some cases this is done automatically without the user ever knowing he is voting for the host app;
regular account, user might not be aware there’s a VD account spun up in the background in behalf of him and the possibility to change the vote preference through VD dashboard, app is funneling the user into a 1 choice option.

In both cases app is harvesting votes due to lack of interest/knowledge of a user in combination with no voting UI, contributing to predatory practices.

If the answer is YES and app adds itself to the vote preference, 2 problems arise:

  1. Adds additional complexity to the rules to determine, what is acceptable and what is not;
  2. Reduced autonomy of a user`s governance decisions.

Yes, I agree. Apps deserve votes from the onboarded users. With that said, this should not come at the expense of reduced autonomy of a user`s governance decisions.

Users should have the autonomy to decide for themselves at all times. If a user is stripped from a choice, such practices would contribute to predatory tactics to acquire votes.
A vote acquired based on one dimensional metric (usage of an app), contributes to distorted weekly allocation. Especially when such vote comes from unaware voters lacking knowledge/interest in the DAO.

Th DAO is steering towards rewarding conscious decisions (freshness multiplier) and highlighting apps based on multiple metrics (merit-based reputation layer).
This proposal is a natural move towards a more decentralized direction DAO is already shifting to.

In simple words, we should not contribute to conditions, where user is forced to vote for 1 or multiple apps based on 1 metric. It is his decision. Apps should not exploit a users lack of ability to decide.

Solutions

image
image505×1024 120 KB

This is an example UI for a native VBD auto-voter integration:

  1. Complies with the new rules;
  2. Host app is highlighted (100% prefilled);
  3. User has full voting autonomy (all eligible apps available, can change relayer);
  4. Change preferences/opt out at any time through host app or VBD governance page;
  5. Does not add friction to voting.

Apps are encouraged to onboard new users to gain more voters, while voters retain their voting autonomy. As all variables are prefilled (disclosed 100% to host app, preferred relayer, auto-vote enabled), it does not add to the complexity of “earning more”.

Apps with VD integration can set the neutral default (vote divided to all eligible apps equally, does not affect allocation results).
This allows them to immediately comply with the new rules until they decide to:

  1. Improve the UI for existing VD integration;
  2. Integrate native VBD auto voter;
  3. Remove in-app voting completely.

Sorry, did not fully understand this part. You quoted 2 scenarios from “not allowed”. Could not connect the dots.

2 Likes
4

I will vote Yes to that if it comes into proposal. Forcing user into premise without a presenting other choices is a No in my book.

Love the UI proposed template. Something like that would lead to a concious choice / def. more informative for user.

3 Likes
5

Appreciate the support!

This will certainly be submitted for support, but I am in no rush. Need to gather more feedback and adjust accordingly. Also, this might not be a very popular proposal, and at first it might look as a big disadvantage to apps, but in reality it creates a fair playing ground and benefits the overall decentralization.

3 Likes
6

You are right, I didn’t think of the fact that VeDelegate does not support social login connection.
Then I agree with you, those users are locked in, so the app needs to allow the user to:
a) disable all
b) change preference of apps that are being voted

I think if we push a bit more on the native autovoting of vebetterdao and apps migrate to that solution it would be the best, because a user would just login into vebetter (not another external app) and will be able to fully join the ecosystem, disable autovoting and so. But for this to work we need to enable a form of compounding (convert b3tr to vot3 for the user) that now is missing in the vebetter autovoting, and my understanding is that this is crucial for the apps.
So until veDelegate adds social login, if an app is using social login + staking, then I agree, they must provide a way for the user to change preferences or opt-out.

Anyway, I think it’s important that ones the user takes control over his wallet/voting decision, the apps MUST NOT INTERFEER with it, if not explicitly asked by the user. Example: user lands on evearn, autovoting is enabled, user goes to vebetterdao/vedelegate, changes settings or whatever, then evern cannot change settings back to vote only evearn. It must be something decided by the user.

Well for me this should be MANDATORY. You cannot just say “fuck it, i will just override the preferences to vote only my app”. You should be able just to add yourself on top imho.

Reduced autonomy of a user`s governance decisions.

I understand this, but the user in the first place doesn’t know anything about vebetter or maybe doesn’t want to. It’s true that the app takes an advantage in votes, but it’s also true that this benefits the user as well, because they receive more b3tr rewards coming from governance participation.
The important is that the user must be able to opt-out or change governance decisions or add other apps to vote for. If the user is not informed in any way of all of this then I agree with you it’s not great.

What I mean is that the base logic of “In order to compete with other apps in the allocations I want that the users that use my app vote for me, in particular the web2 users that come from social login and know nothing about vechain or vebetterdao” is not wrong. The wrong part is completly hiding this from the user and not allowing a practical way to change this.

1 Like
7

To me the whole point of voting is voting for apps you like…
If the users entry point app into VBD is app X, then this app automatically sets them up to vote on that app - what if they actually after some exploration prefer app Y
Where do they see that app X is what they are actually voting for?! How can they easily switch to app Y
To me this all needs standardising… with common UI components in each app and same standards applied in each app via common components
So that in app Y they can adjust in-app their preference
New users are not going to go to VeDelegate

2 Likes
8

It looks like in overall we think alike, with some nuances.

My goal is not to push any certain in-app voting service (third party or native VBD). But having a VBD auto-voter has it’s perks - it is already a subject to logic governed by proposals/contributions by the community.
Few things it’s lacking -

  1. integrated compounding you mentioned. While the function ConvertToVOT3 can be called during the enabling, user still has to perform manual conversions to increase his vot3 power. If the user is not aware of such logic/doesn’t care, well, that is his choice;
  2. No flexibility with vote weights - votes are distributed equally to all selected apps (learned this only yesterday, thanks @reheat )

Yes, I totally agree. And it’s not something hypothetical, this is a tactic used by at least 1 app.

Yes, a balance between user autonomy and allowing apps to benefit from users landing on their app is needed. I struggle with this rule as I’m not sure how to incorporate it in a way it does not leave room for dirty tactics, for example, user with VD account votes for 10 apps, he lands on 11th app and initiates the in-app voting, the host app adds themselves in the vote preferences with 90% weight, leaving 10% to the original 10. Yes, user is provided with the UI, confirms the transaction, nothing hidden, but where do we draw the line, what is an acceptable way how apps can add them to existing vote preferences? I added this nuance in my more detailed rules (posting shortly), not perfect, but as a starting point for more detailed discussion.

9

Similar questions prompted me to start working on this proposal. After listening to a lot of feedback and digging deeper, I’ve assembled the initial list of more detailed rules. Posting shortly.

10

Rule 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: Apps must provide a visible UI component to opt out of the governance service at any time.

Conversion Allowance: Apps may include a function to convert B3TR to VOT3 when a user initiates in-app voting.

Rule 2: Self-Promotion

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

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

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

Rule 3: Default Configurations

If an app provides governance services and the user opts in without specifying preferences, or preferences become ineligible, the following defaults apply if the services require a governance action:

App Allocation: Vote weight must be set to equal distribution among all endorsed dApps.

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

Rule 4: Dynamic Eligibility & 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, if the user has subscribed to a service requiring a governance action.

Redirection Prohibition: Apps cannot redirect weight from ineligible projects to the host app 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 3 applies.

Rule 5: Anti-Bribery Measures

Apps 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 app.

Universal Exclusion

These rules 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.

1 Like
11

Rule 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.

Rule 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 3: Default Configurations

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

App Allocation: Vote weight must be set to equal distribution among all endorsed dApps.

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

Rule 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 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 3 and Rule 4 (Weight Redistribution and Redirection Prohibition), and according to self-promotion described in Rule 2.

Rule 5: 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.

Rule 6: Treasury Fund Neutrality

dApps are prohibited from using allocation or grant funding received from the VeBetter DAO Treasury to vote in governance cycles. These funds must remain neutral and cannot be used to influence funding outcomes or governance decisions.
dApps found in violation of this rule must provide full restitution by returning all accrued voter rewards to the VeBetter DAO Treasury. Continued non-compliance or bad-faith use of Treasury funds will result in a governance proposal to blacklist the dApp from the ecosystem.

Exemption: dApps maintain the right to use Treasury-sourced funds to support proposals in support phase.

Universal Exclusion

These rules 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.

12

Improved rules based on feedback.

Changes:

Added “as long as such transaction is disclosed and confirmed by the user.”

Added new section under Rule 4
Essentially this removes automation loopholes bypassing freshness multiplier.

New rule based on feedback regarding recent discovery of one of the app self-voting with allocation.
This is first iteration of the rule, so I expect it to be improved (shorter) in the next version.

13

veDelegate has social login now: https://x.com/veDelegate/status/2054578147601858936

1 Like
14

I strongly disagree with this viewpoint, i am not going to have my users vote by default for all applications. Especially since in my opinion some apps don’t deserve votes due to lack of potential, updates, or behavior i can’t stand behind. They make the ecosystem, and thus my own application weaker.

Personally I am ok with the default state is that votes go to the app the users are using, **as long as the user has the option to (1) opt out, or (2) change their preference.
**
This still incentives apps to grow and onboard users and get rewarded for it, an application with a massive userbase (think mugshot), should be able to receive significant support from their own userbase, this support should not go towards applications just because they also happen to be part of the ecosystem.

Without this change, this proposal is not something I can stand behind, it will negatively impact our bigger applications who have the most potential for mass adoption, while rewarding the smaller applications that don’t.

15

Thanks for bringing this to light!

Votes spread equally among all apps would indeed not be neutral as I believed. It would favor smaller projects. While that in itself is not bad, I did not intend to introduce favoritism.

I will rework the rule 3.

16

Rule 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.

Rule 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 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 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 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 4 (Weight Redistribution and Redirection Prohibition), and according to self-promotion described in Rule 2.

Rule 5: 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.

Rule 6: Fund Neutrality

dApps are prohibited from using allocation or grant funding received from the VeBetter DAO Treasury to vote in governance cycles. These funds must remain neutral and cannot be used to influence funding outcomes or governance decisions.
dApps found in violation of this rule must provide full restitution by returning all accrued voter rewards to the VeBetter DAO Treasury.

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

Universal Exclusion

These rules 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.

17

Changes made:

Rule 3

Replaced “Vote weight must be set to equal distribution among all endorsed dApps.” with current selection.

@GreenAmbassador shared some valuable feedback about the negative effects of setting vote equally to all endorsed apps. Such “neutral vote” is not neutral at all considering the formula how Quadratic Funding is calculated.
Dividing vote to all endorsed apps has the potential to significantly impact the allocation, benefiting apps that are not getting the support from voters.
The goal of this proposal is not to pick winners and reallocate funds, but rather to create a level playing field for apps and enhance voter autonomy, thereby strengthening conscious governance decisions.

Why “no vote shall be cast?”

After receiving feedback, looking through different options offered by Claude (with VBD documentation installed), the new proposed selection was the most neutral with the least potential negative effects.

  1. Fits well with Rule 1 (all changes must be user confirmed);
  2. True neutrality - no beneficiaries if a voters preferences become ineligible;
  3. Reduced risk of inactive users affecting the allocation.

Rule 6

Improved wording to avoid interpretations.
Removed “Continued non-compliance or bad-faith use of Treasury funds will result in a governance proposal to blacklist the dApp from the ecosystem.”

Because all of these rules (and those already in the rulebook) are off-chain, there is no automatic on-chain enforcement. Instead, monitoring is maintained by the community and fellow apps, and anyone can submit a proposal in case of a rule violation.

18

Looking great Morb, thanks for listening to the community and making the adjustments!

imo dApps should be able to use their treasury for governance decisions, because they are very important stakeholders in the ecosystem that should have a voice in the direction the DAO is heading. It makes no sense that my dApp would have no say in decisions that might impact my application.

Fully aligned that dApps should not be able to vote on the weekly allocation rounds.

2 Likes
19

Rule 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.

Rule 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 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 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 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 4 (Weight Redistribution and Redirection Prohibition), and according to self-promotion described in Rule 2.

Rule 5: 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.

Rule 6: Fund Neutrality

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.

Universal Exclusion

These rules 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.

20

Improved rule 6 based on feedback.

Apps are allowed to vote on proposals with allocation and grant funding.

1 Like