# Meteora Liquidity Pools Fees Methodology

## 1. Overview

Fees are measured as the total economic value paid by traders to execute swaps within Meteora Liquidity Pools. This metric is utilized to evaluate the protocol's capacity to generate economic activity and compensate liquidity providers. Collected fees are distributed between liquidity providers as supply-side fees and the protocol treasury as protocol fees. Fee accrual is captured at the time of trade execution across V1 and V2 dynamic automated market maker (DAMM) pools, as well as dynamic liquidity market maker (DLMM) pools.

## 2. Data sources

- **Blockchain events**: `Swap`, `InitializePool`, `CreateConfig`, and `SetPoolFees` from `DAMM_v1` programs, `EvtSwap2`, `InitializePool`, `InitializeCustomizablePool`, and `InitializePoolWithDynamicConfig` from `DAMM_v2` programs, `Swap` and `LbPairCreate` from `DLMM` programs, `Migration` from `DBC` programs, Solana token balance changes, and DEX trades, covering Solana
- **External data**: End-of-day price feeds and asset metadata

## 3. Step-by-step calculation

### Component A: Pool initialization and metadata mapping

- **Purpose**: Map pool accounts to their respective asset mints and decimal precisions
- **Logic**: Pool configurations are established by parsing `InitializePool` from `DAMM_v1` programs, `InitializePool`, `InitializeCustomizablePool`, and `InitializePoolWithDynamicConfig` from `DAMM_v2` programs, and `LbPairCreate` from `DLMM` programs. Each pool account is mapped to its corresponding asset mints (Asset A and Asset B). Asset metadata is joined to retrieve decimal precisions for each asset.
- **Key fields**: `pool_account`, `token_a_mint`, `token_b_mint`, `token_a_decimals`, `token_b_decimals`

### Component B: DLMM fee calculation

- **Purpose**: Calculate swap fees for DLMM pools
- **Logic**: Fees for DLMM pools are parsed from `Swap` from `DLMM` programs. The total fee is captured from the `fee` field, which is inclusive of the host fee. Fee asset routing is determined by the pool's fee collection mode: under mode 0, fees are accrued in the swap's input asset (Asset X for trades swapping for Asset Y, and Asset Y otherwise); under mode 1, fees are always accrued in Asset Y.
- **Key fields**: `pool_account`, `swap_for_y`, `fee`, `protocol_fee`, `collect_fee_mode`

### Component C: DAMM V1 fee calculation

- **Purpose**: Calculate swap fees for V1 dynamic AMM pools
- **Logic**: Since V1 pools do not emit swap events with explicit fee fields, fees are derived by parsing `Swap` from `DAMM_v1` programs. The swap input amount is multiplied by the pool's active fee schedule, which is determined by parsing `SetPoolFees` from `DAMM_v1` programs, falling back to the default configuration from `CreateConfig` from `DAMM_v1` programs if no pool-specific fees were set. The fee asset is identified by matching the protocol fee account in the swap instruction with the pool's initialized protocol fee accounts. Total fees and protocol fees are calculated using the respective trade fee and owner trade fee numerators and denominators.
- **Key fields**: `pool_account`, `protocol_token_fee`, `amount`, `trade_fee_numerator`, `trade_fee_denominator`, `owner_trade_fee_numerator`, `owner_trade_fee_denominator`

### Component D: DAMM V2 fee calculation

- **Purpose**: Calculate swap fees for V2 dynamic AMM pools
- **Logic**: Fees for V2 pools are parsed directly from `EvtSwap2` from `DAMM_v2` programs. Total fees are calculated as the sum of the claiming fee, protocol fee, compounding fee, and referral fee fields. Protocol fees are extracted from the protocol fee field. The fee asset is determined based on the fee collection mode and trade direction: if the collection mode is set to zero, the fee is accrued in Asset B for trades from Asset A to Asset B, and in Asset A for trades from Asset B to Asset A; otherwise, the fee is accrued in Asset B.
- **Key fields**: `pool_account`, `trade_direction`, `collect_fee_mode`, `swap_result_claiming_fee`, `swap_result_protocol_fee`, `swap_result_compounding_fee`, `swap_result_referral_fee`

### Component E: Exclusion of migrated launchpad pools

- **Purpose**: Filter out pools that originated from bonding-curve graduations to prevent double-counting with Meteora Launchpad
- **Logic**: `Migration` from `DBC` programs is parsed to identify pools that graduated from bonding curves. Any DAMM V1 or DAMM V2 pool account matching a migrated pool is excluded from the Meteora Liquidity Pools product attribution and routed to Meteora Launchpad instead.
- **Key fields**: `pool_account`, `damm_version`, `dbc_virtual_pool`

### Component F: Wash trading filtration

- **Purpose**: Exclude inorganic pool-days to ensure fee metrics reflect organic trading activity
- **Logic**: Daily turnover is calculated for DAMM V2 (cp-amm) pools by dividing daily quote-leg volume by the quote-leg reserve from vault balances. Pool-days where the daily turnover exceeds a threshold of 20 are flagged as wash trading. These flagged pool-days are excluded from the fee calculations.
- **Key fields**: `pool_account`, `timestamp`, `turnover`, `quote_vol_native`, `quote_reserve_native`

### Component G: USD conversion and aggregation

- **Purpose**: Normalize fee amounts and convert them to USD
- **Logic**: Daily fee amounts and protocol fee amounts are aggregated by day, pool, and asset. The raw amounts are normalized by the decimal precision of each asset and multiplied by the corresponding end-of-day asset prices. Daily values are aggregated to produce the final Fees metric using UTC day boundaries.
- **Key fields**: `timestamp`, `token_address`, `fees`, `price_usd`

*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