github

twitter

discord

website

Exchanges (DEX)

Raydium

# Raydium Active users (daily) Methodology

## 1. Overview

The Raydium Daily Active Users (DAU) metric measures the number of unique addresses that executed at least one trade on any Raydium protocol product during a given day. This metric provides insight into daily user engagement across Raydium's various automated market maker (AMM) and concentrated liquidity products. The calculation identifies distinct trader addresses (signers) per day by analyzing all successful trading transactions across five Raydium product lines.

## 2. Data sources

The methodology relies on the following data sources:

- **Pre-aggregated Solana DEX trades**: Processed swap transaction data from the Solana blockchain that includes trade details, participant addresses, token information, and program identifications across multiple DEX protocols
- **Raydium program instruction logs**: Raw Solana blockchain instruction logs from five specific Raydium programs:
  - CPMM (Constant Product Market Maker) program instructions for standard AMM operations
  - CLMM (Concentrated Liquidity Market Maker) program instructions for concentrated liquidity operations  
  - OpenBook program instructions for legacy AMM v4 operations
  - StableSwap program instructions for stable asset swaps
  - LaunchLab program instructions for token launches
- **Pool configuration instruction logs**: Blockchain instruction logs that capture pool creation events (`CreatePool`, `Initialize`) linking pools to fee configuration addresses
- **Fee configuration instruction logs**: Blockchain instruction logs that capture fee setting creation and updates (`CreateAmmConfig`, `UpdateAmmConfig`) with timestamps for dynamic fee tracking

## 3. Step-by-step calculation

### Component A: Trade data extraction and filtering
- **Purpose**: Extract all Raydium trading activity from Solana blockchain data and ensure data quality
- **Logic**: The process begins by identifying Raydium trades from pre-aggregated Solana DEX data. Trades are identified by filtering for transactions where either the outer program or inner program matches one of five specific Raydium program addresses. The system applies comprehensive data quality filters to ensure complete trade records, removing any transactions with null or empty values for critical fields including base amounts, quote amounts, token mint addresses, vault addresses, and pool addresses. Each trade is classified into one of five product categories based on the program ID and assigned a surrogate key and order ID for tracking purposes.
- **Key fields**: Critical fields include `signer` (trader address), `block_timestamp` (transaction timing), `outer_program` and `inner_program` (program identifications), `pool_address` (trading pool), `base_amount` and `quote_amount` (trade volumes), `base_mint` and `quote_mint` (token addresses), and `base_vault` and `quote_vault` (pool vault addresses)

### Component B: Fee configuration tracking
- **Purpose**: Establish dynamic fee rates for pools that can have their fees updated after creation
- **Logic**: This component builds a historical view of fee configurations by processing two types of instruction logs. First, it creates a mapping between pool addresses and their fee configuration addresses by extracting pool creation instructions from CLMM and CPMM programs. Second, it tracks fee rate changes over time by combining fee configuration creation and update instructions. The system uses window functions to fill forward missing fee values when only specific parameters are updated, creating continuous time intervals for fee rate application. Order IDs ensure proper temporal sequencing of fee changes.
- **Key fields**: Key fields include `amm_config` (fee configuration address), `trade_fee_rate`, `protocol_fee_rate`, and `fund_fee_rate` (various fee components), `block_timestamp` and `order_id` (temporal tracking), and `pool_address` (pool identification)

### Component C: Trade enrichment with fee data
- **Purpose**: Combine trading activity with appropriate fee rates based on transaction timing
- **Logic**: This step enriches each trade with the correct fee rates by performing temporal joins between trades and fee configurations. For CPMM and CLMM products, the system matches each trade to the appropriate fee configuration that was active at the time of the transaction using order ID comparisons. For OpenBook, StableSwap, and LaunchLab products, hardcoded fee rates are applied since these products use fixed fee structures. The temporal join ensures that trades are matched with the fee configuration that was active at the time of execution.
- **Key fields**: The enriched dataset includes all original trade fields plus calculated `trade_fee_rate`, `protocol_fee_rate`, and `fund_fee_rate` values expressed as decimal percentages

### Final aggregation
- **Combining components**: The final DAU calculation processes the enriched trade data by selecting distinct combinations of daily timestamp, chain identifier, user type (always classified as 'Trader'), product identifier, and signer address
- **Time aggregation**: Block timestamps are truncated to day granularity using timestamp truncation functions, establishing clear daily boundaries for user activity measurement
- **Final calculation**: The metric counts each unique signer address only once per day per product, regardless of how many trades they executed. The result provides the count of distinct active trader addresses for each day across all Raydium products, with chain availability filtering applied to ensure data completeness and reliability

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

Unique revenue-generating users over a fixed 24-hour window.

RaydiumRAY

Active users (daily)

Active users (daily)

Competitive landscape