Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Convex Finance Integration

This documentation outlines the technical implementation and related smart contracts for the Convex Finance protocol, and is intended for protocols and services integrating on top of Convex.

Convex boosts the rewards of both Curve liquidity providers and veCRV/veFXS/veFXN holders. On Ethereum mainnet, Convex manages Curve LP staking positions through a voting proxy that holds the protocol's veCRV, shares the boosted yield back to depositors, and mints the native token (CVX) pro rata with the CRV generated. The same "boost-as-a-service" pattern has been extended to other gauge systems using separate voting proxies. veFXS for the Convex/Frax platform and veFXN for the Convex/f(x) platform. Each of those platforms has its own fee model and does not generically mint CVX: see the cvxFXS and cvxFXN pages below.

Overview of the system

  • Booster — the main deposit contract. Users deposit Curve LP tokens and receive a 1:1 tokenized deposit ("deposit token") that can be staked for rewards.

  • Rewards (BaseRewardPool) — the reward contract used by the LP pools, plus ConvexRewardPool on sidechains.

  • CVX and cvxCRV Staking — staking contracts for the protocol's native tokens.

  • CVX Minting — how CVX is minted when CRV is claimed.

  • CVX Locking (vlCVX) — how CVX is locked for voting.

  • Staking Wrappers — how integrators tokenize a staked Convex position.

  • Convex-Frax Staking (cvxFXS) — Convex's boost platform for the Frax Finance gauge system.

  • Convex-Function(X) Staking (cvxFXN) — Convex's boost platform for the f(x) gauge system.

  • On-Chain Voting — the vote-locked governance layer for vlCVX holders.

  • Depositors & Token Conversions — converting CRV/FXS/FXN into cvxCRV/cvxFXS/cvxFXN.

  • Side Chain Implementation — notes for deploying on non-Ethereum chains.

Contracts

The mainnet platform contracts live at https://github.com/convex-eth/platform. The legacy/mainnet deployed-address list is maintained in contracts/contracts.json in that repository — treat it as an address source, not a complete current pool catalog (it contains a historical set of pool records; the live Booster.poolLength() is the authoritative pool count). Voting/registry deployments are separately listed in the voting repo's deployment/mainnet.json and on the live VotingRegistry. Verification/ABI tooling should always read addresses from the deployment files or from the live contracts.

Core entry points (Ethereum mainnet)

Contract
Address

Booster

0xF403C135812408BFbE8713b5A23a04b3D48AAE31

CVX token

0x4e3FBD56CD56c3e72c1403e103b45Db9da5B9D2B

cvxCRV token

0x62B9c7356A2Dc64a1969e19C23e4f579F9810Aa7

CrvDepositor

0x8014595F2AB54cD7c604B00E9fb932176fDc86Ae

CvxLockerV2 (vlCVX)

0x72a19342e8F1838460eBFCCEf09F6585e32db86E

CVX staking (stakerRewards)

0xCF50b810E57Ac33B91dCF525C6ddd9881B139332

cvxCRV staking (lockRewards)

0x3Fe65692bfCD0e6CF84cB1E7d24108E434A7587e

NextBooster

Last updated

Was this helpful?