github

twitter

discord

website

Exchanges (DEX)

Raydium

# Raydium Supply-side fees Methodology

## 1. Overview

Supply-side fees represent the portion of total trading fees that flows to liquidity providers rather than the Raydium protocol. This metric answers the question "How much revenue do liquidity providers earn from providing liquidity to Raydium pools?" The calculation follows a simple formula: Supply-side fees = Total fees - Protocol revenue. This methodology captures fees from all Raydium AMM variants including CPMM, CLMM, OpenBook, StableSwap, and LaunchLab.

## 2. Data sources

The methodology relies on several key data sources:
- **Solana DEX trades**: Parsed swap transactions from all Raydium AMM programs including CPMM, CLMM, OpenBook, StableSwap, and LaunchLab
- **Raydium program instruction logs**: Smart contract events for fee configuration management (`CreateAmmConfig`, `UpdateAmmConfig` instructions) and pool creation events
- **LaunchLab trading events**: Specialized `TradeEvent` instruction logs that capture platform-specific fee breakdowns
- **End-of-day token price feeds**: Daily USD prices for Solana tokens used in fee calculations
- **Token metadata**: Decimal places and address information for proper amount normalization
- **Solana transaction records**: Transaction-level data providing context for instruction parsing

## 3. Step-by-step calculation

### Component A: Total fees calculation
- **Purpose**: Calculate aggregate fees collected from all Raydium trading and pool creation activities
- **Logic**: Combines three fee sources. For trading fees, multiply trading volume by applicable trade fee rates, which vary by AMM type. CPMM and CLMM pools use dynamic rates from pool configurations (retrieved via temporal joins matching trade timestamps to fee configuration changes). OpenBook pools use a fixed 0.25% rate, StableSwap pools use 0.02%. Pool creation fees add a flat 0.15 SOL fee for each new CPMM pool. LaunchLab fees combine platform fees and protocol fees from specialized trading events.
- **Key fields**: `trading_volume_usd` (converted using end-of-day prices), `trade_fee_rate` (from pool configurations or hardcoded), `platform_fee` and `protocol_fee` (from LaunchLab events), `fee_amount` (0.15 SOL for pool creation)

### Component B: Protocol revenue calculation  
- **Purpose**: Calculate the portion of total fees that flows to the Raydium protocol rather than liquidity providers
- **Logic**: Uses the same transaction data but applies protocol-specific fee rates. For trading revenue, multiply trading volume by trade fee rate and then by the sum of protocol fee rate and fund fee rate (both rates come from pool configurations or are set to fixed values). Pool creation revenue includes the entire 0.15 SOL creation fee. LaunchLab revenue includes only the protocol fee portion, as platform fees flow to liquidity providers.
- **Key fields**: `protocol_fee_rate` and `fund_fee_rate` (from pool configurations), `protocol_fee_usd` (from LaunchLab events), `fee_amount_usd` (converted creation fees)

### Component C: Fee rate configuration management
- **Purpose**: Track dynamic fee rates for CPMM and CLMM pools over time
- **Logic**: Process `CreateAmmConfig` and `UpdateAmmConfig` instruction logs to build a temporal view of fee configurations. Create ordered sequences of fee changes using block slot and instruction index. Use window functions to fill forward fee rates when only partial updates occur. Apply temporal joins to match each trade with the active fee configuration at the time of execution.
- **Key fields**: `trade_fee_rate`, `protocol_fee_rate`, `fund_fee_rate` (all normalized from basis points to decimal), `amm_config` (pool configuration identifier), `order_id` (temporal ordering key)

### Component D: Price conversion and normalization
- **Purpose**: Convert native token amounts to USD values for consistent fee calculations
- **Logic**: Join trading data with end-of-day price feeds using timestamp and token address. Apply token decimal normalization to convert raw token amounts to standard decimal representation. For trading volume calculation, prioritize stable tokens (USDC, USDT) or SOL when available as the base for volume calculation, otherwise use the smaller of the two token amounts to avoid double-counting.
- **Key fields**: `price_usd` (from end-of-day feeds), `decimals` (from token metadata), `base_amount` and `quote_amount` (normalized token quantities)

### Final aggregation
- **Combining components**: Aggregate total fees by summing trading fees, pool creation fees, and LaunchLab fees by day, chain, and product. Similarly aggregate protocol revenue components. Daily aggregation uses `timestamp_trunc` to align all transactions to day boundaries.
- **Currency conversion**: All native token amounts are converted to USD using end-of-day price feeds matched by timestamp and token address. LaunchLab fees are normalized using token decimals before USD conversion.
- **Time aggregation**: All metrics are calculated on a daily basis using day-truncated timestamps. Incremental processing ensures only recent days are recalculated.
- **Final calculation**: Supply-side fees equals total fees minus protocol revenue. The union structure combines positive total fees with negative protocol revenue, then applies the finalization macro for metric standardization and chain availability filtering.

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

Portion of fees distributed to service providers or supply-side participants.

RaydiumRAY

Supply-side fees

Supply-side fees

Competitive landscape