Velodrome voting lets veVELO holders direct emissions and earn pool rewards
Last updated ·
Velodrome voting lets veVELO holders allocate emissions across eligible pools and earn pool voting rewards. In the V2 system, a VELO lock supplies voting power through an NFT, or non-fungible token. Pool votes direct the following epoch’s liquidity rewards, while voters share trading fees and deposited incentives. Staked liquidity receives emissions through a separate reward contract called a gauge. The lock’s voting weight, the pool’s total votes and its reward funding determine each voter’s entitlement.
Additional votes can reduce a lock’s share of a pool’s voting rewards even when the pool’s total funding stays unchanged.
Voting locks and liquidity deposits earn different rewards
An eligible veVELO lock can earn voting rewards; an eligible staked liquidity position can earn emissions. Either position can exist without the other. Voting for a pool does not require depositing its trading assets, and depositing liquidity does not create veVELO voting power.
On OP Mainnet, staked liquidity earns VELO. Supported remote Superchain gauges distribute XVELO, the cross-chain representation of VELO. Velodrome recovery guidance directs holders on Celo, Fraxtal, Soneium, Unichain, Superseed, Metal, Mode and Lisk to return XVELO to OP Mainnet by October 15, 2026. It warns that these bridges will be deprecated and recovery after the deadline is not guaranteed. In basic V2 pools, staking LP tokens exchanges the corresponding liquidity fees for emissions. Unstaked liquidity can retain trading fees under its pool rules. In emissions-eligible Slipstream concentrated-liquidity pools, a configurable share of unstaked liquidity’s trading fees can also go to voters. The gauge rewards staked liquidity, while the pool’s voting-reward contracts reward allocated voting power. A voting lock contains VELO; an LP position retains exposure to its deposited pool assets.
How does a veVELO lock determine voting power?
A timed V2 lock derives voting power from its VELO balance and remaining duration, with a maximum duration of four years.
Timed locks lose weight as expiry approaches
Voting power is approximately the locked amount multiplied by remaining duration divided by the maximum duration. Contract arithmetic and weekly rounding of the unlock date affect the recorded balance. As expiry approaches, the remaining duration falls and voting power declines. Adding VELO increases the underlying lock balance; extending an eligible timed lock increases its remaining duration. Neither operation creates a liquidity deposit. The principal remains escrowed until the timed lock reaches its recorded expiry and meets the withdrawal conditions.
Permanent locks keep their maximum-duration weight
Permanent V2 locks retain voting power without time-based decay. Turning off permanent mode starts a maximum-duration timed lock, rounded to the protocol’s weekly boundary. It does not release the underlying VELO immediately. An active voting state can prevent that conversion until the lock’s votes can be reset. Permanent locking also leaves pool selection to the voting mechanism.
The weekly voting window and allocation limits
V2 epochs last seven days and turn over each Thursday at 00:00 UTC. The first hour reserves a distribution window. Ordinary pool voting closes before the final hour, while specifically allowlisted veNFTs have a late-voting exception. These restrictions apply to the weekly V2 system.
| Parameter | V2 rule or value | Effect on voting or exit |
|---|---|---|
| Timed lock ceiling | Four years | Unlock dates round down to a weekly boundary. |
| Epoch length | Seven days | Pool allocation follows weekly accounting. |
| Epoch boundary | Thursday, 00:00 UTC | A new voting epoch begins. |
| Opening restriction | First hour of the epoch | Voting, resetting and managed entry or exit are blocked. |
| Regular voting cutoff | Start of the final hour | Late voting requires an allowlisted veNFT. |
| Fresh direct allocation | Once per normal veNFT per epoch | A vote or managed deposit uses that epoch’s allowance. |
| Pools per allocation | Governor-configured maximum |
The Voter’s maxVotingNum supplies the applicable limit.
|
| Rule scope | Weekly V2 pool voting | Lock state and gauge eligibility also constrain the action. |
Recorded pool allocations persist until changed or reset. Recasting recalculates weight from the lock’s voting power; a poke refreshes existing allocations without choosing a different pool mix.
Pool fees, incentives and rebases follow different paths
Voting fees and external incentives belong to pool reward contracts, while VELO rebases use a separate distributor.
Trading fees follow the pool’s fee accounting
The weekly model rewards voters using fees from a preceding trading epoch. The relevant fee contract accounts for the amounts routed to that pool’s voters. Trading activity creates the fee pot, and recorded voting weight determines its division. Direct V2 fee claims pay the NFT owner, even when an authorized operator initiates the claim.
Deposited incentives attract pool votes
External participants can deposit eligible reward tokens into a pool’s incentive contract. Those deposits reward voters allocating weight to that pool. Incentives can supplement a pool’s trading fees without demonstrating stronger trading demand. Their amount and token composition can change between epochs as participants change their deposits.
Rebases add VELO through separate accounting
Rebases distribute additional VELO to voting locks using their share of escrowed voting power. A rebase claim adds VELO to a normal lock that remains unexpired or permanent. For an expired, non-permanent lock, the distributor pays the owner liquid VELO instead. A larger locked balance therefore differs from spendable fee income. Pool voting rewards become claimable through completed reward epochs; an estimate of pending rewards does not establish a received payment.
Why can a pool’s voting return change before the epoch closes?
A pool’s indicated voting return changes when its reward pot, total allocated voting weight or reward-token valuation changes before settlement.
A lock’s pool reward share uses its recorded allocated weight relative to the pool’s total recorded weight at the reward epoch’s end. Additional votes can dilute that share without reducing the pool’s total reward funding.
A large incentive pot can attract enough voting power to reduce rewards per unit of weight. Fees reflect an earlier trading period, while incentives reflect deposited funding. Their combined value describes voting revenue, which differs from the emissions a gauge streams to staked liquidity. An annualized figure expresses a reward snapshot over a year, without fixing later fees or incentive deposits.
The Voter rejects allocations to nonexistent or inactive gauges. Killed gauges receive no new emissions. Remote Superchain gauges also have configurable emission caps, so extra votes cannot force their emissions above the applicable limit.
Direct voting, managed locks and the Aero transition
Direct allocations retain control over the pool mix
A normal veNFT lets its owner choose eligible pools and relative weights. Resetting clears the recorded pool votes. It requires a later epoch than the last vote and a completed opening distribution window. Superchain voting keeps the root Voter on OP Mainnet and forwards weights to eligible remote reward contracts. Remote voting rewards accrue on the corresponding pool’s chain, so the reward location can differ from the lock’s location.
Managed deposits hand allocation to a shared lock
Managed NFTs aggregate deposited voting power, and their manager determines the shared pool allocation. Rewards can be distributed to depositors or compounded through the manager’s implementation, with its applicable fees. Direct voting and managed entry are mutually exclusive within an epoch. Withdrawal from a managed NFT cannot occur in the deposit epoch. It restores a normal lock with a maximum-duration timed expiry, including the depositor’s accrued locked rewards. Leaving managed voting therefore does not make the underlying VELO immediately liquid.
Aero plans a different allocation model
The announced Aero launch is scheduled for October 21, 2026, combining Velodrome and Aerodrome into a new protocol. Its planned Predictive Allocation mechanism uses sAERO positions to direct AERO rewards continuously and earn exchange revenue as it accrues. The planned system removes rebases. Existing locks and liquid tokens require migration. Before migrating veVELO, claim outstanding rewards and withdraw any managed or externally deposited positions. Old gauges and factories are slated for retirement. These weekly veVELO rules describe V2; once a lock migrates, Aero’s allocation and reward rules apply.
Popular questions about Velodrome voting
Can an approved operator vote with my veVELO NFT?
An approved operator can vote with a V2 veVELO NFT under the same epoch and lock-state restrictions as its owner. This uses the NFT’s ownership or approval permission. That approval can also authorize other NFT operations, so it grants broader control than a narrowly scoped voting permission.
Why does a very small pool allocation sometimes revert?
A V2 vote reverts if a selected pool receives zero voting weight after integer division. The contract normalizes each submitted weight against the sum of all submitted weights. A tiny share of a small lock can therefore round down to zero, even when the pool has a live gauge.
Which tokens do V2 fee and incentive claims pay?
Basic V2 fee rewards arrive in the pool’s underlying tokens, while incentive rewards arrive in the eligible tokens deposited into its incentive contract. A combined reward valuation does not change those payout assets. VELO rebases use separate accounting and can increase an unexpired lock’s balance instead of arriving as spendable voting income.
Does a pool vote also change the total VELO emission rate?
Pool votes allocate available VELO emissions among gauges; they do not set the protocol’s total issuance. Velodrome has a separate EpochGovernor process for emission-rate decisions once its tail-emission schedule is active. Pool allocation and emission governance count different decisions, even when both use veVELO voting power.