Curvefi
Curvefi veCRV voting power declines as a CRV lock approaches expiry
Curvefi veCRV voting power declines linearly because it measures the CRV amount locked and the time remaining before expiry. The locked CRV balance stays unchanged unless more tokens enter the lock or an eligible withdrawal occurs. Extending an active lock raises its voting weight by moving the expiry later. Adding CRV also raises that weight, while leaving the expiry unchanged. Both changes preserve the lock’s withdrawal restrictions.
Updated:The short version: Extending an active CRV lock raises voting weight and delays withdrawal, while existing gauge votes need a separate update.
Proposal votes, gauge allocations, and reward eligibility
veCRV supplies voting weight for Curve DAO proposals and gauge allocations, alongside eligibility for protocol revenue and supported CRV reward boosts. Its name means vote-escrowed CRV. Proposal votes govern protocol decisions. Gauge votes allocate CRV emissions among approved reward contracts serving pools and lending markets. A liquidity gauge tracks staked liquidity and distributes rewards to eligible depositors.
These uses share an underlying voting balance but follow different accounting rules. Gauge allocations record lock data when votes are cast. Revenue distribution uses weekly historical balances. Supported liquidity gauges use a stored working balance for CRV reward calculations. A falling live veCRV balance therefore does not imply every displayed vote, boost, or accrued payment changes simultaneously. Maintaining voting weight and refreshing a particular allocation are separate operations.
Linear decay against a fixed unlock date
Voting weight depends on both the locked CRV amount and the remaining duration, with the maximum lock duration providing the denominator. The conceptual formula is locked CRV multiplied by remaining lock time, divided by maximum lock time. Both durations must use the same units. For an unchanged active lock, veCRV voting power declines linearly to zero at its recorded expiry.
The native VotingEscrow contract on Ethereum defines its maximum duration as four 365-day years and calculates elapsed time using seconds. A later expiry must stay within that maximum measured from the time of the change. For an unchanged deposit, the absolute rate of decline stays constant. Adding CRV increases the amount and the subsequent decay rate. Extending the expiry increases present weight without changing that rate for the same CRV amount. The contract rounds requested expiry timestamps down to weekly boundaries, so the recorded expiry controls the remaining duration at a given timestamp. Integer arithmetic introduces small differences from a simple decimal estimate of the same lock’s voting weight.
A wallet’s percentage of total veCRV can move differently from its absolute balance. Other locks also decay, receive deposits, or gain extensions.
Choices for the lock and its voting weight
Each address can hold at most one native CRV lock. Lock management changes the deposit, expiry, or use of voting weight through distinct options. Greater weight can require more CRV, a later withdrawal date, or both. Waiting preserves the recorded withdrawal date. The native escrow contract permits these choices only within their respective lock states.
| Choice | Effect on weight or withdrawal | Required lock state and inputs |
|---|---|---|
| Create a lock | Establishes voting weight from amount and expiry | No existing locked balance; CRV, escrow allowance, and a valid future expiry |
| Add CRV | Raises weight without changing expiry | Active lock, additional CRV, and sufficient escrow allowance |
| Extend expiry | Raises weight and delays withdrawal | Active lock and a later weekly expiry within the maximum duration |
| Leave the lock unchanged | Weight declines toward the existing withdrawal date | Existing lock; no update transaction required |
| Withdraw expired CRV | Returns the entire recorded CRV balance | Recorded expiry reached |
| Refresh a gauge vote | Updates the selected allocation using the latest lock data | Lock lasting beyond the next epoch; the gauge’s voting delay satisfied |
Gauge votes after a top-up or extension
Existing gauge votes retain the lock data recorded when the vote was cast until a valid replacement vote updates them. Increasing the escrow balance or expiry does not rewrite that stored allocation. The previously recorded weight continues its scheduled decay toward its recorded end. A higher live veCRV balance can therefore coexist with an older gauge allocation.
The GaugeController applies new allocations from the next weekly epoch, which begins on Thursday at 00:00 UTC. The GaugeController enforces a 10-day interval between a wallet’s successive votes for the same gauge. A new vote also requires the lock to remain active beyond the next epoch boundary. These conditions limit when increased voting power can influence emissions.
Resetting a gauge vote starts the same voting delay. Updating an allocation does not require clearing it first.
Current weight and historical records
VotingEscrow distinguishes the CRV amount in a lock from its time-weighted balance, so an unchanged deposit can coexist with falling veCRV. The contract’s locked record holds the amount and expiry. Its current balanceOf view evaluates voting weight at the relevant timestamp. Transaction history alone does not reveal current voting power, because time changes the balance between transactions.
The contract stores voting checkpoints with a weight and a rate of decline. Historical queries reconstruct earlier voting weight from those records. An extension affects the lock going forward; it does not replace its past state. A gauge allocation or fee snapshot can refer to a different accounting time than a live veCRV read. The wallet address, balance type, and relevant timestamp must match before two values can meaningfully be compared.
Expiry and withdrawal flexibility
Native CRV locks cannot be withdrawn early or partially. VotingEscrow’s withdraw function releases the entire recorded CRV balance only after expiry. Time decay removes voting weight, while escrow still holds the CRV until withdrawal. Extending the lock therefore exchanges a later redemption date for greater weight today. Extra CRV inherits the existing expiry. An expired lock cannot accept a top-up or extension; creating another lock requires withdrawing the old balance first. Selling or transferring veCRV cannot provide an exit, because its voting balance is non-transferable.
Weekly revenue and checkpointed boosts
Revenue allocation uses a wallet’s veCRV share at weekly snapshot times, together with fees available for the relevant period. Claiming later does not substitute today’s balance for an earlier eligible snapshot. Curve distributes this revenue in crvUSD, including portions of swap fees and interest from its stablecoin markets. A new lock first contributes at the weekly snapshot at or after its creation. Fees allocated to that week become claimable after it finishes and the distributor records the relevant balances. The distributed fee amount and total eligible voting weight also affect the payment.
Boosting concerns CRV emissions earned on liquidity staked in a compatible gauge. Its calculation depends on the wallet’s veCRV share, adjusted for boost delegation where supported, and its liquidity share within that gauge. The standard formula caps the working balance at the actual deposit, allowing up to a 2.5x increase over the unboosted working-balance baseline. This limit describes reward weighting, not a fixed increase in total return. Gauges refresh stored working balances at checkpoints or supported interactions. Live veCRV decay therefore need not appear as an identical second-by-second change in the stored boost.
Questions and answers about Curvefi veCRV
Does the CRV market price change the veCRV decay rate?
The veCRV decay calculation uses the locked CRV amount and time remaining, without a CRV market-price input. Price movements can change the value of the underlying CRV, while its voting-weight calculation follows the same time relationship. A display reporting monetary value therefore measures something different from the voting balance.
Can a transferable locked-CRV receipt give my address native veCRV voting power?
Holding a transferable receipt for locked CRV does not itself create native veCRV at the holder’s address. The underlying voting balance belongs to the address holding the VotingEscrow lock. A receipt product can provide separate voting arrangements under its own rules. Those arrangements do not make its receipt balance interchangeable with a direct veCRV balance.
Are multisig wallets allowed to manage veCRV locks directly?
Multisig and smart contract wallets can lock CRV directly under the upgraded SmartWalletChecker, which accepts all wallet addresses. The earlier contract-whitelisting requirement no longer applies. The wallet must still support the necessary contract calls and CRV approval, and the resulting veCRV belongs to that wallet address under the same decay and expiry rules.
Whose CRV does deposit_for use when it adds to another address’s lock?
The native deposit_for function draws CRV from the address whose lock receives the deposit, using that address’s allowance to VotingEscrow. Its caller can be a different address. The recipient must already have an active lock and sufficient CRV and allowance. This function cannot create a new lock or extend the recipient’s expiry.
Will claiming protocol revenue consume my veCRV voting balance?
Claiming protocol revenue transfers the distributable reward token without consuming veCRV or changing the CRV lock. The fee distributor accounts for eligible historical balances and previously claimed periods. Ordinary time decay continues between balance readings, so a later live balance can be lower even though claiming did not spend voting power.
Is revenue from earlier weeks claimable after my lock expires?
Revenue attributable to eligible earlier weekly balances can remain claimable after the lock expires, provided the relevant fee distributor remains enabled and the revenue remains unclaimed. Expiry stops future voting weight; it does not erase the historical balance used for those earlier allocations. Claim eligibility follows the recorded periods rather than the current veCRV balance alone.
Which gauge rewards can veCRV boost?
The standard veCRV boost applies to CRV emissions earned by staked liquidity in a supporting gauge. External reward tokens follow their own liquidity-share accounting and do not receive that boost. Increasing veCRV therefore does not multiply every reward shown for a position. Protocol revenue distributed to veCRV holders is also a separate allocation.
What units do raw veCRV balance readings use?
Raw veCRV balances use integer base units with the decimal scaling VotingEscrow reports through its decimals field. A human-readable balance divides the returned integer by ten raised to that decimal count. The result measures voting weight. Applying token formatting does not turn it into an amount of transferable CRV or a fee payment.