# PumpSwap Trading volume Methodology

## 1. Overview

Trading volume is defined as the total value of trades executed on the PumpSwap decentralized spot exchange. Since trading fees are paid by users on their trades, a correlation is observed between this metric and the ability of PumpSwap to generate fees and revenue. The volume of graduated assets trading on the PumpSwap automated market maker (AMM) platform is specifically tracked, while bonding-curve transactions from the primary pump.fun platform are excluded. Through the measurement of these secondary market trades, the overall liquidity and trading activity of assets post-graduation is assessed.

## 2. Data sources

- **Blockchain events**: `CreatePoolEvent`, `BuyEvent`, and `SellEvent` from `AMM` programs, covering Solana
- **External data**: End-of-day price feeds for native assets and asset metadata

## 3. Step-by-step calculation

### Component A: Pool identification and metadata mapping

- **Purpose**: The identification of active PumpSwap liquidity pools and retrieval of asset decimal configurations.
- **Logic**: `CreatePoolEvent` from `AMM` programs are parsed to identify unique pool addresses, base asset addresses, quote asset addresses, and their respective decimal precisions. This pool registry is maintained incrementally to enable the mapping of subsequent trade instructions to their correct asset metadata.
- **Key fields**: `pool_address`, `base_mint_address`, `quote_mint_address`, `base_decimals`, `quote_decimals`

### Component B: Trade extraction and normalization

- **Purpose**: The extraction of swap details and normalization of trade amounts.
- **Logic**: `BuyEvent` and `SellEvent` from `AMM` programs are parsed to capture swap transactions. For Buy instructions, the quote asset input amount (including liquidity provider fees) and base asset output amount are extracted. For Sell instructions, the base asset input amount and quote asset output amount (excluding liquidity provider fees) are extracted. These raw amounts are normalized by dividing by the asset's decimal precision retrieved from the pool registry.
- **Key fields**: `transaction_id`, `block_timestamp`, `base_amount`, `quote_amount`, `instruction_type`

### Component C: SOL volume filtering

- **Purpose**: The isolation of native SOL volume to prevent price distortions from low-liquidity assets.
- **Logic**: Trading volume is filtered to aggregate only the native SOL (Wrapped SOL) leg of each swap. For Buy instructions, the input asset (base mint address in the normalized trade record) is verified to match the native SOL address. For Sell instructions, the output asset (quote mint address in the normalized trade record) is verified to match the native SOL address. This restriction is applied to ensure that trading volume is denominated in SOL, thereby avoiding double-counting and eliminating nominal volume spikes from illiquid assets.
- **Key fields**: `base_mint_address`, `quote_mint_address`, `base_amount`, `quote_amount`

### Component D: USD conversion and aggregation

- **Purpose**: The conversion of SOL trading volume to USD and aggregation to daily granularity.
- **Logic**: The daily sum of SOL trading volume is multiplied by the end-of-day USD price of SOL. The final values are aggregated by day using UTC boundaries, and any days with missing activity are zero-filled to ensure a continuous time series.
- **Key fields**: `timestamp`, `trading_volume`, `price_usd`

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

Total value of spot trades executed on the exchange.