# Constant Product Fees Methodology

## 1. Overview

Fees measures the total value paid by users to trade within Shadow Constant Product pools. This metric represents the total economic value generated by the protocol's liquidity pools, encompassing both the compensation distributed to liquidity providers and the portion retained by the protocol. Fees are primarily derived from trading activity and additional reward distributions on the Sonic blockchain.

## 2. Data sources

- **Blockchain events**: `Swap` events from `Pair` contracts, `PairCreated` events from `Factory` contracts, `SetPairFee` and `SetPairFeeSplit` events from `PairFactory` contracts, `setFeeSplit` function calls from `Pair` contracts, and `ClaimRewards` events from `Gauge` contracts, covering Sonic
- **External data**: End-of-day price feeds for assets and asset metadata

## 3. Step-by-step calculation

### Component A: Trading volume quantification

- **Purpose**: To calculate the gross value of assets swapped through Constant Product pools.
- **Logic**: `Swap` events are parsed from `Pair` contracts to identify the change in balances for both assets involved in a trade. Volumes are normalized by decimal precision for each asset. To mitigate the impact of price manipulation or illiquid asset pairs, the daily trading volume is calculated as the minimum USD value between the two assets involved in the swap.
- **Key fields**: `token0_amount`, `token1_amount`, `token0_decimals`, `token1_decimals`

### Component B: Dynamic fee parameter tracking

- **Purpose**: To identify the specific fee rates and protocol splits applicable to each pool at the time of a trade.
- **Logic**: Fee tiers are extracted from `SetPairFee` events emitted by `PairFactory` contracts. If no specific fee event is found for a pool, a default fee of 0.3% is applied. Protocol fee splits (the percentage of fees diverted to the protocol) are identified from `SetPairFeeSplit` events and `setFeeSplit` function calls. These parameters are tracked chronologically to ensure the correct rates are joined to swap events based on block numbers.
- **Key fields**: `fee_tier`, `fee_split`

### Component C: Trading fee derivation

- **Purpose**: To calculate the total fees generated from swap activity and determine their allocation.
- **Logic**: Total trading fees are calculated as the product of the daily trading volume and the pool-specific `fee_tier`. These fees are then bifurcated based on the `fee_split` parameter. The supply-side portion is calculated as `trading_volume * fee_tier * (1 - fee_split)`, while the protocol revenue portion is calculated as `trading_volume * fee_tier * fee_split`.

### Component D: Liquidity provider reward tracking

- **Purpose**: To capture additional value distributed to liquidity providers through reward claims.
- **Logic**: `ClaimRewards` events are parsed from `Gauge` contracts. Reward amounts are normalized by decimal precision and converted to USD using end-of-day price feeds. These claimed rewards are aggregated and classified as supply-side fees.
- **Key fields**: `amount`, `token_address`

### Component E: Final aggregation and normalization

- **Purpose**: To combine all fee components into a standardized daily USD metric.
- **Logic**: Total fees are calculated as the sum of trading-generated fees and claimed rewards. All components are normalized to USD using end-of-day price feeds and aggregated by day using UTC boundaries. Metric values are zero-filled for days where no activity is detected.

*This methodology was automatically generated by Token Terminal's methodology analyzer.*

Total value users pay to use a protocol (gross fees, user-paid fees).

Fees