@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.
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:
Dilution: too many endorsed apps, per-app rewards keep shrinking.
B3TR price in structural decline, zero buy-pressure.
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.
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.
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:
dApp decides to include in-app voting;
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.
VD wallets with ineligible vote preferences will no longer be able to vote for all apps equally, thus, less benefiting inactive/stale projects;
dApps will no longer be able to set up voting wallets in behalf of users without their consent;
No more overriding user vote preferences without their consent;
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.
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.