github

twitter

discord

website

Exchanges (DEX)

Raydium

# Raydium Trading volume Methodology

## 1. Overview

The daily USD value of assets traded across Raydium's decentralized exchange protocols on Solana is measured by Raydium trading volume. Trading activity is captured from five distinct Raydium product variants: Raydium CPMM, Raydium CLMM, Raydium OpenBook, Raydium Stable Swap, and Raydium LaunchLab. Trade volumes are aggregated by day, and the representative trading volume for each swap is determined as the lesser USD value of the two traded assets to ensure double-counting is prevented.

## 2. Data sources

- **Blockchain events**: Swap transactions are extracted from the Solana decentralized exchange program, and `CreateAmmConfig`, `UpdateAmmConfig`, `CreatePool`, and `Initialize` instructions are parsed from Raydium programs, covering Solana
- **External data**: End-of-day price feeds and asset metadata are utilized

## 3. Step-by-step calculation

### Component A: Raw trade extraction across Raydium products

- **Purpose**: All Raydium swap transactions are extracted from Solana DEX trade data
- **Logic**: Solana DEX trades are filtered for transactions involving five specific Raydium program accounts: Raydium CPMM (`CPMMoo8L3F4NbTegBCKVNunggL7H1ZpdTHKxQB5qKP1C`), Raydium CLMM (`CAMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK`), Raydium OpenBook (`675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8`), Raydium Stable Swap (`5quBtoiQqxF9Jv6KYKctB59NT3gtJD2Y65kdnB1Uev3h`), and Raydium LaunchLab (`LanMV9sAd7wArD4vJFi2qDdfnVhFxYSUg6eADduJ3uj`). Data quality filters are applied to ensure base amount, base mint account, base vault account, quote amount, quote mint account, quote vault account, and pool account are all present and non-empty. Trade amounts are normalized by dividing by the decimal precision of each asset.
- **Key fields**: `block_timestamp`, `transaction_id`, `pool_address`, `base_mint_address`, `quote_mint_address`, `base_amount`, `quote_amount`, `transaction_signer`

### Component B: Fee configuration tracking for Raydium CLMM and Raydium CPMM

- **Purpose**: Applicable trading fees are determined for each pool over time
- **Logic**: Fee configuration instructions are combined from `CreateAmmConfig` and `UpdateAmmConfig` instructions for both Raydium CLMM and Raydium CPMM programs. Three fee types are tracked: trade fee rate, protocol fee rate, and fund fee rate. Temporal intervals are created using order IDs based on block slot and instruction sequence. Unchanged fee values are carried forward when only specific parameters are updated. Pools are mapped to their AMM configurations through `CreatePool` and `Initialize` instructions.
- **Key fields**: `amm_config`, `trade_fee_rate`, `protocol_fee_rate`, `fund_fee_rate`, `order_id`, `next_order_id`

### Component C: Fee rate application across Raydium products

- **Purpose**: The correct fee rates are applied to each trade based on timing and product type
- **Logic**: Trades are joined with fee configuration data using temporal logic where the trade order ID is located between the fee setting order ID and the next order ID. Product-specific fee logic is applied: dynamic fees from AMM configurations (normalized by decimal precision) are applied for Raydium CPMM and Raydium CLMM, fixed rates (0.25% trade, 3% protocol) are applied for Raydium OpenBook, fixed rates (0.02% trade, 0% protocol/fund) are applied for Raydium Stable Swap, and Raydium LaunchLab fees are set to null for separate tracking.
- **Key fields**: `trade_fee_rate`, `protocol_fee_rate`, `fund_fee_rate`

### Component D: Daily aggregation by pool

- **Purpose**: Individual trades are aggregated to daily totals per pool to reduce data volume
- **Logic**: Trades are grouped by day, chain, product, pool, ordered asset accounts, and fee rates. Absolute values of base and quote amounts are summed and mapped to ordered asset accounts (`amount_0` and `amount_1`) to maintain consistent asset tracking regardless of swap direction.
- **Key fields**: `timestamp`, `amount_0`, `amount_1`

### Component E: Trading pair metadata mapping

- **Purpose**: Asset metadata is mapped and trading pair identifiers are constructed
- **Logic**: Aggregated trade volumes are joined with asset metadata for asset symbol retrieval. Trading pair identifiers and names are constructed by ordering the assets, with stablecoins or fiat-pegged assets placed second, or sorted alphabetically if both or neither are fiat-pegged.
- **Key fields**: `token_symbol_0`, `token_symbol_1`, `trading_pair_id`, `trading_pair_name`

### Component F: USD conversion and double-counting prevention

- **Purpose**: Asset volumes are converted to USD and the representative trading volume is determined
- **Logic**: Daily asset volumes are multiplied by their respective end-of-day prices. To ensure double-counting of swaps is prevented and unpriced assets are handled, the final representative trading volume for each pool is determined as the lesser USD value of the two traded assets.
- **Key fields**: `trading_volume_0`, `trading_volume_1`, `trading_volume`

### Component G: Final aggregation and forward filling

- **Purpose**: Trading volumes are aggregated and complete time series coverage is ensured
- **Logic**: Trading volumes are aggregated across all pools and products by day. Standard metric schema validation is applied, and the time series is finalized to ensure complete daily coverage with zero values applied to inactive days.
- **Key fields**: `timestamp`, `trading_volume`

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

Total value of spot trades executed on the exchange.

RaydiumRAY

Trading volume

Trading volume

Competitive landscape