Liquidity providers deposit funds into GMX and receive trading fees from traders (supply-side fees).

GMX is a non-custodial exchange for spot and perpetual contracts, live on Arbitrum, Avalanche, MegaETH and Solana. GMX was founded by an anonymous team and launched in 2021.

GMX token holders own and govern the protocol. On the EVM deployments they take a cut of the total trading fees paid by traders (revenue), split between GMX buybacks and the treasury. On Solana the protocol's share accrues to that deployment's treasury rather than to GMX token holders.

governance

github

twitter

discord

etherscan

website

Derivative exchanges

# GMX Notional trading volume Methodology

## 1. Overview

Notional trading volume is measured as the total value of derivative contracts and spot trades executed across GMX V1, GMX V2, and GMX Solana. This metric is utilized as a primary indicator of protocol activity and liquidity, directly correlating with the protocol's ability to generate fees and revenue. Perpetual contract trade sizes, spot swaps, and liquidity pool mint/burn actions are aggregated to determine the total volume. All values are normalized to USD to enable standardized comparison across different chains and assets.

## 2. Data sources

- **Blockchain events**: `IncreasePosition`, `DecreasePosition`, `LiquidatePosition`, `Swap`, `BuyUSDG`, and `SellUSDG` events from `Vault` contracts; `EventLog1` and `EventLog2` events from `EventEmitter` contracts; and `TradeEvent` instructions from the `GMSol` program, covering Arbitrum, Avalanche, MegaETH, and Solana
- **External data**: End-of-day price feeds and asset metadata

## 3. Step-by-step calculation

### Component A: GMX V1 perpetual trading volume

- **Purpose**: Calculates the notional volume of perpetual contract trades on GMX V1.
- **Logic**: `IncreasePosition`, `DecreasePosition`, and `LiquidatePosition` events are parsed from `Vault` contracts. For position increases and decreases, the change in position size is extracted from the `sizeDelta` field. For liquidations, the liquidated position size is extracted from the `size` field. These values, which are natively denominated in USD with 30 decimals, are normalized by decimal precision to determine the final USD volume.
- **Key fields**: `sizeDelta`, `size`, `token_address`

### Component B: GMX V1 spot and liquidity pool volume

- **Purpose**: Calculates the volume of spot swaps and liquidity pool mints/burns on GMX V1.
- **Logic**: Spot swaps are captured by parsing `Swap` events from `Vault` contracts, where the input asset amount is extracted from the `amountIn` field. Liquidity pool mints and burns are captured by parsing `BuyUSDG` and `SellUSDG` events from `Vault` contracts, extracting the asset amount from the `tokenAmount` field. These asset amounts are normalized by decimal precision and multiplied by end-of-day asset prices to calculate the USD volume.
- **Key fields**: `amountIn`, `tokenAmount`, `token_address`

### Component C: GMX V2 perpetual trading volume

- **Purpose**: Calculates the notional volume of perpetual contract trades on GMX V2.
- **Logic**: `EventLog1` events representing position increases and decreases are parsed from `EventEmitter` contracts. The change in position size is extracted from the `sizeDeltaUsd` field within the event's integer items and normalized by decimal precision. To attribute the volume to the correct originating chain, the trade's `orderKey` is matched with the corresponding `OrderCreated` event from `EventEmitter` contracts, falling back to the execution chain if no matching creation event is found.
- **Key fields**: `sizeDeltaUsd`, `orderKey`, `token_address`

### Component D: GMX V2 spot trading volume

- **Purpose**: Calculates the volume of spot swaps on GMX V2.
- **Logic**: Swap fee events are parsed from `EventEmitter` contracts. The total swap amount is calculated by summing the receiver fee, pool fee, and remaining swap amount fields. This sum is normalized by decimal precision and multiplied by the token price extracted from the event's integer items. Originating chain attribution is resolved by matching the swap's trade key with corresponding order, deposit, or withdrawal creation events.
- **Key fields**: `receiver_fee_amount`, `pool_fee_amount`, `remaining_amount`, `token_price`, `tradeKey`

### Component E: GMX Solana trading volume

- **Purpose**: Calculates the trading volume on GMX Solana.
- **Logic**: `TradeEvent` instructions are parsed from the `GMSol` program. The trading volume is calculated by taking the absolute difference between the position size after the trade and the position size before the trade. Since these values are natively stored in USD with 20 decimals, the resulting difference is normalized by decimal precision to obtain the final USD volume.
- **Key fields**: `size_before_usd`, `size_after_usd`

### Component F: USD normalization and aggregation

- **Purpose**: Combines all volume components into a unified daily metric.
- **Logic**: The calculated USD volumes from GMX V1, GMX V2, and GMX Solana are aggregated. Daily totals are grouped by timestamp, chain, and product. Missing days are filled with zeros to ensure a continuous time series.
- **Key fields**: `timestamp`, `chain_id`, `notional_trading_volume`

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

Total USD value of derivative contracts executed on the protocol.

GMXGMX

Notional trading volume

Notional trading volume

Competitive landscape

Chain breakdown