website

twitter

discord

Exchanges (DEX)

Meteora

# Meteora User Mau Methodology

## 1. Overview

Active users (monthly) measures the number of unique addresses that make a revenue-generating transaction with a project, i.e. An application or a blockchain. Active users (monthly) are measured over a 30-day rolling window. User engagement and trading activity are tracked across Meteora's products: Meteora DLMM, Meteora Launchpad, and Meteora Liquidity Pools. Distinct trader accounts are identified per 30-day rolling window, providing insight into the protocol's monthly user base and trading adoption.

## 2. Data sources

- **Blockchain events**: Parsed trade instructions from the `LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo`, `Eo7WjKq67rjJQSZxS6z3YkapzY3eMj6Xy8X5EQVn5UaB`, `cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG`, and `dbcij3LWUppWqq96dh6gJWwBifmcGfLSB5D4DuSMaqN` programs, `Migration` from `DBC` programs, and token balance changes for pool vaults, covering Solana

## 3. Step-by-step calculation

### Component A: Meteora trade identification

- **Purpose**: Identify all trading transactions that occurred on Meteora's programs
- **Logic**: Solana DEX trade instructions are filtered to include only transactions that interacted with Meteora's specific program accounts. Four program IDs are included: `LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo` (Liquidity Book), `Eo7WjKq67rjJQSZxS6z3YkapzY3eMj6Xy8X5EQVn5UaB` (Dynamic AMM V1), `cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG` (Dynamic AMM V2), and `dbcij3LWUppWqq96dh6gJWwBifmcGfLSB5D4DuSMaqN` (Dynamic Bonding Curve). Both outer program and inner program fields are checked to capture all relevant interactions
- **Key fields**: `signer` (wallet account executing the trade), `base_mint` and `quote_mint` (asset accounts being traded), `base_amount` and `quote_amount` (trade quantities), `block_timestamp` (transaction time), and program identifiers for product classification

### Component B: Product categorization and data standardization

- **Purpose**: Classify trades by Meteora product type and standardize the data format
- **Logic**: Trades are categorized into Meteora DLMM, Meteora Launchpad, and Meteora Liquidity Pools. Trades executing on the Dynamic AMM V1 (`Eo7WjKq67rjJQSZxS6z3YkapzY3eMj6Xy8X5EQVn5UaB`) and Dynamic AMM V2 (`cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG`) programs are matched against pool migration records from `Migration` in `DBC` programs. If a pool is identified as originating from a bonding-curve graduation, its trades are classified under Meteora Launchpad; otherwise, they are classified under Meteora Liquidity Pools. Trades executing on the Dynamic Bonding Curve program (`dbcij3LWUppWqq96dh6gJWwBifmcGfLSB5D4DuSMaqN`) are also classified under Meteora Launchpad. Trades executing on the Liquidity Book program (`LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo`) are classified under Meteora DLMM. Trade amounts are normalized by decimal precision and converted to absolute values. Additionally, pool-days for Dynamic AMM V2 are filtered to exclude wash trading by removing trades from any pool-day where a turnover threshold of 20 (calculated as daily native quote-leg volume divided by native quote-leg reserve) is exceeded. The chain is standardized as 'solana' for all records.
- **Key fields**: A `product_id` field is created for product classification, `amount_0` and `amount_1` fields are normalized as absolute values, and a standardized `chain` identifier is added

### Component C: Monthly user aggregation

- **Purpose**: Count distinct active users per 30-day window across all Meteora programs
- **Logic**: Block timestamps are truncated to daily boundaries using day-level granularity. For each 30-day window, all unique `signer` accounts that executed trades are identified, ensuring that users who made multiple trades on the same 30-day window are counted only once. All users are classified as 'Trader' type since this metric specifically tracks trading activity
- **Key fields**: A `timestamp` field is created and truncated to the day level, `user_type` is standardized as 'Trader', and `user_mau` is populated with the unique `signer` account

### Component D: Final aggregation

- **Logic**: Processed trade data is passed directly into the monthly user count calculation, as all necessary information is contained within the trade records. Monthly boundaries are determined by truncating blockchain timestamps to the day level, ensuring consistent 30-day rolling windows. The final count is calculated as the number of distinct wallet accounts (`signer` field) that executed at least one trade on any Meteora program within each 30-day rolling window. No additional mathematical operations are applied, as the metric is calculated by counting unique accounts per 30-day window.

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

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

MeteoraMET

Active users (monthly)

Active users (monthly)

Competitive landscape