Fee Growth

Fee growth is measured as the amount of fees (in token units) earned per unit of virtual liquidity (L) since the pool's inception. It is stored as two global state variables: feeGrowthGlobal0X128 and feeGrowthGlobal1X128. These values accumulate independently for each token in the pair, scaled by 2¹²⁸ for precision. When a swap generates a fee, it is divided by the current total liquidity L and added to these global accumulators.

To determine a specific liquidity provider's (LP) earnings, the protocol tracks fee growth outside and inside each position. When liquidity is deposited or withdrawn, the contract snapshots the current global fee growth. The fees owed to an LP are calculated as: Fees_owed = (feeGrowth_global - feeGrowth_outside) * position_liquidity This design ensures fees are accurately attributed even as liquidity is added or removed by others.

In concentrated liquidity AMMs (e.g., Uniswap V3), fee growth is tracked per tick. Each tick boundary stores feeGrowthOutside0X128 and feeGrowthOutside1X128. This granular accounting is essential because liquidity (and thus fee accumulation) is not uniform across the entire price curve. To calculate fees for a position spanning multiple ticks, the protocol sums the fee growth inside its price range, excluding growth that occurred outside of it.

Fees are not automatically distributed; they compound within the pool as increased fee growth values. An LP must initiate a transaction to claim their fees, which triggers the fee calculation and mints the corresponding token amounts. Common claiming actions include:

• Collecting fees while keeping the position open.
• Withdrawing liquidity, which automatically claims any accrued fees.
• Adjusting a position's range or liquidity amount.

Fee growth data is critical for on-chain analytics to calculate Annual Percentage Yield (APY) and compare pool profitability. Analysts monitor:

• Fee Growth Rate: The increase in feeGrowthGlobal over time, indicating pool activity.
• Fee APR: (Δ feeGrowth / L) * 365 * 100.
• Position-Level ROI: Fees earned relative to the capital deposited. This data drives liquidity provider strategies and capital allocation decisions across different pools and price ranges.

Fee growth is stored as two global, ever-increasing 128-bit values: feeGrowthGlobal0X128 and feeGrowthGlobal1X128. These values represent the total fees earned per unit of virtual liquidity (L) for each token since the pool's inception. When a position is active, it captures the difference in these global values between the time of deposit and withdrawal to calculate its earned fees. This design ensures fees are allocated pro-rata to liquidity providers based on their share and the duration their capital was at risk.

The use of 128-bit fixed-point numbers for fee growth is a deliberate security and precision choice.

• Precision: Multiplying by 2^128 allows for extremely fine-grained tracking of fees per liquidity unit without floating-point errors.
• Overflow Safety: The values are designed to overflow only after millennia of continuous operation at maximum transaction volume, making the risk negligible. This is a classic example of safe smart contract arithmetic using checked math libraries to prevent exploits.

Each liquidity position stores its own feeGrowthInside0LastX128 and feeGrowthInside1LastX128. These snapshots record the fee growth values specific to its price tick range at the time of the last interaction. To claim fees, the contract calculates: feesEarned = (feeGrowthInsideNow - feeGrowthInsideLast) * positionLiquidity / 2^128 This design ensures accurate and fair distribution even as liquidity moves in and out of different price ranges, preventing fee leakage or miscalculation.

Fee growth is the metric that enables concentrated liquidity. By allowing LPs to target specific price ranges, the fee earnings per unit of capital (L) are amplified within that range compared to full-range liquidity. Higher fee growth in a range signals greater trading volume and competition for that price space. This creates a dynamic market for liquidity provision, aligning LP incentives with trader demand and optimizing overall capital efficiency in the Automated Market Maker (AMM).

The feeGrowthGlobal accumulators are manipulation-resistant data points that can be used by time-weighted average price (TWAP) oracles. While the current price is easy to manipulate in a single block, significantly altering the long-term fee growth rate requires sustained, economically irrational trading. This makes fee growth a potentially useful secondary signal for on-chain security and derivative protocols that need to assess genuine, long-term pool activity rather than transient price spikes.

Calculating feeGrowthInside for a position requires reading the fee growth accumulators at the lower tick, upper tick, and globally. This involves multiple storage reads and fixed-point arithmetic. While secure, this complexity contributes to higher gas costs for minting, modifying, or burning positions compared to simpler AMM designs. Protocol designers must balance this accounting overhead against the benefits of concentrated liquidity and precise fee distribution.

The transaction fees paid by traders to liquidity providers for using a pool. In Uniswap V3, these fees are the source of fee growth. Key characteristics:

• Set as a percentage of the swap amount (e.g., 0.05%, 0.30%).
• Accrued to the pool's global fee growth variables.
• Distributed proportionally to LPs based on their contributed liquidity and its active price range.

The discrete price intervals that define where concentrated liquidity can be placed. Fee growth is tracked per tick to calculate earnings for specific liquidity positions.

• A tick is a specific price point (e.g., price = 1.0001^i).
• Tick spacing is the minimum distance between ticks where liquidity can be provided (e.g., 10, 60, 200).
• Fee growth per unit of liquidity is stored for both above and below each initialized tick.

A capital efficiency model where LPs provide liquidity within a custom price range. This model directly interacts with fee growth mechanics.

• LPs earn fees only when the pool price is within their specified range.
• Fee growth outside a position's range does not accrue to that position.
• The system tracks fee growth inside a position's range using the values stored at its boundary ticks.

The core accumulator variable that tracks total fees earned per unit of virtual liquidity in the entire pool since inception. It is the foundation for calculating individual LP rewards.

• Represented as two 128-bit fixed-point numbers: feeGrowthGlobal0X128 and feeGrowthGlobal1X128 for each token.
• Increases with every swap.
• An LP's uncollected fees are calculated as the difference between the global fee growth and the fee growth last recorded by their position.

A value stored at each initialized tick, recording the fee growth per unit of liquidity that occurred below (for lower tick) or above (for upper tick) that tick. It is essential for computing fees earned by a specific position.

• Allows the protocol to calculate fee growth inside a position's range without iterating over all historical swaps.
• The formula: f_i = f_g - f_o(tick_lower) - f_o(tick_upper).

The fees that have accrued to a liquidity position but have not yet been claimed by the LP. This value is a derived state, not stored on-chain, calculated using fee growth variables.

• Calculated on-demand when an LP calls collect() or views their position.
• Formula: (f_g - f_i_inside_last) * liquidity, where f_i_inside_last is the fee growth inside the position the last time fees were collected or liquidity was modified.