Liquidity providers deposit funds into PancakeSwap and receive trading fees from traders (supply-side fees).

PancakeSwap is a non-custodial exchange protocol built on Binance Smart Chain and other blockchains (originally a fork of Uniswap). PancakeSwap was founded by an anonymous team and launched in 2020.

CAKE tokenholders own and govern the protocol. They currently take a cut of the total trading fees paid by traders (revenue).

governance

github

twitter

discord

etherscan

website

Exchanges (DEX)

PancakeSwap

# PancakeSwap Revenue Methodology

## 1. Overview

PancakeSwap revenue is represented by the protocol fees earned from trading activities on the PancakeSwap decentralized exchange. Total daily revenue in USD is calculated from both V2 and V3 versions of the protocol. For V2 pools, revenue is calculated by applying a fixed 0.08% fee to trading volumes, while actual protocol fees paid during swaps are captured for V3 pools. The business question of how much daily revenue is generated from trading fees across all supported chains and protocol versions is answered by this metric.

## 2. Data sources

- **Blockchain events**: `Swap` events from `Pair` and `Pool` contracts, `PairCreated` and `PoolCreated` events from `Factory` contracts, and transaction records, covering Arbitrum, Base, BSC, Ethereum, and 2 other chains
- **External data**: End-of-day price feeds for assets, asset metadata including decimal precision and symbols, and a hardcoded denylist of trading pairs with insufficient price feed coverage

## 3. Step-by-step calculation

### Component A: Trading pair registry

- **Purpose**: A comprehensive registry of all valid PancakeSwap trading pairs and pools across supported chains is created.
- **Logic**: Factory creation events from both V2 and V3 protocols are processed to extract pair addresses, asset compositions, and fee tiers. These are joined with asset metadata to obtain decimal places and symbols needed for amount normalization. Trading pair names are constructed by concatenating asset symbols. For V2 pairs, a standard 0.25% fee tier is assigned, while variable fee tiers specified during creation are used for V3 pools.
- **Key fields**: `account_address`, `token0_address`, `token1_address`, `token0_decimals`, `token1_decimals`, `fee_tier`, `account_name`, `version`, `chain`

### Component B: Raw trade extraction

- **Purpose**: Swap events from both PancakeSwap V2 and V3 protocols are extracted and standardized.
- **Logic**: Swap events are processed differently based on the protocol version. For V2 swaps, asset amount changes are calculated by subtracting output amounts from input amounts, and revenue fields are set to zero to be calculated in a later step. For V3 swaps, direct asset amounts and protocol fee amounts are captured from the event data. Trades from denylisted pairs are excluded to maintain data quality. Transaction records are joined to identify the actual user addresses initiating trades.
- **Key fields**: `block_timestamp`, `account_address`, `token0_amount`, `token1_amount`, `token0_revenue`, `token1_revenue`, `user_address`, `version`, `chain`

### Component C: Volume and revenue calculation

- **Purpose**: Raw asset amounts are converted to USD values, and trading volumes are calculated with anti-manipulation measures.
- **Logic**: Trades are aggregated by day, and decimal corrections are applied using asset metadata from the trading pair registry. End-of-day price feeds for both assets in each pair are joined to convert amounts to USD. Anti-manipulation logic is implemented by taking the minimum USD value between the two assets in each trade, ensuring that price discrepancies do not inflate volume figures. For V3 trades, protocol fee amounts are converted to USD using the same price feeds. Missing price data is handled by defaulting to zero values.
- **Key fields**: `trading_volume`, `revenue`, `timestamp`, `version`, `chain`, `market_sector_id`, `business_segment_id`

### Component D: Final aggregation and protocol fee application

- **Purpose**: Calculated volumes and revenues are aggregated, and protocol fees are applied to produce the final daily revenue metric.
- **Logic**: Calculated volumes and revenues are processed with different logic based on the protocol version. For V2 trades, the trading volume is multiplied by the fixed 0.08% protocol fee rate to calculate revenue. For V3 trades, the direct revenue amounts already calculated from protocol fees are used. All data is aggregated to daily boundaries using timestamp truncation. The final revenue components are summed by day, chain, and business classification. Chain availability filtering is applied to ensure data completeness, and the final metric standardization and zero-filling processes are executed.
- **Key fields**: `timestamp`, `chain_id`, `market_sector_id`, `business_segment_id`, `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.

PancakeSwapCAKE

Revenue

Revenue

Competitive landscape

Chain breakdown