[VeBetterDAO Proposal] Auto-Voting for X Allocation with Gasless Voting and Relayer Rewards

[Dara]

Hey there,

We would like to propose an auto-voting system for X Allocation Voting that simplifies voting for users while creating new earning opportunities for community members who act as relayers.

Users who opt in to auto-voting have votes cast and rewards claimed each round automatically with no gas fees or manual steps. Relayers take care of all the work for you and take a small fee of the rewards for their service.

Current System Challenges

The current voting allocation system requires users to:

• Vote Manually each round to earn rewards

• Cover Gas Fees for both voting and claiming

• Stay Constantly Engaged or risk missing a round

• Lock Tokens with third-party services that offer a similar capability, fuelling centralisation and adding counterparty risks

---

Auto‑Voting Workflow

For Users

• Opt In & Choose

  • Toggle to enable auto-voting
  • Select up to 10 projects you care about
  • Votes will be distributed equally

• Snapshot
  When enabled, your auto-voting status is locked in at round start. No mid-cycle tweaks.

• Manual Rewards Conversion
  We never touch your funds: after rewards arrive, you convert B3TR → VOT3 yourself for the next round.

For Relayers

• When the round starts, relayers can:

  • Participate to submit your votes and claim rewards for you.

• When the round is finished, relayers:

  • Claim rewards when all required actions fulfilled.
  • Take a small percentage of those rewards as their service fee (capped at a set limit)

---

Gas & Relayer Fee Payout

Each relayer must perform two on-chain actions per user per round: vote submission and reward claim.

Gas Estimation (Simulated via Thor Solo)

Action	Avg. Gas Used	VTHO Cost
Vote submission	245,322	2.4532 VTHO
Reward claim	60,869	0.6087 VTHO
Total	—	3.0619 VTHO

Conversion Rate

• 1,000 gas = 0.01 VTHO

• 100,000 gas = 1 VTHO

• 1 VTHO ≈ 0.017 B3TR (Date: 5 Aug 2025 from BetterSwap)

So, each relayer pays approximately 3.0619 VTHO ≈ 0.051 B3TR per user per round.

Fee Structure

To make relayer participation sustainable, a default fee and a maximum cap are applied to user reward transactions.

Parameter	Value (TBD)	Description	Governance Configurable
Default Fee	[TBD] %	A proportional fee from the user’s reward to compensate the relayer.	YES
Fee Cap	[TBD] B3TR	Ensures relayers don’t overcharge on large payouts.	YES

These parameters are currently left as TBD and are open to community feedback.

Relayer Fee Calculation

Each round, relayers share a common Rewards Pool which is funded by taking a fixed percentage from every user’s reward claim. From that pool, each relayer payout is determined by their share of the total work performed:

• Reward Pool Funding: A set percentage of each user’s claimed rewards is collected into the relayer Rewards Pool.

• Relayer Actions: Each relayer action is weighted to reflect cost differences.

• Action Weights:

  • Vote = 3 points (Governance Configurable)

  • Claim = 1 point (Governance Configurable)

• Total Weight: Sum of all relayers weighted actions in that round.

• Relayer Payout: (Relayer Weight / Total Weight) × Rewards Pool

Example

Let’s set the relayer fee at 10% for demonstration purposes.

Imagine two users, each earning 20 B3TR this week:

1. Relayer claims 20 B3TR for User A → 2 B3TR (10%) goes to the pool, 18 B3TR to User A.

2. Relayer claims 20 B3TR for User B → 2 B3TR (10%) goes to the pool, 18 B3TR to User B.

Resulting Rewards Pool = 2 + 2 = 4 B3TR

Two relayers process all 4 required actions this round:

• Alice: 2 votes + 1 claim
  → (2 × 3) + (1 × 1) = 7 weight points

• Bob: 0 votes + 1 claim
  → (0 × 3) + (1 × 1) = 1 weight point

Relayer	Vote	Claim	Weighted Points	Share Of Total	Payout
Alice	2	1	7	7/8 = 87.5%	0.875 × 4 = 3.5 B3TR
Bob	0	1	1	1/8 = 12.5%	0.125 × 4 = 0.5 B3TR

In this scenario, relayers divide the 4 B3TR pool based on the weighted effort of their work. Alice earns 3.5 B3TR while Bob earns 0.5 B3TR which creates a fairer distribution aligned with actual gas costs.

---

Benefits

For Users

• Your VOT3 never leaves your wallet

• App preferences can be updated at anytime to reflect your interests

• Automatic vote casting and reward claiming without gas costs

• Higher participation rates in governance

For Relayers

• Sustainable business model with predictable fees

• Fair reward distribution based on work performed

• Protected income through pooled rewards

• Scalable service opportunity

For the Ecosystem

• Break up centralisation on existing third-party services that offer similar abilities to users in exchange for their tokens lock-up

• Increased governance participation

• Stronger network effects

• Lowers technical and engagement barriers

---

Technical Specifications

Key Functions

// User Functions
function toggleAutoVoting() external
function setUserVotingPreferences(bytes32[] memory apps) external

// Relayer Functions  
function castVoteOnBehalfOf(address voter, uint256 roundId) external
function claimRewards(uint256 roundId, address voter) external

// Relayer Rewards Pool Management
function claimRewards(uint256 roundId, address relayer) external
function deposit(uint256 amount, uint256 roundId) external

// For Dapp Developers
function isUserAutoVotingEnabled(address account)
function isUserAutoVotingEnabledAtTimepoint(address account, uint48 timepoint) 
function getUserVotingPreferences(address account)

---

Additional Considerations

• Voting Scope
  Auto-voting applies only to X Allocation voting. Governance Proposals must still be voted on manually to ensure thoughtful participation.

• Equal Allocation Voting Power
  Auto-voting splits your voting power equally across all selected applications.

• Manual Voting Disabled
  While auto-voting is active, you can’t cast manual allocation-round votes to prevent conflicts.

• Opt-Out Anytime
  Disable auto-voting at any time and your preferences will clear and take effect in the next round.

• Fee Claim Condition
  Relayers can only withdraw their fee once all expected vote and reward-claim actions for that round have successfully completed.

• Standard Governance Checks
  You must hold ≥1 VOT3 and satisfy all normal voting prerequisites (e.g., VeBetterPassport eligibility).

---

Architecture Diagram

• User: the on-chain account opting in and setting their app preferences.

• Relayer: Executes votes and reward claims on users’ behalf.

• XAllocationVoting: the core contract that tracks auto-voting settings, aggregates rounds, and registers relayer actions.

• VoterRewards: handles the split and distribution of rewards (fee vs. payout).

• RewardRelayersPool: accumulates the fees and handle the distribution to the relayers.

Note: The 10% fee percentage in the diagram is for demonstration purposes only and do not reflect actual data or final parameter values.

---

Q&A

1. Do we still check for 3 sustainable actions?

We still do.

2. Manual rewards conversion: Reasoning behind this decision and not an opt-in too? Many users appreciate the VeDelegate experience due to auto conversion too.

• User Control and Security
  To automatically convert rewards like VeDelegate does, we’d need access to user wallets. That adds complexity and potential security risks. By keeping it manual, users stay fully in control of their funds at all times.

• Avoiding Centralisation Risks
  Platforms like VeDelegate swap your tokens and give you their own. This lets them stake on your behalf and earn higher rewards but it also means they gain more control over staking power. That kind of setup can slowly shift power into fewer hands and lead to more centralisation, which we want to avoid.

• Simplicity First
  Since this feature is still new, we’re keeping things simple to avoid unnecessary risks. As we see how users interact with the system, we can explore smarter solutions in the future — but only if they don’t compromise trust or safety.

3. Is the Default Fee (under Fee Structure) also configurable by the user? If the user wants to give a greater percentage than the base, can he be able to do that? This would incentivise relayers to target priority users first.

No, users can’t change or raise the default fee. There’s no real reason to do that, because relayers have to process everyone’s votes and reward claims. If they skip even one user, no one gets their reward. So it doesn’t make sense to prioritise one user over another.

Also, it doesn’t matter if someone has just 1 VOT3 or 1 million. All the fees go into one pool and get shared among relayers based on how many actions they completed. You can check the example under the Architecture Diagrams section for more details.

4. Could the shares of a relayer be determined by gas consumed?

That’s another good approach but it adds complexity at this early stage of the feature. We aim for simplicity at this phase so the weighted solution seems sufficient.

5. What happens if multiple relayers vote/claim for one user?

It will fail if the action has already completed. It operates on a first-come, first-served basis.

6. What if the vote/claim actions are not all completed by the relayers (e.g., they ran out of gas, or their system breaks)?

All required actions need to be completed for each round. Or else, none of the relayers can claim the rewards for the round.

Initially, I anticipated that VeChain will be the main relayers. This gives us full control to monitor gas usage and implement retry mechanisms, so we can make sure that every user vote is successfully submitted. Later on, as third-party relayers join in, we’ll still keep our own relayers active as a safety net to ensure all voting actions are properly handled.

7. What factors should be considered when setting the default fee and fee cap for relayers?

• Covering Costs:
  Relayers spend about 3.06 VTHO (≈ 0.051 B3TR) per user each round. To break even with a 10% fee, users need to earn at least 0.51 B3TR weekly or hold about 50 VOT3.

• Fairness for Users:
  A small holder might not earn much, so charging a % of their reward is fairer than a flat fee. A cap is also needed make sure big holders don’t get overcharged.

• Price Changes:
  Since B3TR and VTHO prices can change, fees should be flexible enough to adjust over time.

• Governance Control:
  Both the fee and cap can be updated through governance, so we can tweak things based on real-world data and feedback.

---

We’d Love Your Feedback

1. Does the proposed auto-voting flow feel clear and intuitive?

2. What do you think is a fair fee and cap for relayers?

3. What would you tweak, improve, or add to make this system better?

[DaveL]

Great work by the team!

A tip for any relayer implementor is dynamic gas fee’s, and many votes to cast, you might consider to stagger casting those votes over a few blocks to optimise your gas costs.

[reheat]

Definitely a very interesting solution! Great work on the proposal.

I have some suggestions I’d like to add. Sorry if some of them already exist in the proposal and I missed it.

• Require a minimum of Moon GM NFT to act as relayers. This rewards user investment and act as an additional incentive to upgrade your GM NFT from Earth, further strengthening the VeBetterDAO treasury. Also acts as a barrier to protect against abuse.
• Have a higher auto-vote cap than ≥1 VOT3. veDelegate has a ≥50 VOT3 requirement to user their service (without manual execution).
  • This proved very effectful in removing ‘burner wallets’ from just voting with a very low amount to receive certain rewards:
    • Most recently Mugshot’s leaderboard, earning burner wallets XP with just 1 vot3
    • It also protects against bad actors using hundreds/thousands of wallets to auto-vote on a dApp in order to abuse quadratic funding.
  • The higher the threshold, the harder to abuse at scale.
  • I would set at a ≥10-50 VOT3 requirement. Earning that amount of B3TR is entirely feasible in a couple of days as a new VeBetterDAO user.
• If I didn’t miss it already being proposed, I would also set a cap on the amount of actions a relayer can take. I worry that a user could otherwise build some automation solution to automatically complete every relay action available as soon as one is listed, leaving none for ‘legit’ relayers.
  • The exact cap and implementation I’ll leave up to discussion.
• I would also propose that an ‘auto-vote’ should not last indefinitely.
  • This can lead to dApps that exist now having a huge benefit over dApps that join later as users have ‘set-and-forget’ their votes on the dApps they liked then. A lot can change over time.
  • I suggest a 12-round duration at most. After that, a new auto-vote has to be started by the user.
• I think the fee needs to be at 1-5% to compete with other solutions (that all currently charge 10%)
• Add the new required section “added, modified, removed features” to comply with the governance proposal rules coming soon

Finally, some situations to consider:

• What happens if a dApp that a user has selected to vote for loses endorsements or gets blacklisted/delisted? Do we rebalance the remaining <9 dApps to equal share?
• Do all existing relay actions show up instantly with new round start? This would create a disadvantage for regions where rounds start in the middle of the night.
• GM NFT Rewards (of moon+) are distributed as normal with the users’ voting rewards? Does it require some technical solution?

I really like the concept. Would love to see something like this iterated on.

[VeHunt]

This will be HUGE updates in coming weeks👀

[Plunk]

This is an interesting topic for sure. A couple notes, if they don’t make things too complicated - I’m keeping in kind that you’ve mentioned wanting to keep this simple.

• I suggest having the ability for the user to delegate to a relayer to have first dibs to carry out the actions. If not completed in a certain timeframe (24 hours for example) then it gets opened up to the floor.

• On the reverse - I suggest a “reservation” system where a relayer can claim a user’s action slot for a given round before executing it (again, reserved for a given time-frame such as 24hrs).

The above two points would prevent wasted gas from several duplicate attempts that come from a first-come fist-serve system.

In the interest of abuse prevention, these above suggestions would only make sense if there was an action cap and GM Moon NFT or higher was necessary to be a relayer.

• Is there a reason, other than simplicity, as to why the vote weight needs to be split evenly amongst the dApps? I would still love to see people select their voting percentages.
• I would propose that there be a dashboard to publicly display total votes processed, relayers involved, pool distribution, and participation rates of the relayers. This would provide important information to both users and relayers, whilst also driving competition and promoting participation.
• Going off of @reheat’s action cap suggestion. I would suggest that the cap is determined based on the amount of relayers and the amount of users with automated votes, with the cap being raised dynamically as the week progresses if there is low participation from relayers.

Quite frankly, whether I am on-board or not with this system would rely heavily on the anti-abuse mechanisms and safeguards.

I agree with all of @reheat’s points, particularly regarding the minimum VOT3 requirement, GM Moon NFT requirement, and having an action cap for the relayer. We have seen many systems get abused where new wallets can be spun up by users to inflate numbers to reward themselves unfairly, and these measures would act as a very effective barrier to this abuse.

I’ll be following this discussion with interest. Looking forward to seeing further community participation regarding this one.

[Dan]

@reheat

Require a minimum of Moon GM NFT to act as relayers. This rewards user investment and act as an additional incentive to upgrade your GM NFT from Earth, further strengthening the VeBetterDAO treasury. Also acts as a barrier to protect against abuse.

I don’t see how adding this requirement will make anything better for this use case.
There won’t be many relayers, so this won’t bring prices up for GM in any way, and there can be no abuse: if you cast the vote for a user, good for you, someone has to do it. And that’s it, you cannot do actually much.
Also, relayers will use some software running and attaching a GM to a private key just to run a software is not something that really makes sense to me.

@reheat

If I didn’t miss it already being proposed, I would also set a cap on the amount of actions a relayer can take. I worry that a user could otherwise build some automation solution to automatically complete every relay action available as soon as one is listed, leaving none for ‘legit’ relayers.

But that’s the thing: there is no such thing as good relayer or bad relayer. The goal here is to have a way to cast votes and claim rewards for the users without a single entity that has any sort of power and in a way that this can survive even without VeChain. So if someone builds an automation tool to cast votes before anyone else I consider that a success! It means that all votes are cast, rewards are claimed and all is good. The point here imho is not to find a way for someone to make money, but to find a way to be 100% sure that those votes will be cast.
Adding a cap will only introduce issues imho, eg: relayers cannot claim their rewards if even 1 single user is still missing from having his rewards claimed or vote cast; in this scenario all relayers are incentivized to actually be sure to claim/vote for ALL. If you now introduce a cap it means that this could be at risk or that someone just switch wallet and get around the cap.

@reheat

I would also propose that an ‘auto-vote’ should not last indefinitely.

Could be an issue from an ux point of view and a big disadvantege of the dao since veDelegate can do whatever.

@reheat

I think the fee needs to be at 1-5% to compete with other solutions (that all currently charge 10%)

But other solutions (veDelegate) don’t cap, we instead have a cap. Eg: we could decide that max fee is 100 B3TR, so even if you have 1 Milion B3TR the fee will still be 10’0, while on veDelegate that 10% will be 10000 B3TR.

@reheat

What happens if a dApp that a user has selected to vote for loses endorsements or gets blacklisted/delisted? Do we rebalance the remaining <9 dApps to equal share?

We rebalance. Not sure what will happen if the only app selected is delisted though, we should for sure double check this scenario.

@reheat

Do all existing relay actions show up instantly with new round start?

Not sure what you mean. Once the round start relayers can start casting the vote and claim the rewards (aka do their actions).

@reheat

GM NFT Rewards (of moon+) are distributed as normal with the users’ voting rewards?

Yes.

[Dan]

@Plunk

I suggest having the ability for the user to delegate to a relayer to have first dibs to carry out the actions. If not completed in a certain timeframe (24 hours for example) then it gets opened up to the floor.

That’s a nice idea, what is the vision here though? Have apps like Cleanify, Mugshot, etc as relayers for their users? Would those apps like this tho? Maybe they don’t really care and just want to allow their users to vote for them in their app (as Mugshot and Cleanify are doing). Still, this could add some pretty complicated logic, so I’m thinking: should we consider this for an MVP? I think we should start with a simple and functioning design first, see how it evolves in the first month or so and then iterate.

@Plunk

The above two points would prevent wasted gas from several duplicate attempts that come from a first-come fist-serve system.

True, but theoretically simulating the transaction could prevent this, even if I agree, it will still be possible that 2 relayers cast/claim for the same user in same block.

@Plunk

Is there a reason, other than simplicity, as to why the vote weight needs to be split evenly amongst the dApps? I would still love to see people select their voting percentages.

The issue is with validating that the relayer is not changing the votes of the user. In the first iterations we did it was very gas consuming and required quite a few of loopings to validate that, but we could try to give it another shot and maybe we find a better solution.

[reheat]

Hey! Thanks for responding. Sorry in advance for the long post in advance haha.

I think I’m a bit confused with the intent of the system then, my apologies. I read it as an open system that anyone could opt into, basically some kind of “bounty board” of votes, where anyone can just go in and click "vote” on ‘available votes’, if that makes sense.

In my head, I was envisioning it having the same issues that Nubila’s “validator/auto-validator” system has. In there, validators can ‘validate’ the weather report from user’s Nubila weather tation. Doing so, validators earn rewards. Exactly how relayers (validators) would vote on users (the nubila devices) and earn rewards.

Their issue is that these validations go up each day, and every validation is instantly completed by bots for the rewards, leaving actual users unable to claim any rewards for themselves. With time, nobody bothers doing it manually as its pointless. All rewards are instantly taken by bots.

That’s what I envisioned this auto-voter system would face too. I (as someone who would definitely act as a relayer if possible) would go in and instantly see every vote already handled by bots. And therefore, my suggestions of anti-abuse mechanics.

@Dan

I don’t see how adding this requirement will make anything better for this use case.
There won’t be many relayers, so this won’t bring prices up for GM in any way, and there can be no abuse: if you cast the vote for a user, good for you, someone has to do it. And that’s it, you cannot do actually much.
Also, relayers will use some software running and attaching a GM to a private key just to run a software is not something that really makes sense to me.

The GM NFT of moon+ would act as the anti-bot mechanic in this case. The abuse I was envisioning was the scenario of there being no votes to cast as all votes have already been claimed by bots.

When you said ‘there won’t be many relayers’, I’m curious. It’s a missing piece of the puzzle for me. If it’s not open to anyone, how will the relayers be selected? If it’s open, I do think there will be many relayers (if the rewards are worth it of course).

@Dan

But that’s the thing: there is no such thing as good relayer or bad relayer. The goal here is to have a way to cast votes and claim rewards for the users without a single entity that has any sort of power and in a way that this can survive even without VeChain. So if someone builds an automation tool to cast votes before anyone else I consider that a success! It means that all votes are cast, rewards are claimed and all is good. The point here imho is not to find a way for someone to make money, but to find a way to be 100% sure that those votes will be cast.
Adding a cap will only introduce issues imho, eg: relayers cannot claim their rewards if even 1 single user is still missing from having his rewards claimed or vote cast; in this scenario all relayers are incentivized to actually be sure to claim/vote for ALL. If you now introduce a cap it means that this could be at risk or that someone just switch wallet and get around the cap.

This definitely highlights an interesting conversation. I agree that limiting the amounts of relay actions per wallet isn’t right, I forgot about the ‘rewards cap’ in the original proposal when I wrote that. It serves the same purpose without risking having votes unhandled.

The system is designed to compensate the relayer, with a set fee cap per wallet, and if there is no gating (moon nfts or otherwise), my worry is that someone will find a way to claim 99% of the relay rewards for themselves over multiple wallets (going around the rewards cap).

Every vote would be handled yes, but it would mean that they’re only handled by software from a few individuals and not spread out over multiple different relayers. And the rewards would be with the same few.

• The ‘good relayer’ in my example would be the people going into VBD on their own, completing votes as they’re available, and earning a fair reward for their time.
• The ‘bad relayer’ would be the person automating every vote and draining the rewards pool for themselves. Exactly what’s happened with the Nubila validation example above.

Both complete the vote for the users, yes, but the rewards end up in the hands of a few, leaving us with a centralized system in a sense.

But yes, if the goal of this is just to handle votes and to simply cover gas fees for the relayer, then sure, it doesn’t matter who does it.

@Dan

Could be an issue from an ux point of view and a big disadvantege of the dao since veDelegate can do whatever.

Sure. It’s an UX issue, I can understand that. But when the user opts into auto-voting, a timestamp for when it expires could be added. And an in-app notification sent through VeWorld as it’s getting close to expiring/has expired. I think it’s a reasonable compromise personally.

This proposal specifically says that voting on proposals would be handled outside the voter/relayer system as those require thoughtful input, but in my opinion what dApps users vote for is of even higher importance than for/against/abstain on a proposal. So asking users to resubmit every three months (and requiring a new dapp selection in the process) makes sense.

A dApp currently lives and dies on getting votes (as there is no base allocation), and voter count matters monumentally. Proposals don’t care about the individual voters in the same way, they care about the %s of agreement. Therefore, it doesn’t make sense for me to design a system where a user could lock votes on 10 apps indefinitely.

veDelegate (and other solutions) can always do whatever, that’s true, but I think an official solution should aim to be better than its competitors and learn from mistakes already made (much harder to add time-restricted auto-voting after the fact).

@Dan

But other solutions (veDelegate) don’t cap, we instead have a cap. Eg: we could decide that max fee is 100 B3TR, so even if you have 1 Milion B3TR the fee will still be 10’0, while on veDelegate that 10% will be 10000 B3TR.

I was going off the 10% relayer fee in the example scenario in the proposal (the b3tr going to the pool). That’s what the user will lose on using the auto-voting service, and that’s why I think it needs to be 1-5%, otherwise everyone would just keep using 3rd party services. Not the fee cap of raw B3TR that the relayer can claim.

@Dan

Not sure what you mean. Once the round start relayers can start casting the vote and claim the rewards (aka do their actions).

That’s what I meant, sorry for the confusing wording. At minute one of the round, all relayers can then cast the votes then.

Disregarding any bots, if all current votes to handle show up at the first minute of the round, that would mean at 3AM my time (CEST), typically.

Unless there are votes to handle for multiple hours each round, that would mean it’s a useless system for me (and most of Europe) to partake in as all possible rewards for the round would be claimed by the time I wake up.

Obviously that’s a hard scenario to design around, and if there are always votes to handle, it wouldn’t matter. I just figured it’d be worth bringing up

---

Again, I think the proposed system has a lot of potential. I was mostly focused on the relayer side of things as I agree, all votes just needs to be handled. I just don’t want to see a world where all votes are handled within 1 minute each round by one individual with a bot, claiming all the relayer rewards over multiple wallets.

[LudoDidymus]

Cheers Dara on face value and without being a technical guru who can envisage potential issues this looks like a great improvement. ReHeat and Plunk do a great job raising potential issues and Dan has obviously put a lot of thought into this as well.

From my perspective cheers everyone for the proposal and considerations to potential issues that arise. I’d be happy to support it, implement it, analyse how it goes and make future adjustments as required to fix issues from excessive relayer farming, monopolies of relayer or anything else if it arises.

As a simple user of VeBetterDao I find myself pretty focused on just using dapps. So I greatly appreciate the time, thought and effort by VeChain and VeFam to dig deep into the nuanced issues surrounding VeBetter and to come up with solutions. Legends

[Dan]

Let me try to put this technical implementation proposal into easier words: we want to allow auto voting, but we do not want to control the user’s funds (as veDelegate does) because it could be a security issue, so we will update the smart contracts to allow the user to toggle an option where they can turn on autovoting and define a list of apps; Now we need a system in place that can guarantee that the votes of the user will be cast each round. To do that the foundation will create a server that will index and cast votes / claim rewards for users that opted in. But we do not want to be a central point of failure or need to be always there in order to make this function to work, this is why anyone can do those transactions. But performing those transactions costs VTHO and to incentivize services to cast the votes those fees needs to be covered (this is why the fee). To makes things fair all the fees goes to a pool and everyone will claim the rewards based on their activity. To be sure that some users are left out the limitation was added that all votes must be cast otherwise no one gets any reward.

From our point of view our goal is only to guarantee that the votes are cast and rewards are claimed. This autovoting functionality must work 100% of the times. So for me personally if there is a single guy casting all the votes on monday after the round starts would be a win situation: vote is cast, users claimed rewards, all very efficiently.

[daithihearn]

We could allow people to register as a relayer. Then for the first N blocks of a round they will have exclusive rights to do actions for a fair portion of the accounts that have enabled autovoting. After N blocks the restrictions are removed. Dead relayers get ejected from the system.

This would allow more relayers to participate and will help to avoid collisions. However it will add more complexity. We generally take the approach of start simple and iterate. But maybe this is an important enough feature to implement in the MVP.

[Dara]

Thanks everyone for joining the discussion,

I would also propose that an ‘auto-vote’ should not last indefinitely.

It won’t be indefinitely.

In the current DAO system, the user is required to perform 3 sustainable actions within each 12-round window to stay eligible. This proposal already takes this consideration. For example, if the user enables auto-voting and doesn’t do anything, their auto-voting will be disabled once the decay period is reached. This essentially acts as a built-in restriction. By adding an extra rule on top for auto-voting might cause friction.

That being said, we can improve the UI to make it clearer for the users and add further changes in the next iteration if needed.

Ref: Proof of Participation | VeBetterDAO Docs

If I didn’t miss it already being proposed, I would also set a cap on the amount of actions a relayer can take.

Placing a limit on relayer actions makes sense to some extent. While it may seem fair, it could also cause problems if we depend on a fixed number of relayers to finish their tasks so that others can get rewards. For example, if one relayer wallet is compromised and they cannot complete their actions, it could prevent others from receiving their share of the fees and could also risk missing votes for users in that round.

What Daithi proposed might help with this. “We could allow people to register as a relayer. Then for the first N blocks of a round they will have exclusive rights to do actions …”.

I would also add that any action-limit or time-frame should apply only to voting, not to claiming rewards. Claims should be done quickly so that users get their rewards and relayers are paid. Having back-to-back restrictions would slow everything down.

Basically, relayers can register and voting actions are divided among them. These actions must be completed within a set time frame. Once the time limit is reached, they are released for other relayers to participate.

This autovoting functionality must work 100% of the times.

I agree that the relayer system should aim for a degree of fairness but not at the cost of reliability. Just wanting to echo this comment from Dan that reliability for users should remain the top priority.

[reheat]

Thanks @Dan for the explanation. Makes sense from that point of view!

What you’re saying @daithihearn would suffice as a good first step in my opinion. It would solve the issue of one person claiming all rewards and it would solve my Europe-example of rounds starting in the middle of the night.

If its not too complex I think that would be a good compromise

@Dara yes, I know about the proof of participation requirement. I also know that a lot of users do not update their voting preferences nearly as often as they complete better actions.

Would it be a fair compromise to leave the technical implementation as is, but add an item to the “governance carousel”:

(where you claim weekly voting rewards, click to go vote for apps, see new apps that have been added etc)

It would simply prompt the user to “revisit” their selected dapps every N weeks? Just to make sure their vote preferences are still valid.

This would not require a redesign of any other UX component of this proposal imo.

---

These two changes would be great to see and I’d consider that a very good start for the MVP and can be analyzed for any future changes once implemented.