website

twitter

discord

Exchanges (DEX)

Meteora

# Meteora Liquidity turnover Methodology

## 1. Overview

Liquidity turnover is calculated as trading volume relative to total liquidity on the decentralized exchange. The efficiency with which liquidity is utilized to facilitate trades is represented by this metric. The ratio is calculated by dividing daily trading volume by daily total value locked (TVL), with both components converted to USD. Meteora DLMM, Meteora Liquidity Pools, and Meteora Launchpad on Solana are covered by this metric.

## 2. Data sources

- **Blockchain events**: DEX trade instructions from Meteora programs `LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo`, `Eo7WjKq67rjJQSZxS6z3YkapzY3eMj6Xy8X5EQVn5UaB`, `cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG`, and `dbcij3LWUppWqq96dh6gJWwBifmcGfLSB5D4DuSMaqN`, `DBC_Migration` instructions from Meteora programs, and asset balance changes for vault accounts, covering Solana
- **External data**: End-of-day price feeds for Solana assets

## 3. Step-by-step calculation

### Component A: Vault identification and dimension setup

- **Purpose**: Identify all vault accounts that hold liquidity for Meteora pools.
- **Logic**: Vault accounts are extracted from Solana DEX trade instructions where the executing program is identified as Meteora DLMM, Meteora Liquidity Pools, or Meteora Launchpad. For each trade, both the base vault account and quote vault account are captured. Each vault-asset pair is classified by its respective product type based on the program ID. A mapping of vault accounts to their associated assets and protocol types is created.
- **Key fields**: `pool_address`, `account_address`, `token_address`, `product_id`

### Component B: Trading volume calculation

- **Purpose**: Calculate daily trading volume in USD across all Meteora pools.
- **Logic**: Solana DEX trade instructions are filtered to include only those from Meteora programs. For each trade, the base and quote amounts are extracted and normalized by decimal precision. Product types are remapped to Meteora Liquidity Pools or Meteora Launchpad, with graduated pools identified using `DBC_Migration` instructions. To ensure data integrity, wash trading pool-days are identified and excluded. Specifically, constant-product AMM (DAMM V2) pool-days are flagged as inorganic and filtered out if the daily trading volume on both legs is greater than 20 times the respective reserves in native units. USD values are calculated for both legs of the remaining trades using end-of-day price feeds. To maintain a conservative one-sided notional convention, the lesser of the two USD amounts is selected as the trade volume. Volumes are aggregated by day and product type.
- **Key fields**: `block_timestamp`, `signer`, `token_0_address`, `token_1_address`, `amount_0`, `amount_1`, `product_id`

### Component C: Vault balance tracking

- **Purpose**: Track daily asset balances held in Meteora vault accounts.
- **Logic**: Solana asset balance changes are joined with the identified vault accounts. The post-transaction balance is extracted for each vault-asset combination. Forward-filling is applied to handle days without balance changes, ensuring a continuous balance history. Records are deduplicated and filtered to ensure only valid balances are retained for each vault account.
- **Key fields**: `timestamp`, `token_address`, `account_address`, `pool_address`, `token_amount`

### Component D: TVL calculation

- **Purpose**: Calculate total value locked (TVL) in USD across Meteora pools.
- **Logic**: Vault balances are distributed proportionally for vault accounts backing multiple pools to prevent double-counting. Product types are remapped to Meteora Liquidity Pools or Meteora Launchpad, with graduated pools identified using `DBC_Migration` instructions. Asset amounts are aggregated by day, asset, and product type, and then converted to USD using end-of-day price feeds.
- **Key fields**: `timestamp`, `token_address`, `product_id`, `tvl_token`, `tvl`

### Component E: Liquidity turnover calculation

- **Purpose**: Calculate the final liquidity turnover ratio at the project level.
- **Logic**: Daily trading volume is aggregated to the project level and joined with project-level daily TVL using timestamp. Daily trading volume is divided by daily TVL to produce the liquidity turnover ratio. A zero-filling strategy is applied to handle missing data points and ensure a consistent time series.
- **Key fields**: `timestamp`, `trading_volume`, `tvl`, `liquidity_turnover`

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

Trading volume divided by total liquidity.

MeteoraMET

Liquidity turnover

Liquidity turnover

Competitive landscape