# Whirlpools Revenue Methodology

## 1. Overview

The portion of trading fees retained by Whirlpools, as determined by the protocol take rate, is measured by Revenue. The remaining fees are distributed to supply-side participants, specifically liquidity providers. The earnings generated by the protocol from facilitating decentralized asset swaps are represented by this metric, before operating expenses and asset incentives are deducted. Revenue is accumulated across various concentrated liquidity pools and is converted to USD using end-of-day price feeds.

## 2. Data sources

- **Blockchain events**: `InitializePool`, `InitializePoolV2`, and `InitializePoolWithAdaptiveFee` used to establish pool metadata, `InitializeConfig` and `SetDefaultProtocolFeeRate` used to track default protocol fee rates, `InitializeFeeTier`, `SetDefaultFeeRate`, `InitializeAdaptiveFeeTier`, and `SetDefaultBaseFeeRate` used to track default trade fee rates, `SetProtocolFeeRate` and `SetFeeRate` used to track pool-specific fee rates, `Traded` parsed from program logs to capture real-time fee rates, and trade execution data from decentralized exchange trade records, covering Solana
- **External data**: End-of-day price feeds and asset metadata

## 3. Step-by-step calculation

### Component A: Whirlpools pool initialization and metadata tracking

- **Purpose**: The universe of active Whirlpools is established and their associated assets and configurations are mapped.
- **Logic**: Pool metadata is resolved by parsing `InitializePool`, `InitializePoolV2`, and `InitializePoolWithAdaptiveFee` from `Whirlpool` programs. For each pool, the unique pool account, the associated configuration account, the fee tier account, and the mint accounts for both assets (Asset 0 and Asset 1) are extracted. The initialization timestamp is recorded to establish a temporal baseline for fee rate applications.
- **Key fields**: `pool_address`, `config`, `fee_tier`, `token_address_0`, `token_address_1`, `initialized_at`

### Component B: Whirlpools fee rate and protocol share determination

- **Purpose**: The applicable trade fee rate and the protocol's share of those fees are determined for each pool.
- **Logic**: Default trade fee rates are parsed from `InitializeFeeTier`, `SetDefaultFeeRate`, `InitializeAdaptiveFeeTier`, and `SetDefaultBaseFeeRate` from `Whirlpool` programs and are applied based on the pool's initialization timestamp. Default protocol fee shares are parsed from `InitializeConfig` and `SetDefaultProtocolFeeRate` from `Whirlpool` programs and are applied based on the pool's initialization timestamp. Pool-specific overrides are captured from `SetFeeRate` and `SetProtocolFeeRate` from `Whirlpool` programs. For active swaps, these rates are dynamically updated or replaced by parsing `Traded` from the `Whirlpool` program logs, wherein the exact input amount, liquidity provider fee, and protocol fee for each swap are contained, including variable fees on adaptive fee pools. The trade fee rate is calculated as the sum of the liquidity provider fee and the protocol fee divided by the input amount, while the protocol fee share is calculated as the protocol fee divided by the sum of the liquidity provider fee and the protocol fee.
- **Key fields**: `trade_fee_rate`, `protocol_fee_share`, `input_amount`, `lp_fee`, `protocol_fee`

### Component C: Whirlpools trade volume extraction

- **Purpose**: Trade volumes executed through Whirlpools are captured and normalized.
- **Logic**: Raw trade records are filtered for the Whirlpools program account (`whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc`). Raw asset amounts are normalized by dividing the raw values by the decimal precision of each respective asset, which is retrieved from asset metadata. Normalized trade amounts are mapped to the correct asset positions (Asset 0 and Asset 1) based on the pool's initialized metadata.
- **Key fields**: `amount_0`, `amount_1`

### Component D: USD valuation and revenue calculation

- **Purpose**: Trade volumes are valued in USD and the protocol's share of fees is calculated as revenue.
- **Logic**: Normalized trade volumes for both assets are multiplied by their respective end-of-day asset prices. To prevent valuation distortions from unpriced or illiquid assets, the overall trade volume is valued using the conservative lower value of the two trade legs, except when one leg is a tokenized stock asset, in which case the tokenized stock asset leg's valuation is preferred. Daily protocol revenue is then calculated by multiplying the USD-denominated trading volume by the applicable trade fee rate and the protocol fee share. Daily revenue values are aggregated and zero-filled for days with no activity.
- **Key fields**: `trading_volume`, `trade_fee_rate`, `protocol_fee_share`, `revenue`

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

Revenue

Exchanges (DEX)

Users are able to use the Orca protocol to transact with digital assets on a peer-to-peer or peer-to-protocol basis by trading against liquidity  pools, which are created and seeded by other users providing liquidity of a pair of tokens into such liquidity pools in exchange for a stake of the liquidity and trading fees generated by such pools.

Orca is a non-custodial automated market maker (AMM) protocol built on Solana. Orca was founded by Yutaro Mori and Grace Kwan and launched in 2021.

ORCA tokenholders govern the Orca protocol treasury, which receives a portion of the trading fees paid by users of the protocol.