website

twitter

discord

Exchanges (DEX)

Meteora

# Meteora User Wau Methodology

## 1. Overview

Active users (weekly) measures the number of unique addresses that make a revenue-generating transaction with a project, i.e. An application or a blockchain. Active users (weekly) are measured over a 7-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 7-day window, providing insight into the protocol's weekly 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-7-day windows for Dynamic AMM V2 are filtered to exclude wash trading by removing trades from any pool-7-day window where a turnover threshold of 20 (calculated as weekly 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: Weekly user aggregation

- **Purpose**: Count distinct active users per 7-day window across all Meteora programs
- **Logic**: Block timestamps are truncated to weekly boundaries using week-level granularity. For each 7-day window, all unique `signer` accounts that executed trades are identified, ensuring that users who made multiple trades within the same 7-day window are counted only once per 7-day window. 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 week level, `user_type` is standardized as 'Trader', and `user_wau` is populated with the unique `signer` account

### Component D: Final aggregation

- **Logic**: Processed trade data is passed directly into the weekly user count calculation, as all necessary information is contained within the trade records. Weekly boundaries are determined by truncating blockchain timestamps to the week level, ensuring consistent 7-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 7-day window. No additional mathematical operations are applied, as the metric is calculated by counting unique accounts per 7-day window.

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

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

MeteoraMET

Active users (weekly)

Active users (weekly)

Competitive landscape