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:
-
Relayer claims 20 B3TR for User A â 2 B3TR (10%) goes to the pool, 18 B3TR to User A.
-
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
- Do we still check for 3 sustainable actions?
We still do.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
-
Does the proposed auto-voting flow feel clear and intuitive?
-
What do you think is a fair fee and cap for relayers?
-
What would you tweak, improve, or add to make this system better?
