website

twitter

discord

Exchanges (DEX)

Meteora

# Meteora Afpu Methodology

## 1. Overview

Average fees per user (AFPU) is measured as the fees paid per active user over a fixed 24-hour window. The average daily cost incurred by an individual user for utilizing the protocol's liquidity services is reflected by this metric. This metric is calculated across the Meteora DLMM, Meteora Launchpad, and Meteora Liquidity Pools products. A key indicator of user-level monetization and protocol efficiency is provided by AFPU, where total fee generation is normalized against the active users (daily) base.

## 2. Data sources

- **Fees**: Derived from the Fees metric
- **Active users (daily)**: Derived from the Active users (daily) metric

## 3. Step-by-step calculation

### Component A: Meteora DLMM, Launchpad, and Liquidity Pools fee extraction

- **Purpose**: Fee accruals from Meteora liquidity products are captured.
- **Logic**: `Swap` from `DLMM` programs, `EvtSwap` and `EvtWithdrawMigrationFee` from `DBC` programs, and `EvtSwap2` from `DAMM_v2` programs are parsed on Solana. For Meteora DLMM, fees are extracted in the input asset. For Meteora Launchpad (via DBC), fees are extracted in the output asset and are comprised of trading, protocol, and referral components, while token-migration fees are captured from migration withdrawals. For DAMM V2 pools (attributed to Meteora Liquidity Pools or Meteora Launchpad), the fee asset is determined by the pool's collection mode, and the total fee is calculated as the sum of claiming, protocol, compounding, and referral components. Inorganic pool-days for DAMM V2 pools, where daily native quote-leg volume is greater than 20 times the quote-leg reserve, are filtered out to maintain consistency with filtered volume.
- **Key fields**: `fee`, `protocol_fee`, `trading_fee`, `referral_fee`, `claiming_fee`, `compounding_fee`, `fee_amount`.

### Component B: Meteora Liquidity Pools and Launchpad legacy fee derivation

- **Purpose**: Fees for legacy pools where explicit fee fields are not emitted are calculated.
- **Logic**: `Swap` is parsed from the `DAMM_v1` program. Since explicit fee fields are not contained within these instructions, fees are derived by applying the fee schedule (numerator and denominator) from `SetPoolFees` or `CreateConfig` to the input amount. The specific fee asset is identified by matching the protocol fee account against the pool's configuration.
- **Key fields**: `amount`, `trade_fee_numerator`, `trade_fee_denominator`, `protocol_token_fee`.

### Component C: Active user identification

- **Purpose**: Unique daily traders across all Meteora products are identified.
- **Logic**: Unique transaction signer accounts are identified from trade records across the Meteora DLMM, Meteora Launchpad, and Meteora Liquidity Pools programs. Only successful trades are included in the count to ensure only successful interactions with the protocol's liquidity are reflected. Inorganic pool-days for DAMM V2 pools, where daily native quote-leg volume is greater than 20 times the quote-leg reserve, are filtered out to ensure consistency across trade-derived metrics.
- **Key fields**: `signer`, `executing_account`, `outer_executing_account`.

### Component D: USD conversion and AFPU calculation

- **Purpose**: Values are normalized to USD and the final average per user is calculated.
- **Logic**: Fee amounts are normalized by decimal precision and multiplied by end-of-day price feeds. Total daily fees are aggregated across all products and divided by the count of unique active users (daily). Daily granularity is maintained using UTC day boundaries.
- **Key fields**: `timestamp`, `fees`, `user_dau`, `price_usd`.

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

MeteoraMET

Average fees per user (AFPU)

Average fees per user (AFPU)

Competitive landscape