# Meteora Launchpad Trading volume Methodology

## 1. Overview

Trading volume is defined as the total value of trades executed on Meteora Launchpad. Since trading fees are paid by users on these trades, a strong correlation is exhibited between this metric and the project's ability to generate fees and revenue. For Meteora Launchpad, trading volume is captured from both the initial dynamic bonding curve phase and the subsequent graduated liquidity pools. Through this volume tracking, the overall market demand and liquidity depth for newly launched assets can be evaluated.

## 2. Data sources

- **Blockchain events**: `Migration` instructions from `DBC` programs, decentralized exchange trade instructions from Meteora programs, and asset balance changes from Solana accounts, covering Solana
- **External data**: End-of-day price feeds and asset metadata

## 3. Step-by-step calculation

### Component A: Trade instruction parsing and normalization

- **Purpose**: Extract raw trade data and normalize asset amounts
- **Logic**: Trade instructions executed through Meteora programs are parsed from Solana decentralized exchange trade records. The asset amounts are extracted and normalized by their respective decimal precisions using asset metadata.
- **Key fields**: `amount_0`, `amount_1`, `token_0_address`, `token_1_address`

### Component B: Product attribution and pool origin mapping

- **Purpose**: Attribute trades specifically to Meteora Launchpad
- **Logic**: Trades are mapped to Meteora Launchpad if they occur directly on the Dynamic Bonding Curve (DBC) program. Additionally, `Migration` instructions from the `DBC` program are parsed to identify graduated pools. Trades occurring on Meteora V1 or V2 liquidity pools that originated from these graduated bonding curves are also attributed to Meteora Launchpad, while other pool trades are routed to Meteora Liquidity Pools.
- **Key fields**: `pool_address`, `product_id`, `instruction_type`

### Component C: Wash trading filtration

- **Purpose**: Filter out inorganic trading activity from constant-product pools
- **Logic**: Daily trading volume is compared against reserves for both asset legs of DAMM V2 (constant-product AMM) pools. Pool-days where the turnover ratio (daily native volume divided by native reserve) on both legs exceeds a threshold of 20 are flagged as wash trading. These flagged pool-days are excluded from the trade dataset prior to USD valuation.
- **Key fields**: `pool_address`, `timestamp`, `vol_0_native`, `vol_1_native`, `reserve_native`

### Component D: USD valuation and conservative volume calculation

- **Purpose**: Calculate the USD value of trades using a conservative one-sided notional method
- **Logic**: Normalized asset amounts are multiplied by their respective end-of-day USD prices. To prevent distortion from price manipulation or extreme volatility, the trading volume for each trade is calculated as the lesser of the two USD-valued legs.
- **Key fields**: `amount_0`, `amount_1`, `price_usd`

### Component E: Aggregation and finalization

- **Purpose**: Aggregate trading volume and apply final data quality filters
- **Logic**: The conservative USD trading volumes are aggregated by day, chain, and product. Missing days are filled with zeros to ensure a continuous time series, and chain availability filters are applied to align with data freshness standards.
- **Key fields**: `timestamp`, `chain_id`, `product_id`, `trading_volume`

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

Total value of spot trades executed on the exchange.

Trading volume