> For the complete documentation index, see [llms.txt](https://docs.convexfinance.com/convexfinanceintegration/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.convexfinance.com/convexfinanceintegration/cvx-locking-vlcvx.md).

# CVX Locking (vlCVX)

**CVX** must be locked as **vlCVX** to participate in the voting process. The current locking contract is [CvxLockerV2.sol](https://github.com/convex-eth/platform/blob/main/contracts/contracts/CvxLockerV2.sol) (mainnet: `0x72a19342e8F1838460eBFCCEf09F6585e32db86E`, symbol `vlCVX`). It is a vote-escrowed token: your voting weight is derived from the amount you have locked, allocated into 16 weekly future epochs.

#### Quick Overview

* **CVX** is locked for 16 weeks (`lockDuration` = 16 × 7 days)
* Weekly epochs begin at Thursday 0:00 UTC (`rewardsDuration` = 7 days)
* Locks are anchored to **future epochs**: a fresh `lock()` starts the lock at the beginning of the *next* epoch plus the full lock duration, so your voting weight only becomes active from the next epoch onwards
* Voting power is 0 after depositing until the next epoch
* Each deposit/lock is grouped into weekly locks. These locks' unlock times are independent of each other. **Each non-expired full lock contributes its entire (boosted) amount** to your weight from its activation epoch until its expiry; as soon as a lock expires it drops out of your weight entirely — weight does **not** linearly decay with remaining lock time
* Expired locks can still gain platform fees. However they can be forcefully kicked (with an incentive to the kicker) if left unclaimed for too long

#### Kick incentive

Expired locks can be kicked by anyone after a grace period. The kicker is rewarded a portion of the expired position, growing per epoch of delay (both parameters governance-set):

* `kickRewardPerEpoch` — currently **25 bps** on mainnet (max 500 bps)
* `kickRewardEpochDelay` — currently **4 epochs** (minimum 2)
* Formula: kicker reward = `expiredLockAmount * min(kickRewardPerEpoch * (epochsOver + 1), 10000) / 10000` — i.e. **0.25**% of the expired position for the first eligible epoch after the grace delay, growing by **0.25**% per additional epoch.

Verify the live values with `kickRewardPerEpoch()` and `kickRewardEpochDelay()` on the locker before publishing — these are governance-adjustable.

#### Key functions

```javascript
//lock CVX for 16 weeks, _spendRatio is a bps boost spend (0 = no boost)
await vlcvx.lock(account, amount, spendRatio)

//add to an existing lock (same epoch weight), optionally relock
await vlcvx.processExpiredLocks(relock)        //relock expired positions
await vlcvx.withdrawExpiredLocksTo(to)         //claim expired positions to an address

//kick expired locks of another account (get rewarded with kickIncentive)
await vlcvx.kickExpiredLocks(account)

//view voting weight
await vlcvx.balanceOf(account)                          //current weight
await vlcvx.balanceAtEpochOf(epoch, account)            //weight snapshotted at an epoch
await vlcvx.totalSupplyAtEpoch(epoch)                   //total weight at an epoch
```

#### Boost

The platform can enable a "**boost**" on locks: a portion of a new lock (up to `maximumBoostPayment` bps of the deposit) can be spent to add a bonus of up to `boostRate` bps on top (i.e. `boostRate = 10000` means a +1x bonus, for up to 2x total boosted weight at maximum spend). Boost is **currently disabled** on mainnet because `maximumBoostPayment = 0` — so locked amount equals boosted amount until governance enables it. Check `boostRate()` **and** `maximumBoostPayment()` on-chain before assuming a boost is active.

#### ERC20-like interface

**vlCVX** exposes a reduced ERC20 surface (`name`, `symbol`, `decimals`, `totalSupply`, `balanceOf`) so it can be used as a balance read by voting tooling, but it is **not** transferable — balances are derived from locks.

#### Participation, delegation & EIP-1271

* **Off-chain (Snapshot) voting**: a smart-contract **vlCVX** holder participating in Snapshot voting must be able to delegate to an EOA address, or implement EIP-1271 so the contract can sign votes. Weight for off-chain voting is generally read via the `votingEligibility` / `votingBalance` helper contracts maintained by Convex.
* **On-chain voting** (DAO votes, gauge weight votes): handled by the dedicated voting platform, which authenticates the voter address or its registered surrogate directly (no EIP-1271) — see On-Chain Voting