github

twitter

discord

website

Exchanges (DEX)

Raydium

# Raydium Active users (monthly) Methodology

## 1. Overview

Raydium Monthly Active Users (MAU) measures the number of unique traders who executed at least one trade on the Raydium decentralized exchange within a rolling 30-day period. This metric answers the business question of user engagement and platform adoption by tracking distinct trading addresses across Raydium's various AMM products. The calculation uses HyperLogLog algorithms for efficient distinct user counting across multiple dimensional breakdowns including overall protocol, chain, user type, and product-specific views.

## 2. Data sources

- **Solana DEX trades**: Parsed Solana blockchain trading events containing user addresses, transaction details, amounts, token information, and pool identifiers across Raydium's DEX protocols
- **Raydium instruction events**: Solana program instruction logs from multiple Raydium variants including CLMM (Concentrated Liquidity Market Maker), CPMM (Constant Product Market Maker), OpenBook integration, StableSwap, and LaunchLab programs
- **Fee configuration events**: Blockchain events tracking AMM configuration creation (`CreateAmmConfig`) and updates (`UpdateAmmConfig`) that establish and modify trading fee rates over time
- **Pool initialization events**: Instructions from `CreatePool` and `Initialize` events that map individual pools to their corresponding fee configurations
- **Blockchain transaction metadata**: Solana transaction identifiers, block timestamps, instruction indices, and execution ordering information

## 3. Step-by-step calculation

### Component A: Fee configuration tracking
- **Purpose**: Establishes the fee rate settings for each AMM configuration across time periods
- **Logic**: Combines fee configuration creation events from CLMM and CPMM programs with their subsequent update events. Creates chronological ordering using formatted strings based on block slots and instruction parameters. Tracks three fee types: `trade_fee_rate`, `protocol_fee_rate`, and `fund_fee_rate`. Uses window functions to fill forward fee rates when only partial updates occur, ensuring each configuration has complete fee information at any point in time.
- **Key fields**: `amm_config` (configuration identifier), fee rate fields normalized by dividing raw values by 1,000,000, `order_id` for temporal sequencing

### Component B: Pool-to-configuration mapping
- **Purpose**: Links individual trading pools to their corresponding AMM fee configurations
- **Logic**: Extracts the relationship between pool addresses and AMM configurations from pool creation events. Combines data from both CLMM `CreatePool` instructions and CPMM `Initialize` instructions to capture all pool types. Creates a static mapping table since pool-to-config relationships don't change after pool creation.
- **Key fields**: `pool_address` (unique pool identifier), `amm_config` (links to fee configuration data)

### Component C: Trade processing and classification
- **Purpose**: Processes raw Solana DEX trades to identify Raydium transactions with appropriate fee rates
- **Logic**: Filters Solana DEX trades for transactions involving Raydium program addresses across five product variants. Validates trade completeness by requiring non-null values for amounts, token mints, vaults, and pool addresses. Joins with fee configuration data to apply appropriate rates based on product type and timing: dynamic rates from blockchain events for CPMM/CLMM products, hardcoded rates for OpenBook (0.25% trade fee, 3% protocol fee) and StableSwap (0.02% trade fee, 0% protocol fee), and null rates for LaunchLab requiring separate tracking. Creates unique transaction identifiers using block slot, transaction ID, and instruction indices.
- **Key fields**: `signer` (trader address), `product_id` (AMM variant), `pool_address`, token amounts and addresses, fee rates, `order_id` for temporal matching

### Component D: Daily active user identification
- **Purpose**: Identifies unique traders per day across all Raydium products
- **Logic**: Extracts distinct signer addresses from processed trades, truncating timestamps to day granularity. Classifies all signers as 'Trader' user type since the metric focuses on trading activity. Groups results by date, chain, user type, and product to create the foundation for MAU calculations.
- **Key fields**: `timestamp` (day-truncated), `user_dau` (unique trader addresses), `product_id`, classification dimensions

### Component E: HyperLogLog sketch creation
- **Purpose**: Converts daily user data into efficient data structures for distinct counting across time windows
- **Logic**: Applies HyperLogLog initialization to daily user data, creating probabilistic sketches that enable efficient distinct counting when aggregating across multiple days. Uses precision parameter of 15 bits for balance between accuracy and storage efficiency. Groups by all relevant dimensions to maintain granular sketch data.
- **Key fields**: `hll` (HyperLogLog sketch), dimensional grouping fields

### Component F: Rolling window generation
- **Purpose**: Creates 30-day lookback periods for each date to define MAU calculation windows
- **Logic**: Generates a complete date spine covering the full data range, then cross-joins with 30-day date arrays to create rolling windows. Each date gets associated with its preceding 29 days plus itself, forming complete 30-day periods. Handles incremental processing by limiting date ranges based on the last modified time with appropriate safety margins.
- **Key fields**: `timestamp` (target date), `joinday` (dates within the 30-day window)

### Component G: Window-based user aggregation
- **Purpose**: Combines daily HyperLogLog sketches across each 30-day window
- **Logic**: Joins the rolling window structure with daily HLL data, matching on the join dates within each window. Merges HyperLogLog sketches using `hll_count.merge_partial()` to combine probabilistic user counts across the 30-day periods. Maintains all dimensional breakdowns while aggregating temporal data.
- **Key fields**: Aggregated `hll` sketches across 30-day windows, preserved dimensional fields

### Component H: Multi-dimensional breakdowns
- **Purpose**: Creates MAU calculations across four different analytical dimensions
- **Logic**: Generates separate result sets for overall protocol MAU (project_dbt_tag dimension), chain-level MAU, user-type MAU, and product-specific MAU. Each breakdown nullifies non-relevant dimensional fields and extracts final counts from merged HLL sketches using `hll_count.extract()`. Combines all breakdowns using union operations to create a comprehensive dimensional view.
- **Key fields**: `user_mau` (extracted distinct count), `dimensions` (breakdown type), relevant dimensional identifiers

### Final aggregation
- **Combining components**: Unions the four dimensional breakdowns (project_dbt_tag, chain, user_type, product_id) into a single result set, with appropriate null values for non-applicable dimensions in each breakdown
- **Currency conversion**: Not applicable as this metric counts users rather than monetary values
- **Time aggregation**: Uses rolling 30-day windows rather than calendar month boundaries, providing a moving average view of user engagement over time
- **Final calculation**: Extracts distinct user counts from merged HyperLogLog sketches, providing probabilistically accurate unique user counts across the defined time windows and dimensional breakdowns. The result shows how many unique traders were active within each 30-day period leading up to each date.

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

Unique revenue-generating users over a rolling 30-day window.

RaydiumRAY

Active users (monthly)

Active users (monthly)

Competitive landscape