Does Setting a Gauge Vote to Zero Remove Its Voting Cooldown?

A successful zero-weight gauge vote starts another cooldown for that account and gauge. GaugeController records the successful zero-weight vote’s timestamp, so a replacement allocation must still satisfy the 10-day delay. Replacing the existing allocation directly avoids an unnecessary reset, provided the account already meets the timing and voting-budget requirements.

Will Adding CRV to an Existing Lock Refresh My Gauge Votes Automatically?

Increasing a CRV lock does not automatically incorporate its extra voting power into existing gauge votes. Extending the lock also requires a new vote to update those recorded contributions. The controller reads the lock’s slope and expiry when accepting a vote. Re-voting remains subject to the same-gauge cooldown, while personal boost updates follow the gauge’s checkpoint rules.

Can Someone Else Refresh My Recorded CRV Boost?

LiquidityGaugeV6 lets anyone call its kick function when the account satisfies the contract’s eligibility checks. The stored working balance must exceed the unboosted baseline. The account must also have either zero direct veCRV balance or a voting-escrow update later than its gauge checkpoint. A permitted call settles CRV accounting and recalculates the weight; it does not withdraw the account’s LP tokens.

What Happens to External Rewards If a Gauge Is Killed?

LiquidityGaugeV6’s killed status stops its CRV emission accounting while external rewards remain governed by their own funding schedules. Controller registration and positive voting weight cannot override that status. An external reward balance can therefore remain claimable while the CRV stream has stopped. Gauge administrators control this setting; additional veCRV from a depositor does not reverse it.

Whose veCRV Balance Matters When I Stake LP Tokens for Another Address?

LiquidityGaugeV6 calculates the boost using the beneficiary’s adjusted veCRV balance. A deposit transfers LP tokens from the transaction sender but credits the selected beneficiary, which defaults to the sender when no other address is specified. Funding another address’s stake does not attach the sender’s boost to it.

Curve

Curve gauges use vote weights for CRV emissions and veCRV for eligible reward boosts

Curve gauges distribute incentives to accounts staking liquidity provider (LP) tokens or supported lending vault shares. Vote weights determine an approved gauge’s share of CRV emissions, while eligible veCRV balances adjust each account’s share within that gauge. CRV locks create veCRV, or vote-escrowed CRV. These controls operate at different levels: a vote changes the gauge allocation, and a boost changes reward accounting for an individual stake. Externally funded token rewards follow separate rules.

8 October 2026 · last updated

In short: For an unchanged LP stake at its working-balance cap, additional veCRV cannot increase the stake’s calculated CRV reward weight.

Staked Balances and Reward Eligibility

Gauge staking requires the LP or vault token the chosen contract accepts, on the same chain as that gauge. A deposit credits a staked balance to an account, establishing participation; a token allowance only authorizes a transfer. New reward accrual also requires an active stream. For CRV, the Ethereum liquidity gauge or cross-chain root gauge needs controller registration and effective emission weight, and its killed status must permit emissions. Gauge versions determine the applicable boost calculation and claim interface.

The gauge adds reward accounting to the existing pool share while its underlying asset exposure continues. Gauge rewards can change without altering the pool’s asset mix.

Vote Allocations and Weekly Emissions

GaugeController combines gauge weights and gauge type weights to calculate a normalized share of CRV inflation for each eligible gauge. This relative weight determines the gauge’s allocation. A raw weight alone does not describe its share of all emissions.

veCRV holders allocate a percentage of their voting power among gauges. The total cannot exceed 100%. A voter’s chosen percentage refers to their own power, not the gauge’s percentage of the overall CRV stream.

Gauge voting does not require an LP deposit in the target pool, and depositing there does not automatically cast a vote. The controller records voting allocations separately from staking balances. A staker’s personal boost uses voting-escrow balance, without requiring a vote for that particular gauge.

A new vote schedules its contribution for the next weekly epoch, which begins Thursday at 00:00 UTC. Existing voting contributions decay with their underlying locks. Aggregate effective weights determine the allocation, including the contributions of other voters. The account’s lock must extend beyond the next epoch boundary for the controller to accept a vote.

Working Balances and the Boost Ceiling

LiquidityGaugeV6 calculates each staker’s working balance from deposited LP tokens and the adjusted veCRV balance its boost proxy reads, then uses that weight for CRV accounting.

Let l denote the account’s staked LP balance, L the gauge’s total staked LP balance, v the adjusted veCRV balance the boost proxy returns for that account, and V total veCRV supply. When V is positive, the formula is b = min(l, 0.4*l + 0.6*L*v/V). If V is zero, the contract uses the baseline term alone.

LiquidityGaugeV6 gives an unboosted stake a working balance equal to 40% of its deposited LP tokens. The cap at l creates a 2.5x maximum relative to that baseline. Boosting leaves the deposited LP token quantity unchanged.

For positive veCRV supply and a nonempty stake, the formula reaches full boost when v/V meets or exceeds l/L, subject to integer rounding. In other words, the account’s adjusted veCRV share must cover its share of staked LP tokens. A fixed adjusted veCRV balance can fully boost a smaller stake yet provide only partial boost for a larger stake.

The gauge divides its CRV stream across accounts in proportion to their working balances. Raising one account’s weight changes the denominator, so a displayed boost factor does not promise an identical multiplier on received CRV. Extra adjusted veCRV adds no weight once the stake reaches its cap.

A Gauge Vote Retry After the Cooldown

GaugeController requires at least 10 days between an account’s votes for the same gauge. A failed cooldown check reverts the attempted vote.

In a hypothetical retry, the account has an accepted vote at timestamp t, the target gauge has controller registration, the requested allocation fits the voting budget, and the CRV lock extends beyond the next epoch. The account attempts a replacement vote at timestamp u. The requested allocation and lock end remain unchanged; the retry changes the attempted transaction time.

When u is earlier than t plus 10 days, the vote fails the timing check and leaves the previous allocation recorded. Repeating the transaction before eligibility returns cannot change this outcome; waiting addresses this specific failure.

In the later attempt, u reaches t plus 10 days. The account continues only if its lock still extends beyond the next epoch; a shorter lock requires stopping this retry. With the other prerequisites still satisfied, the replacement vote succeeds. The controller records its allocation and a new last-vote timestamp, and its contribution takes effect at the following epoch.

Checkpoint Timing and Recorded CRV

Gauge checkpoints settle accrued CRV before refreshing working balances, so increasing veCRV does not apply a stronger boost retrospectively. LiquidityGaugeV6 refreshes weights during deposits, withdrawals, transfers of its staking receipt tokens, and authorized user checkpoints. The stored weight governs reward accounting between these updates.

Stored balances can differ from a fresh calculation using present inputs. Lock decay and changes in total gauge deposits affect the next calculation. The working_supply value sums recorded account weights. It differs from totalSupply, which measures staked LP tokens. CRV accounting uses the former denominator.

For Ethereum liquidity gauges using Minter, that contract first checkpoints the account and then mints its cumulative CRV entitlement minus amounts previously minted for that account from the same gauge, so the remaining claim can be smaller than the cumulative integrate_fraction value. This gauge record includes earlier claims and covers accrual through the last checkpoint. LiquidityGaugeV6 permits the account itself or Minter to call its ordinary user_checkpoint function.

External Incentives and Separate Claim Paths

External rewards use supplied token budgets and distribution periods instead of the controller’s CRV inflation allocation. Authorized managers register reward tokens and assign distributors; those distributors fund the streams. DAO gauge approval does not supply this budget. A deployed gauge can distribute external incentives without qualifying for native CRV emissions.

veCRV boosts do not apply to externally funded gauge rewards. LiquidityGaugeV6 allocates these rewards using ordinary staked balances. Its claim_rewards function handles externally added reward tokens, while Minter handles native CRV emissions. An interface may combine claim actions without merging their accounting. Each funded stream has its own rate and end time; once its funded distribution ends, further accrual requires additional funding.

Root and Child Gauges Across Chains

Cross-chain emissions link a root gauge on Ethereum with a child gauge on the destination chain, where accounts stake their LP tokens. The root receives controller votes and routes CRV to the child. Bridge delivery separates the root’s allocation from local token availability. The root’s emission status matters even when the child has a recorded staking balance.

View image file

Sidechain boosting also requires a voting-escrow oracle configured for the relevant child-gauge system. An Updater transmits Ethereum veCRV information to that oracle so the child can use those records for boost calculations. An Ethereum lock alone does not establish boost support on every chain. Gauge version, oracle configuration, and recorded account data determine the applicable mechanism.

Gauge Yield and Underlying Exposure

A pool’s yield estimate can combine trading income, CRV emissions, and external rewards, each with different accounting. The 2.5x working-balance cap concerns CRV weighting alone. A higher vote weight does not change the assets the LP position holds, and unstaking returns pool shares for a separate pool withdrawal. Before considering a larger CRV lock, the stake’s remaining distance to its working-balance cap determines whether additional veCRV can raise its calculated reward weight.

Curve gauges: reader questions

Does Setting a Gauge Vote to Zero Remove Its Voting Cooldown?: A successful zero-weight gauge vote starts another cooldown for that account and gauge. GaugeController records the successful zero-weight vote’s timestamp, so a replacement allocation must still satisfy the 10-day delay. Replacing the existing allocation directly avoids an unnecessary reset, provided the account already meets the timing and voting-budget requirements.
Will Adding CRV to an Existing Lock Refresh My Gauge Votes Automatically?: Increasing a CRV lock does not automatically incorporate its extra voting power into existing gauge votes. Extending the lock also requires a new vote to update those recorded contributions. The controller reads the lock’s slope and expiry when accepting a vote. Re-voting remains subject to the same-gauge cooldown, while personal boost updates follow the gauge’s checkpoint rules.
Can Someone Else Refresh My Recorded CRV Boost?: LiquidityGaugeV6 lets anyone call its kick function when the account satisfies the contract’s eligibility checks. The stored working balance must exceed the unboosted baseline. The account must also have either zero direct veCRV balance or a voting-escrow update later than its gauge checkpoint. A permitted call settles CRV accounting and recalculates the weight; it does not withdraw the account’s LP tokens.
What Happens to External Rewards If a Gauge Is Killed?: LiquidityGaugeV6’s killed status stops its CRV emission accounting while external rewards remain governed by their own funding schedules. Controller registration and positive voting weight cannot override that status. An external reward balance can therefore remain claimable while the CRV stream has stopped. Gauge administrators control this setting; additional veCRV from a depositor does not reverse it.
Whose veCRV Balance Matters When I Stake LP Tokens for Another Address?: LiquidityGaugeV6 calculates the boost using the beneficiary’s adjusted veCRV balance. A deposit transfers LP tokens from the transaction sender but credits the selected beneficiary, which defaults to the sender when no other address is specified. Funding another address’s stake does not attach the sender’s boost to it.