# Concentrated Liquidity Fees Methodology

## 1. Overview

Fees measures the total value paid by users to trade within Shadow Concentrated Liquidity pools and the incentives provided to the ecosystem through bribes and rewards. This metric includes the swap fees paid by traders—which are distributed between liquidity providers and the protocol—as well as voting bribes and liquidity provider rewards. Fees serve as a primary indicator of the economic value generated by the Shadow Concentrated Liquidity product.

## 2. Data sources

- **Blockchain events**: `Swap` and `SetFeeProtocol` events from `Pool` contracts, `PoolCreated` events from `Factory` contracts, `FeeAdjustment` events from `PoolFactory` contracts, `ClaimRewards` events from `GaugeV3` contracts, and `VotesIncentivized` events from `FeeDistributor` contracts, covering Sonic
- **External data**: End-of-day price feeds for assets and asset metadata

## 3. Step-by-step calculation

### Component A: Trading volume extraction

- **Purpose**: Calculate the base volume upon which trading fees are applied.
- **Logic**: `Swap` events from `Pool` contracts are parsed to identify the change in asset balances for each trade. The absolute value of the change in `token0` and `token1` is extracted. To mitigate the impact of price manipulation, trading volume is calculated as the lesser USD value of the two assets involved in the swap.
- **Key fields**: `token0_amount`, `token1_amount`, `account_address` (pool address)

### Component B: Parameter tracking for fee tiers and splits

- **Purpose**: Identify the applicable fee rates and protocol share for each pool at any given time.
- **Logic**: `PoolCreated` events from `Factory` contracts and `FeeAdjustment` events from `PoolFactory` contracts are tracked to maintain a record of fee tiers per pool. Simultaneously, protocol fee splits are identified through `PoolCreated` events and `SetFeeProtocol` events from `Pool` contracts. These parameters are used to determine how much of the trading volume is captured as total fees and how those fees are partitioned between supply-side participants and protocol revenue.
- **Key fields**: `fee_tier`, `fee_split`

### Component C: Trading fee calculation

- **Purpose**: Determine the total fees generated from swap activities.
- **Logic**: Trading volume is multiplied by the active `fee_tier` for the respective pool. The resulting value is then categorized based on the `fee_split`. Supply-side fees are calculated as `volume * fee_tier * (1 - fee_split)`, while the protocol portion is calculated as `volume * fee_tier * fee_split`.
- **Key fields**: `trading_volume`, `fee_tier`, `fee_split`

### Component D: LP rewards and voting bribes

- **Purpose**: Capture additional value flows including incentives and governance-related fees.
- **Logic**: Incentive claims are extracted from `ClaimRewards` events from `GaugeV3` contracts and classified as supply-side fees. Governance-related incentives are parsed from `VotesIncentivized` events from `FeeDistributor` contracts and classified as protocol revenue.
- **Key fields**: `amount`, `token_address`

### Component E: USD conversion and aggregation

- **Purpose**: Normalize all fee components into a single USD-denominated metric.
- **Logic**: All asset amounts are normalized by their respective decimal precision. These values are multiplied by end-of-day price feeds. All components—including trading fees, rewards, and bribes—are summed to arrive at the total Fees metric. Data is aggregated with a daily granularity using UTC day boundaries.

*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