Can I add CRV to my existing lock without extending its expiry?

Adding CRV to an unexpired VotingEscrow lock leaves its existing unlock date unchanged. The additional tokens use the same remaining lock time when contributing to veCRV. The lock must already contain CRV and must not have expired. Extending the date is a separate operation, and an expired lock requires withdrawal before the address can create a new one.

Does boosting several gauges split my veCRV balance between them?

Standard Ethereum liquidity gauges read the address's eligible veCRV balance independently for personal boosting. Each gauge applies its own liquidity balances, so the same address can have different multipliers across positions. Gauge-weight votes divide an allocated voting budget among gauges; that separate governance allocation does not divide the veCRV balance used in the personal boost calculation.

Are additional gauge incentives multiplied by my veCRV boost?

External reward tokens distributed through a gauge do not receive the native CRV emission boost. Their accounting uses the address's share of deposited LP tokens, rather than its boosted working balance. This is why a position can have boosted CRV emissions alongside unboosted incentives. The mechanism that distributes a reward determines which balance applies to it.

Can a smart-contract wallet create a CRV lock for boosting?

Curve's upgraded SmartWalletChecker permits smart-contract wallets to create CRV locks without an individual whitelist entry. The wallet still needs to authorize the CRV transfer and call the lock-management functions. Its contract address owns the lock, and the normal expiry and non-transferability rules apply. Personal gauge boosting uses the eligible balance attributed to the address that holds the staked position.

Curveswap CRV Rewards and veCRV Boosting

Curveswap can increase a staked liquidity position's CRV reward weight through veCRV, or vote-escrowed CRV, the voting power obtained by locking CRV. Boosting requires an eligible gauge, and the multiplier depends on voting power relative to the position's share of gauge-staked liquidity. The standard mechanism caps the multiplier at 2.5x, while the CRV lock remains separate from the liquidity position.

Liquidity provider (LP) tokens represent a share of pool liquidity, while the gauge assigns a separate weight for distributing incentives. A boost changes that weight. Locking more CRV can increase reward weight without increasing the pool share that those tokens represent.

Key takeaway: The standard gauge reaches full boost when eligible veCRV share matches or exceeds the position's share of gauge-staked liquidity.

Unboosted staking, personal boosts, and shared boosts

An eligible gauge can distribute CRV without a personal lock, while direct veCRV and pooled staking provide different boost arrangements. With direct staking, the gauge records the staked LP balance against the address and uses its eligible voting power. A pooling platform stakes through its own contracts and shares rewards under its own rules. Its communal veCRV can support depositors who hold none personally. Pooling introduces the platform's fee rules and contract dependencies, while direct locking commits the address's CRV until its recorded expiry.

Locked CRV and the voting power that decays

veCRV measures time-weighted voting power, so its balance depends on both the CRV amount and the time remaining until unlock. VotingEscrow holds the deposited CRV while recording that power for the locking address. The veCRV balance falls linearly toward zero as expiry approaches. The locked CRV amount does not shrink through this decay, and veCRV itself cannot be transferred between wallets.

The standard VotingEscrow contract limits a CRV lock to four years from the time it is created or extended. Lock end times are rounded down to whole weeks. The recorded unlock timestamp therefore determines access to the CRV, even when an interface starts from a requested calendar date.

A longer remaining lock supplies more veCRV for the same CRV amount, while postponing access to those tokens. Liquidity withdrawals do not release locked CRV: the liquidity gauge and VotingEscrow hold different assets.

How does veCRV change the CRV reward calculation?

veCRV increases a position's working balance, which determines its share of the native CRV emissions that a gauge distributes. A working balance is an accounting weight measured in LP-token units. The standard Ethereum LiquidityGaugeV6 calculation starts with 40% of the address's staked LP balance. It then adds a contribution based on eligible veCRV, subject to a cap.

Ignoring integer rounding, the relationship is w = min(b, 0.4b + 0.6S(v/V)), when V is positive. Here, b is the address's staked LP balance, and S is the gauge's total staked LP balance. Both quantities use the same LP token and include the position being evaluated.

The variable v represents the eligible veCRV balance read through the gauge's boost proxy. V represents the total VotingEscrow supply that the gauge uses. The proxy can supply an adjusted balance. Wallet CRV holdings that have never been locked do not contribute to that voting-power term.

The boost factor is w/(0.4b) for a positive staked balance, giving a range from 1x to 2.5x. LiquidityGaugeV6 caps an address's working balance at its deposited LP-token balance. Reaching the cap increases reward weight without creating additional LP tokens or enlarging the address's ownership of pool assets.

The gauge distributes native CRV emissions according to each working balance relative to its working supply, the sum of those balances. Consequently, a multiplier alone cannot establish the CRV amount that an address will earn. Other positions' boosts change that denominator, and the gauge's emission allocation can change independently. LiquidityGaugeV6 supplies this Ethereum calculation; other gauge implementations can read voting-power balances differently.

Table: How does veCRV change the CRV reward calculation?
Parameter	Value	Contract scope	Effect on control or accounting
Maximum lock horizon	4 years	Standard VotingEscrow	CRV stays in escrow until the recorded expiry
Lock-end granularity	Whole weeks, rounded down	Standard VotingEscrow	The stored timestamp controls when withdrawal is allowed
Base working-balance coefficient	40% of the staked LP balance	LiquidityGaugeV6	Accounting weight without an eligible veCRV contribution
veCRV contribution coefficient	60% of gauge supply multiplied by the eligible veCRV share	LiquidityGaugeV6	Changes reward weight without changing LP ownership
Working-balance ceiling	100% of the address's staked LP balance	LiquidityGaugeV6	Limits the effective balance used for CRV allocation
Boost-factor ceiling	2.5x the base working balance	LiquidityGaugeV6	Caps the accounting multiplier, without setting a yield

The standard formula reaches its cap when the eligible veCRV share matches or exceeds the address's share of gauge-staked LP tokens. The relevant liquidity denominator is the gauge's staked supply, which can differ from the pool's total liquidity. A larger share of gauge liquidity needs a correspondingly larger voting-power share to retain the full boost. Changes in total veCRV supply also affect that requirement. A smaller calculated multiplier can therefore reflect changed relative balances even when the locked CRV amount is unchanged.

When does a changed veCRV balance reach the gauge?

LiquidityGaugeV6 refreshes an address's working balance during a user checkpoint or a balance-changing gauge action. The contract stores this weight between updates. A confirmed change to the CRV lock updates VotingEscrow, but it does not automatically rewrite the stored balance in every liquidity gauge where that address has a position.

A user checkpoint first accounts for the CRV accrued under the previous working balance, then calculates the updated weight. The address itself or the CRV Minter can invoke this checkpoint. Claiming native CRV through the Minter performs that accounting, while LP deposits and withdrawals also update the affected balance. The gauge's external-reward claim function uses separate accounting and does not refresh the CRV working balance.

An expired lock has zero personal veCRV. Anyone may call kick in LiquidityGaugeV6 when the working balance exceeds the unboosted floor and either personal veCRV is zero or VotingEscrow has a newer user checkpoint than the gauge. The function accounts for accrued CRV and recalculates the working balance without withdrawing LP tokens or resetting the CRV unlock date.

Gauge votes, emissions, and the limits of a yield quote

Gauge-weight voting changes the allocation of CRV emissions among eligible gauges, while personal boosting changes an address's share within its gauge. The boost calculation does not require the address to vote for that same gauge. Gauge votes take effect on the weekly cycle, and their allocation rules are separate from personal working-balance updates. A gauge also needs approval through Curve governance and an emission allocation to receive native CRV incentives.

A displayed reward range reflects unboosted and boosted estimates under the inputs used for that display. The earned amount also depends on the emission rate, gauge weight, and competing working balances over time. Annualized monetary returns introduce token prices and valuation assumptions. Boosting changes reward allocation without improving swap slippage or protecting the assets behind an LP position. A higher multiplier cannot create emissions for a gauge whose CRV emission rate is zero.

Cross-chain voting-escrow data

Cross-chain boosting uses voting-escrow information from Ethereum through an oracle configured for the child gauge's network. Root gauges on Ethereum receive emission allocations, and child gauges account for positions on the destination chain. In the ChildGauge system, a configured L2 VotingEscrow Oracle supplies the voting-power data needed for boosting. A child gauge with no voting-escrow source cannot apply that veCRV contribution. Receiving cross-chain CRV emissions does not by itself enable personal boosts.

The Updater-based messaging route transmits voting-escrow information from Ethereum to a compatible destination oracle. A new lock or lock adjustment can take time to reach that destination. The child gauge calculates from the voting balances and supply available there, so an Ethereum balance alone does not establish the boost currently recorded on another network. Transmission of voting data does not move the locked CRV out of Ethereum escrow.

Pooled positions and control over rewards

A pooled staking platform applies boosting to the position that its contracts hold in a Curve gauge, then allocates rewards to depositors. Its boost depends on its eligible veCRV relative to that pooled position's share of gauge liquidity. Additional deposits can reduce the pooled multiplier when voting power does not increase correspondingly. A large communal lock therefore does not establish a permanent maximum boost for every supported pool.

Open full-size image

Direct staking keeps gauge accounting attached to the staking address, while pooling introduces the platform's reward distribution, fees, and withdrawal rules. Depositing LP tokens into such a platform differs from converting CRV into a liquid-locker token. A transferable locker token does not make the underlying veCRV transferable, and its redemption terms are separate from LP withdrawals. A personal CRV lock follows VotingEscrow's expiry, whereas a pooled LP position follows the staking platform's contracts.

Curveswap: quick answers

Can I add CRV to my existing lock without extending its expiry?: Adding CRV to an unexpired VotingEscrow lock leaves its existing unlock date unchanged. The additional tokens use the same remaining lock time when contributing to veCRV. The lock must already contain CRV and must not have expired. Extending the date is a separate operation, and an expired lock requires withdrawal before the address can create a new one.
Does boosting several gauges split my veCRV balance between them?: Standard Ethereum liquidity gauges read the address's eligible veCRV balance independently for personal boosting. Each gauge applies its own liquidity balances, so the same address can have different multipliers across positions. Gauge-weight votes divide an allocated voting budget among gauges; that separate governance allocation does not divide the veCRV balance used in the personal boost calculation.
Are additional gauge incentives multiplied by my veCRV boost?: External reward tokens distributed through a gauge do not receive the native CRV emission boost. Their accounting uses the address's share of deposited LP tokens, rather than its boosted working balance. This is why a position can have boosted CRV emissions alongside unboosted incentives. The mechanism that distributes a reward determines which balance applies to it.
Can a smart-contract wallet create a CRV lock for boosting?: Curve's upgraded SmartWalletChecker permits smart-contract wallets to create CRV locks without an individual whitelist entry. The wallet still needs to authorize the CRV transfer and call the lock-management functions. Its contract address owns the lock, and the normal expiry and non-transferability rules apply. Personal gauge boosting uses the eligible balance attributed to the address that holds the staked position.

Updated on 8 Oct 2026