# Meteora Launchpad Revenue Methodology

## 1. Overview

Revenue is defined as the portion of fees that Meteora Launchpad retains, as determined by its protocol take rate. The earnings of the project from its token launchpad services are represented by this metric, before cost of revenue, token incentives, and operating expenses are deducted. Revenue is generated from protocol fees accumulated during the dynamic bonding curve (DBC) phase, token migration fees withdrawn upon successful graduation, and ongoing swap fees from graduated pools operating on Meteora's Dynamic AMM (DAMM) V1 and V2 (excluding pool-days flagged for excessive turnover). All collected fees are normalized by decimal precision and converted to USD using end-of-day price feeds.

## 2. Data sources

- **Blockchain events**: `EvtSwap`, `EvtWithdrawMigrationFee`, and `Migration` from the `DBC` program; `Swap` from the `DAMMV1` program; `EvtSwap2` from the `DAMM_v2` program; `InitializeVirtualPoolWithSplToken` and `InitializeVirtualPoolWithToken2022` from the `DBC` program; `InitializePool` from the `DAMM_v1` program; `InitializePool`, `InitializeCustomizablePool`, and `InitializePoolWithDynamicConfig` from the `DAMM_v2` program; `SetPoolFees` and `CreateConfig` from the `DAMM_v1` program; and Solana token balance changes and decentralized exchange trades, covering Solana
- **External data**: End-of-day price feeds and asset metadata

## 3. Step-by-step calculation

### Component A: Dynamic Bonding Curve (DBC) swap fee extraction

- **Purpose**: Protocol fees from active bonding curves are captured.
- **Logic**: `EvtSwap` from the `DBC` program is parsed to identify active bonding curve swaps. The pool, base asset, and quote asset are mapped using `InitializeVirtualPoolWithSplToken` and `InitializeVirtualPoolWithToken2022` from the `DBC` program. The fee asset is determined based on trade direction: if the base asset is sold for the quote asset, the fee is collected in the quote asset; if the quote asset is sold for the base asset, the fee is collected in the base asset. The protocol fee amount is extracted from the protocol fee field.
- **Key fields**: `protocol_fee` representing the protocol fee amount, `trade_direction` representing the trade direction, and `pool` representing the pool account.

### Component B: Token migration fee extraction

- **Purpose**: Fees collected when graduated tokens migrate from bonding curves are captured.
- **Logic**: `EvtWithdrawMigrationFee` from the `DBC` program is parsed to capture fees withdrawn from escrow upon token graduation. The fee asset is mapped to the quote asset of the corresponding pool. If the allocation flag is set to 0, the entire withdrawn fee amount is classified as protocol fee; otherwise, the protocol fee is set to zero.
- **Key fields**: `fee` representing the withdrawn fee amount, `flag` representing the allocation flag, and `pool` representing the pool account.

### Component C: Graduated pool identification and fee extraction

- **Purpose**: Graduated pools are identified and their ongoing protocol swap fees are extracted.
- **Logic**: `Migration` from the `DBC` program is parsed to identify DAMM V1 and DAMM V2 pools that originated from a bonding-curve graduation. For graduated DAMM V1 pools, `Swap` from the `DAMMV1` program is parsed, the fee asset is identified by matching the protocol fee account, and the protocol fee is calculated by multiplying the input amount by the trade fee rate and owner trade fee rate (derived from `SetPoolFees` or fallback `CreateConfig` from the `DAMM_v1` program). For graduated DAMM V2 pools, `EvtSwap2` from the `DAMM_v2` program is parsed, the fee asset is identified based on the collection fee mode and trade direction, and the protocol fee is extracted from the protocol fee field. Pool-days flagged for excessive turnover—where daily native quote-leg volume is greater than 20 times the native quote-leg reserve—are excluded to filter out wash trading.
- **Key fields**: `amount` representing the input amount, `protocol_fee` representing the protocol fee amount, and `protocol_token_fee` representing the fee account.

### Component D: Aggregation and USD conversion

- **Purpose**: Protocol fees are combined, normalized by decimal precision, and converted to USD.
- **Logic**: Protocol fees from active bonding curves, token migrations, and graduated pools (excluding pool-days flagged for excessive turnover) are aggregated daily by asset. Raw amounts are normalized using asset decimal precision from asset metadata. Normalized values are multiplied by end-of-day asset prices to calculate the daily revenue in USD. Daily granularity is maintained with UTC day boundaries.
- **Key fields**: `timestamp` representing the timing, `revenue` representing the aggregated protocol fees, and `price` representing the asset price.

*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.