website

twitter

discord

Exchanges (DEX)

Meteora

# Meteora Average trading volume (per user) Methodology

## 1. Overview

Average trading volume (per user) is measured as the mean USD trading volume per unique active user (daily) on the Meteora protocol. Insight into user engagement intensity is provided by dividing the total daily trading volume by the number of unique trading users identified each day. Multiple products are operated, including Meteora DLMM, Meteora Launchpad, and Meteora Liquidity Pools, all of which are included in the overall trading volume calculation.

## 2. Data sources

- **Blockchain events**: DEX trade instructions from the Meteora DLMM (`LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo`), Meteora DAMM V1 (`Eo7WjKq67rjJQSZxS6z3YkapzY3eMj6Xy8X5EQVn5UaB`), Meteora DAMM V2 (`cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG`), and Meteora DBC (`dbcij3LWUppWqq96dh6gJWwBifmcGfLSB5D4DuSMaqN`) programs, `Migration` from `DBC` programs, and asset balance changes, covering Solana
- **External data**: End-of-day price feeds for assets

## 3. Step-by-step calculation

### Component A: Meteora Launchpad and Meteora Liquidity Pools trade extraction

- **Purpose**: Extract and classify trades from Meteora products
- **Logic**: Meteora trades are identified by filtering for instructions where a match is found between the executing account or outer executing account and specific program accounts. Trades are initially classified based on the program account. To align with the business product axis, trades are remapped using pool origin data: pools identified as originating from a bonding-curve graduation via `Migration` from `DBC` programs are classified as Meteora Launchpad, while other DAMM trades are classified as Meteora Liquidity Pools. To ensure data consistency and eliminate wash trading, inorganic pool-days are identified and filtered out. For Meteora DAMM V2 pools, daily trading volume for both assets in the pool is compared against their respective reserves. Pool-days where the turnover ratio for both assets exceeds 20 are flagged as inorganic and excluded from the trade dataset. Trade quantities are normalized by decimal precision. The signer (user account), pool account, asset addresses, trade quantities, and block timestamp are captured for each trade record.
- **Key fields**: `signer` for user identification, `pool_address` for pool identification, `token_0_address` and `token_1_address` for asset identification, `amount_0` and `amount_1` for trade sizes, `product_id` for product classification

### Component B: Price data aggregation

- **Purpose**: Provide daily USD prices for asset conversion
- **Logic**: Asset price data is aggregated from hourly feeds to create daily averages. Data is filtered for the Solana chain and grouped by day, with the average USD price calculated for each asset. A lookup table keyed by date and asset address is created.
- **Key fields**: `timestamp` (day-truncated), `token_address`, `price_usd` (daily average)

### Component C: USD volume calculation

- **Purpose**: Convert trade amounts to USD and calculate trading volume
- **Logic**: Daily aggregated trade amounts for each pool are joined with price data for both assets in the pair, matching on the trade date and asset addresses. USD values are calculated for both sides of the pool's daily volume by multiplying asset amounts by their respective USD prices. To prevent double-counting, the lesser of the two USD amounts is used. This conservative approach is applied to ensure accurate volume measurement even when variations are present in price data quality between assets.
- **Key fields**: `volume_0` and `volume_1` (USD values for each trade leg), `timestamp`, `product_id`

### Component D: Daily volume aggregation

- **Purpose**: Sum USD trading volume by day and product
- **Logic**: Daily pool volumes in USD are aggregated by summing all trading volume within each day, grouped by chain and product. Daily trading volume totals are created for each of Meteora's products.
- **Key fields**: `timestamp` (day-truncated), `trading_volume` (daily sum), `product_id`

### Component E: Active users (daily) calculation

- **Purpose**: Count unique users who traded each day
- **Logic**: Unique active users (daily) are identified by extracting distinct `signer` accounts for each day from the trade data. Users are classified as 'Trader' type and counted using a distinct counting algorithm. Multiple dimensional breakdowns are created, but the project-level aggregate is utilized for the final metric.
- **Key fields**: `user_dau` (distinct user count), `timestamp`, `dimensions` (aggregation level), `user_type`

### Component F: Final aggregation and average calculation

- **Purpose**: Combine volume and user data to calculate the final metric
- **Logic**: Trading volume data is joined with active users (daily) data on the timestamp field, specifically using the project-level aggregate. Trading volume is summed across all products while the maximum active users (daily) value is taken. All volume calculations are performed in USD using end-of-day asset prices, with amounts converted at the daily pool level before final aggregation. All data is aggregated to daily boundaries using day-truncated timestamps. Total daily trading volume is divided by the active users (daily) count using safe division to handle edge cases where no trades were executed by users on a given day.

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

Average trading volume (per user)

Trading volume divided by daily active users.

MeteoraMET

Average trading volume (per user)

Average trading volume (per user)

Competitive landscape