# Raydium CLMM Trading volume Methodology

## 1. Overview

Trading volume for Raydium CLMM measures the total value of assets exchanged through the protocol's concentrated liquidity pools. This metric reflects the market activity and liquidity utilization of the Raydium CLMM product on Solana. Since trading fees are collected as a percentage of each swap, this metric serves as a primary indicator of the protocol's ability to generate revenue for liquidity providers and the protocol treasury.

## 2. Data sources

- **Blockchain events**: `CreatePool`, `CreateAmmConfig`, and `UpdateAmmConfig` instructions from the Concentrated Liquidity (CLMM) program, and parsed trade records from the Solana DEX trades system, covering Solana
- **External data**: End-of-day price feeds for assets including SOL, stablecoins, and other SPL tokens

## 3. Step-by-step calculation

### Component A: Trade identification and extraction

- **Purpose**: To isolate and capture swap activity specific to the Raydium CLMM program.
- **Logic**: Transactions are filtered where the executing account or the outer executing account matches the Raydium CLMM program identifier. Trade data is extracted from the indexed Solana DEX trades, specifically capturing the base asset mint, quote asset mint, base amount, and quote amount. Only transactions with valid pool addresses and non-null amounts are included in the dataset.
- **Key fields**: `base_amount`, `quote_amount`, `base_mint_address`, `quote_mint_address`, `pool_address`

### Component B: Normalization and fee mapping

- **Purpose**: To adjust raw transaction data into human-readable formats and link trades to their respective fee configurations.
- **Logic**: Raw asset amounts are normalized by their respective decimal precision retrieved from asset metadata. Trade records are joined with pool configuration data derived from `CreatePool` and `CreateAmmConfig` instructions to ensure each trade is associated with the correct fee tier. This association is maintained over time by tracking `UpdateAmmConfig` instructions to account for any parameter changes in the pool settings.
- **Key fields**: `trade_fee_rate`, `amm_config`, `base_amount`, `quote_amount`

### Component C: USD valuation and volume logic

- **Purpose**: To convert asset-level trade data into a standardized USD value while preventing double-counting or overestimation.
- **Logic**: Normalized asset amounts are multiplied by end-of-day price feeds. To prevent double-counting and minimize the impact of price volatility or illiquidity in long-tail assets, the lesser USD value of the two sides is selected as the canonical trading volume.
- **Key fields**: `price_usd`, `amount_0`, `amount_1`, `trading_volume`

### Component D: Final aggregation and normalization

- **Purpose**: To aggregate transaction-level data into a continuous daily time series.
- **Logic**: Individual trade volumes are summed by product, chain, and timestamp. The data is aggregated to a daily granularity using UTC day boundaries. Any dates without recorded activity are zero-filled to ensure a continuous and consistent dataset for analysis.
- **Key fields**: `timestamp`, `product_id`, `trading_volume`

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

Total value of spot trades executed on the exchange.

Trading volume

Exchanges (DEX)