Curveswap gauge voting directs CRV emissions through veCRV allocations

Can one veCRV holder support several gauges?

A veCRV holder can split voting power across several approved gauges, provided the address’s total allocation stays within 100% of its available voting power. Each percentage describes how that address directs its influence. A holder may leave part unallocated, while each gauge receives support from everyone voting for it. The interface expresses these choices as percentages; the controller stores them in basis points. Allocating all personal voting power to a gauge still leaves its final emissions share dependent on the other effective weights.

Lock duration gives each allocation its voting strength

Four years is the maximum CRV lock duration, and remaining lock time determines voting strength alongside the amount locked in Ethereum’s VotingEscrow contract. veCRV represents vote-escrowed CRV and declines linearly toward the unlock date. A longer remaining duration gives the same locked amount greater influence. The lock continues independently of gauge selection, so choosing a gauge does not shorten it. Once the lock expires, its voting contribution reaches zero.

Relative weights connect individual votes to protocol emissions

The GaugeController combines each gauge’s voting weight with its gauge-type weight, then compares that product with the corresponding system-wide total. This normalization determines the gauge’s relative emissions share. Different type weights can change the relationship between raw voting weight and final allocation. Raw vote totals therefore do not describe the complete calculation. The controller records contributions with a size, decay rate and scheduled end. This allows support to decline as locks approach expiry. An unchanged allocation percentage can consequently carry less absolute influence over time.

Weekly activation and vote changes follow different clocks

Thursday at 00:00 UTC starts the weekly weight period, while a separate 10-day cooldown controls changes to an address’s allocation for each gauge.

The Ethereum GaugeController requires at least 10 days between votes from the same address for the same gauge. The restriction applies separately to each selected gauge for that address. Other gauge allocations retain their own update times, subject to the address’s total allocation limit.

The block timestamp of a successful vote determines which weekly boundary applies. A transaction that remains pending across the boundary cannot establish an allocation for the earlier period. New weight changes enter the next weekly cycle.

The Thursday update does not erase existing allocation percentages. They carry forward while their underlying voting strength decays. Repeating an unchanged vote every week is unnecessary, although changes to the CRV lock can require a refreshed vote.

Added CRV and lock extensions require refreshed votes

Adding CRV or extending an existing lock can increase veCRV, but previously recorded gauge votes do not automatically incorporate that extra voting power. Recasting the allocation refreshes its contribution using the updated lock. The per-gauge cooldown still governs that vote, and the change follows the normal weekly activation schedule.

A replacement vote can update the percentage directly. Setting it to zero first counts as a vote and starts the cooldown for that gauge. That prevents an immediate second change there. Moving influence between gauges also remains subject to the total-percentage limit, even when their next eligible update times differ.

DAO approval admits a gauge to the emissions system

View image file

A gauge must be added to the GaugeController through DAO governance before it becomes eligible for CRV emissions. Deploying a pool or gauge contract alone does not grant that eligibility.

An admission proposal can authorize adding the gauge. Weight voting then allocates influence among admitted gauges. Approval does not reserve an ongoing CRV allocation.

A gauge with zero effective relative weight receives no CRV allocation through that weight. The same distinction between admission and allocation applies to stablecoin pools and lending-market gauges.

Staking and boosting determine the depositor’s reward share

Voting selects where CRV emissions flow, while a liquidity gauge measures eligible deposited positions to calculate who earns that gauge’s rewards over time.

From pool liquidity to gauge rewards

A liquidity provider receives LP tokens representing a pool share. Staking eligible LP tokens in the pool’s gauge allows the position to accrue applicable CRV rewards. The voter and liquidity provider need not be the same address. Lending-market gauges can instead track eligible vault shares. Their deposited asset differs, although gauge voting supplies the common emissions-allocation mechanism.

The boost applies within the receiving gauge

The gauge’s CRV allocation

The controller determines the gauge-level emissions share. Increasing support can increase that share, subject to the other effective weights. The CRV emission rate also determines how much CRV that share represents.

The depositor’s CRV participation

The boost calculation uses the depositor’s eligible veCRV balance and share of staked liquidity. It can reach 2.5 times the unboosted reward-weight calculation when the gauge’s requirements are met. The percentage voted to that gauge does not enter this calculation. The boost leaves the gauge’s total CRV allocation unchanged, and external reward tokens cannot receive it.

External LP rewards and vote incentives have different recipients

External gauge rewards pay eligible depositors from supplied reward tokens, while vote incentives can compensate holders who direct voting power toward a gauge. These arrangements have separate funding and distribution conditions. Externally supplied LP rewards do not derive from the CRV inflation allocation.

Permissionless LP rewards do not require the DAO admission needed for native CRV emissions. Contract permissions still control reward administration. In LiquidityGaugeV6, the gauge manager or factory admin can register a reward token and its distributor. Only the assigned distributor can deposit that reward token. A voter-incentive arrangement has its own eligibility conditions, so an ordinary gauge vote does not automatically create a payment entitlement.

Cross-chain gauges receive Ethereum votes through root gauges

Ethereum remains the voting network when a supported gauge serves another chain, with a root gauge connecting the Ethereum allocation to its child gauge. The root receives weight through the GaugeController. Its linked child on the destination network handles deposited positions and local reward accounting. The voting target is the approved Ethereum root gauge; the child gauge serves the destination network.

In RootGauge version 1.0.0, emissions from a vote’s effective week can be minted for bridging only after that week ends. Root and child gauges need the proper linkage, and delivery also depends on their configured bridging infrastructure. The vote’s effective week alone does not establish when destination-chain rewards arrive.

Recorded votes and active weights describe different states

A vote record identifies an address’s allocation, while current relative-weight data identifies the share applying to a particular gauge and emissions week. A successful Ethereum transaction records the vote. A submitted transaction hash alone does not establish success. Voting incurs network gas costs independently of whether the voter supplies liquidity. Current and projected weight figures also need the same time basis for a meaningful comparison.

The gauge’s address, associated pool or lending market and destination network identify the target more precisely than its name alone. Voting history shows individual allocation changes. Historical relative weights show the collective outcome across time. Neither record, taken alone, describes an individual depositor’s claimable CRV balance.

Future emissions change with support and gauge status

A gauge’s future CRV allocation changes with its effective relative weight and the protocol’s emission rate, even when one voter leaves their percentage untouched. Increased support elsewhere can reduce its relative share. Changes in staked liquidity can also alter rewards per deposited share without changing that gauge’s emissions total.

In RootGauge version 1.0.0, the killed state sets its inflation rate to zero. A displayed vote allocation therefore cannot establish an active CRV stream by itself. Restoring root-gauge emissions requires the root-gauge factory’s owner to change that state. Additional voting weight does not perform that action.