website

twitter

discord

Exchanges (DEX)

Meteora

# Meteora Revenue Methodology

## 1. Overview

Revenue measures the portion of fees retained by the Meteora protocol across its various liquidity products. The protocol's take rate from trading and asset migration activity on Meteora DLMM, Meteora Launchpad, and Meteora Liquidity Pools is represented by this metric. These earnings are captured before any distributions to supply-side participants or external partners.

## 2. Data sources

- **Blockchain events**: `Swap` events from `DLMM` programs, `EvtSwap` and `EvtWithdrawMigrationFee` events from `DBC` programs, `EvtSwap2` events from `DAMM_v2` programs, `Swap` instructions from `DAMMV1` programs, `Migration` instructions from `DBC` programs, DEX trades, and Solana account balances, covering Solana
- **External data**: End-of-day price feeds and asset metadata

## 3. Step-by-step calculation

### Component A: Meteora DLMM revenue extraction

- **Purpose**: Capture protocol fees from Meteora DLMM pools
- **Logic**: `Swap` events from `DLMM` programs are parsed to extract the protocol fee amount. The fee asset is identified as either asset X or asset Y based on the pool's fee collection mode and swap direction.
- **Key fields**: `protocol_fee`, `swap_for_y`, `lb_pair` (pool account)

### Component B: Meteora Launchpad revenue extraction

- **Purpose**: Capture protocol fees from Meteora Launchpad pools and asset migrations
- **Logic**: `EvtSwap` events from `DBC` programs are parsed to identify the protocol's share of the swap fee. `EvtWithdrawMigrationFee` events from `DBC` programs are parsed to extract withdrawn migration fees where the partner/protocol allocation flag is met. Additionally, DAMM V1 and DAMM V2 pools that originated from a DBC bonding-curve graduation (identified via `Migration` instructions from `DBC` programs) are mapped to this product, with their respective protocol fees extracted.
- **Key fields**: `swap_result_protocol_fee`, `fee` (withdrawn migration fee), `flag`, `pool` (pool account)

### Component C: Meteora Liquidity Pools revenue extraction

- **Purpose**: Capture protocol fees from standard Meteora Liquidity Pools
- **Logic**: For DAMM V2, `EvtSwap2` events from `DAMM_v2` programs are parsed to extract the protocol fee. For DAMM V1, because `Swap` instructions from `DAMMV1` programs do not emit explicit fee fields, protocol fees are derived by applying the pool's fee schedule (from `SetPoolFees` instructions or config fallbacks) to the input amount. Pools that did not originate from a DBC graduation are mapped to this product.
- **Key fields**: `swap_result_protocol_fee`, `amount`, `protocol_token_fee`, `trade_fee_numerator`, `trade_fee_denominator`, `owner_trade_fee_numerator`, `owner_trade_fee_denominator`

### Component D: USD conversion and aggregation

- **Purpose**: Normalize revenue values to USD for cross-asset comparison
- **Logic**: All captured protocol fee amounts are filtered to exclude wash trading activity from DAMM V2 pools, where pool-days with daily volume exceeding 20 times their reserve are dropped. The remaining protocol fee amounts are normalized by decimal precision. These values are multiplied by end-of-day asset prices to determine the USD value. Daily totals are aggregated by product and chain using UTC day boundaries. Amounts are zero-filled for days where no activity is detected.

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

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

MeteoraMET

Revenue

Revenue

Competitive landscape