Yield trackers, portfolio dashboards, and institutional accounting systems that display Curve or Frax metapool rewards must replicate the on-chain boost formula off-chain. A user's base reward rate is multiplied by a boost factor derived from their veFXS balance and the pool's total liquidity and working supply. Getting this calculation wrong leads to misreporting of expected yield, incorrect APY figures, and potential reconciliation failures for funds that rely on off-chain accrual estimates.
Protocols
Calculating Boosted Rewards in Curve and Frax Metapools
A technical recipe for analytics dashboards and portfolio trackers to calculate a user's boosted CRV, CVX, and FXS rewards from Curve and Frax metapools, using their veFXS balance and on-chain pool parameters.
introduction
BOOSTED REWARD CALCULATION
Introduction
How to correctly compute boosted CRV, CVX, and FXS rewards for liquidity providers in Curve and Frax metapools based on veFXS balances and pool-specific parameters.
The boost mechanism is governed by the veFXS derivative of the veCRV model. Each liquidity provider's earning weight is the minimum of their liquidity provided and a limit calculated as (user_veFXS / total_veFXS) * total_supply * 0.4. The effective boost is working_supply / user_lp_tokens, capped at 2.5x. The critical off-chain challenge is sourcing the correct total_veFXS, user_veFXS, and working_supply values at the specific block height of reward accrual, as these change with every user lock, extension, or withdrawal.
For Frax metapools specifically, the reward stream includes both CRV (and potentially CVX) from the Curve gauge and additional FXS incentives directed by Frax governance. The FXS reward rate per pool is not a constant; it depends on the pool's gauge weight, which is set by veFXS holder votes and can change weekly. Any off-chain reward calculator must therefore ingest both the on-chain boost parameters and the current gauge-relative weight to accurately project total yield.
Chainscore Labs can validate reward-calculation logic for data providers, portfolio trackers, and institutional reporting tools. This includes auditing the off-chain implementation against the on-chain GaugeController, VotingEscrow, and pool-specific contracts, ensuring that edge cases such as expired locks, delegated boosts, and gauge-weight transitions are handled correctly.
BOOSTED REWARD CALCULATION
Quick Facts
Key parameters and dependencies for computing boosted CRV, CVX, and FXS rewards in Curve and Frax metapools
| Field | Value | Why it matters |
|---|---|---|
Primary boost source | veFXS balance | Boost multiplier is derived from a user's veFXS holdings, not their LP token amount; off-chain calculators must query veFXS state correctly |
Boost formula dependency | Pool-specific parameters (total gauge weight, working supply, total supply) | Incorrectly reading or caching these on-chain values leads to systematic reward miscalculation across all users in a pool |
Reward tokens affected | CRV, CVX, FXS | Each reward token may have a different claim contract and distribution cadence; calculators must handle multi-token reward streams separately |
Off-chain data requirements | veFXS balance, pool working_supply, gauge weight, user LP balance, total gauge weight | Missing or stale data for any parameter produces inaccurate APY displays and misleads liquidity providers |
Common integration error | Using user's LP share instead of boost-adjusted working balance | Portfolio trackers that ignore the boost formula under-report rewards for veFXS holders and over-report for non-lockers |
Calculation complexity | Non-linear boost formula with min/max bounds | Simple proportional math is incorrect; integrators must implement the exact Curve boost formula including the working_supply cap |
Verification method | Compare off-chain computed rewards against on-chain claimable amounts | Discrepancies indicate a bug in parameter sourcing, formula implementation, or block-height alignment |
Chainscore service | Reward calculation logic audit and data pipeline validation | Chainscore can review your off-chain reward engine for formula correctness, data freshness, and edge-case handling |
technical-context
REWARD CALCULATION LOGIC
Technical Mechanism
The mathematical derivation of a user's boosted CRV, CVX, and FXS rewards in Curve and Frax metapools, based on their veFXS balance and pool-specific parameters.
Calculating a user's boosted rewards in a Curve or Frax metapool requires off-chain data integration that mirrors the on-chain earned() function, which is not a simple view call due to its dependence on the user's veFXS balance. The core formula derives a user's reward by taking the integral of their boosted liquidity share over time, multiplied by the reward rate. The boost itself is a function of the user's working_supply, which is the minimum of 40% of their staked LP tokens and their total staked LP tokens multiplied by their individual boost factor. This boost factor is calculated as min(veFXS_user / veFXS_total * total_lp_supply / user_lp_tokens, 1), creating a system where a user's veFXS balance directly amplifies their yield up to a maximum of 2.5x.
For an analytics dashboard or portfolio tracker, the precise calculation must be performed iteratively for each time interval between user actions (deposits, withdrawals, or veFXS balance changes). The process involves: 1) Fetching the user's working_supply and the pool's total_working_supply at the start of the interval. 2) Fetching the reward_per_token accumulator at the start and end of the interval. 3) Calculating the user's reward for the interval as user_working_supply * (end_reward_per_token - start_reward_per_token). 4) Summing these rewards across all intervals. This logic must be replicated for each reward token (CRV, CVX, FXS) as each has its own independent reward_per_token accumulator and reward rate.
The primary integration risk lies in incorrectly calculating the working_supply when a user's veFXS balance changes without a corresponding LP token event. A veFXS lock extension or a change in another user's veFXS balance alters the global veFXS_total, which can retroactively change a user's boost factor and their working_supply for past intervals. Data providers must therefore index all UpdateLiquidityLimit and CheckpointToken events and re-calculate rewards from the last checkpoint whenever a relevant veFXS state change occurs. Failure to do so results in a permanent and compounding accounting error in the displayed yield. Chainscore can validate this reward-calculation logic to ensure data integrity for yield trackers and portfolio management systems.
REWARD CALCULATION IMPACT
Affected Systems and Integrators
Data Providers and Yield Trackers
Analytics dashboards, portfolio trackers, and yield aggregators must implement the precise boosted reward formula to display accurate APY figures. The calculation depends on a user's veFXS balance, the pool's total working supply, and gauge-specific parameters.
Key integration points:
- Fetch the user's
working_balancefrom the Curve gauge contract, not just their LP token balance. - Query the
working_supplyand total gauge weight from on-chain state at the exact block height. - Derive the boost multiplier from
min(working_balance / (LP_tokens * 0.4), 2.5).
Action: Validate your reward-calculation pipeline against on-chain claimable_tokens read calls. Chainscore can audit your off-chain reward logic for precision errors and edge cases like expired locks or delegated veFXS.
implementation-impact
REWARD CALCULATION PIPELINE
Implementation Workflow and Data Sources
A step-by-step breakdown of the data sources, contract calls, and mathematical operations required to accurately calculate a user's boosted CRV, CVX, and FXS rewards in Curve and Frax metapools.
01
Identify User's Active Liquidity Position
Query the specific metapool's balanceOf(user) to get the user's LP token balance. For gauges, call depositedBalance(user) on the gauge contract to capture staked liquidity. This raw balance is the basis for the unboosted reward calculation. Analytics dashboards must handle the distinction between unstaked LP tokens and staked gauge deposits, as only the latter earn CRV and FXS emissions.
02
Fetch Pool-Specific Working Supply and Total Gauge Weight
Call working_supply() on the gauge contract to get the boosted total liquidity. Retrieve the pool's relative weight from the GaugeController via gauge_relative_weight(addr). These on-chain values are dynamic and change with veCRV and veFXS voting. Data pipelines must snapshot these at a consistent block height to avoid cross-block inconsistencies in reward rate calculations.
03
Calculate User's Boosted Working Balance
Apply the Curve boosting formula: min(user_lp * 0.4 + (total_lp * user_veFXS / total_veFXS) * 0.6, user_lp). This requires querying the user's veFXS balance and the total_veFXS supply from the Frax veFXS contract. The result is the user's working_balance, which determines their share of CRV and FXS rewards. Integrators must handle the min() logic correctly to avoid overstating boosts.
04
Derive CRV and FXS Reward Rates
CRV rewards flow at a rate determined by the GaugeController's inflation_rate and the pool's relative weight. FXS rewards are governed by the Frax FXSGaugeController or a similar contract. Call reward_data(token) on the gauge to get the current rate and period_finish. Off-chain systems must account for the discrete reward periods and decaying rates to project accurate APRs.
05
Compute User's Earned Rewards and CVX Bonus
The user's share of CRV is (user_working_balance / working_supply) * crv_rate * time. For CVX, apply the Convex multiplier logic if the user is staked through Convex, or calculate the claimable CVX based on the user's proportional share of minted tokens. FXS rewards follow the same proportional logic using the FXS-specific rate and the user's boosted balance. Chainscore can validate this multi-token accrual logic for yield trackers.
06
Validate Against On-Chain Earned Function
Use the gauge's earned(user) or claimable_reward(user, token) view functions as a ground-truth check. These functions compute rewards based on the global accumulator and the user's checkpoint. Off-chain calculations should reconcile with these on-chain values to within a few wei. Discrepancies often indicate incorrect working_supply or rate snapshots. Chainscore can perform independent reconciliation audits for data providers.
BOOSTED REWARD CALCULATION PITFALLS
Implementation Risk Matrix
Identifies common failure modes and affected parties when implementing off-chain logic to calculate boosted CRV, CVX, and FXS rewards for Curve and Frax metapools.
| Risk Area | Failure Mode | Severity | Mitigation |
|---|---|---|---|
veFXS balance snapshot | Using a user's current veFXS balance instead of the balance at the time the reward was earned, leading to incorrect boost calculation. | High | Query historical veFXS balances at the exact block height of each reward event using archive node calls or a subgraph. |
Total veFXS supply | Calculating a user's share of the total veFXS supply using a cached or incorrect totalSupply value from a different block. | High | Always fetch totalSupply() at the same block height as the user's historical veFXS balance to ensure the ratio is accurate. |
Pool-specific parameters | Hardcoding or incorrectly reading the pool's working_supply or total liquidity, which are dynamic and critical for the boost formula. | Medium | Query the pool's working_supply and totalSupply on-chain for each reward period. Validate against the canonical Curve registry. |
Derivative reward tokens | Failing to account for the conversion rate between a pool's LP token and its underlying assets when calculating a user's proportional share of rewards. | Medium | Implement logic to fetch the virtual_price or get_rate() from the pool contract to normalize LP token balances to underlying value. |
Multi-chain reward sources | Aggregating rewards from a single chain while ignoring FXS gauge emissions on sidechains or L2s where the user has liquidity. | Medium | Index all canonical gauge contracts across all chains where the metapool has active incentives. Cross-reference with the official Frax gauge list. |
Bribe and external incentives | Including only CRV, CVX, and FXS in calculations while omitting external bribe tokens (e.g., from Votium or Hidden Hand) that constitute a significant portion of yield. | Low | Integrate with bribe-market APIs or index bribe contract events to capture the full reward picture. Clearly label yield sources as 'base' vs. 'bribe'. |
Reward claiming vs. earning | Indexing only Transfer events from the reward token, which misses unclaimed rewards and misrepresents a user's accrued yield. | High | Call the earned() view function on the gauge contract for each user at each checkpoint, or decode the Checkpoint events to calculate accrued rewards. |
BOOSTED REWARD CALCULATION VERIFICATION
Integration Validation Checklist
A technical checklist for analytics dashboards, portfolio trackers, and yield aggregators to validate the correctness of their off-chain boosted reward calculation logic for Curve and Frax metapools. Each item identifies a specific failure mode, its operational impact, and the verification signal that confirms accurate implementation.
What to check: Confirm that your off-chain logic correctly derives the working_supply by summing the working_balances of all LPs in the pool, not by using the total LP token supply.
Why it matters: The working_supply is the denominator in the boost formula. Using the raw total supply ignores the amplification effect of veCRV or veFXS boosts, leading to a systemic under-calculation of individual user rewards.
Verification signal: Query the working_supply public getter on the pool's gauge contract on-chain and ensure your calculated value matches it exactly for a given block.
resource-links
CANONICAL INPUTS
Source Resources
Use these resources to validate boosted reward calculations for Curve and Frax metapools. Reward dashboards should combine protocol documentation with live contract reads and avoid hard-coding gauge, boost, or reward-token assumptions.
Chains We Build On
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos
Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
BOOSTED REWARD CALCULATION FAQ
Frequently Asked Questions
Common questions from analytics dashboards, portfolio trackers, and yield aggregators on correctly deriving a user's boosted CRV, CVX, and FXS rewards from Curve and Frax metapools.
A user's boosted CRV reward rate is derived from their share of the pool's gauge weight, modified by their individual boost factor. The fundamental formula is:
user_boosted_reward = (user_lp_tokens / total_lp_tokens) * gauge_emission_rate * min(boost_factor, max_boost)
Where:
user_lp_tokens: The amount of LP tokens the user has staked in the gauge.total_lp_tokens: The total LP tokens staked in the gauge.gauge_emission_rate: The CRV per second allocated to this specific gauge.boost_factor: Derived from the user's veCRV balance relative to their LP stake.max_boost: A protocol constant, typically 2.5x.
Why it matters: Without applying the boost factor, a dashboard will systematically under-report rewards for veCRV holders and over-report for non-lockers. The boost is not a fixed multiplier; it decays as the user's LP stake grows without a corresponding increase in their veCRV balance.
Verification signal: Your implementation should match the on-chain reward_data for a known user address queried via the gauge's claimable_reward function.
Trusted by Industry Leaders
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
L
Lee Erswell
CEO, Telos Foundation
how to get started
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
01
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
02
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
03
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
04
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Explore More Solutions
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Book a Call
Start a build
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.