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 Tradeable pairs Methodology

## 1. Overview

The cumulative number of unique trading pairs available on PancakeSwap is measured by the tradeable pairs metric, calculated for each product across all supported chains. The growth of trading opportunities on the platform is tracked by counting each new pair as it is created and maintaining a running total over time. Both PancakeSwap V2 (using constant product AMM) and V3 (using concentrated liquidity) pairs are captured by the calculation.

## 2. Data sources

- **Blockchain events**: `PairCreated` and `PoolCreated` events from `Factory` contracts, covering Arbitrum, Base, BSC, Ethereum, and 2 other chains
- **External data**: Asset metadata including symbols and decimals

## 3. Step-by-step calculation

### Component A: Pair identification and enrichment

- **Purpose**: The extraction of all trading pair creation events and their enrichment with asset metadata.
- **Logic**: Pair creation events from both PancakeSwap versions across all supported chains are identified. For PancakeSwap V2, `PairCreated` events from `Factory` contracts containing the pair address, and the addresses of both assets are extracted. For PancakeSwap V3, `PoolCreated` events from `Factory` contracts containing the pool address, asset addresses, and fee tier are extracted. Each event is enriched with chain, version, and product information. The pair and pool addresses are utilized as the key identifiers, while asset addresses are used to join with asset metadata to retrieve decimal and symbol fields. Human-readable pair names are constructed using the format 'ASSET0_SYMBOL-ASSET1_SYMBOL'. Fee tiers are normalized by dividing by 1,000,000 to convert from basis points to percentage format.
- **Key fields**: `account_address` (pair/pool contract), `asset0_address`, `asset1_address`, `block_timestamp`, `chain`, `version`, `product_id`, `fee_tier`, `account_name`

### Component B: Daily pair creation tracking

- **Purpose**: The identification of the first appearance of each unique trading pair and the aggregation of new pairs by day.
- **Logic**: For each unique account address on each chain, the minimum block timestamp truncated to day boundaries is identified to determine when each pair first became tradeable. By doing so, each pair is ensured to be counted only once on its creation date, even if the same pair appears in multiple events. The results are then grouped by daily timestamp, product, and chain, and the distinct number of new pairs created on each day for each product and chain is calculated.
- **Key fields**: `timestamp` (daily grain), `product_id`, `chain`, `pair_count` (new pairs per day)

### Component C: Cumulative pair counting

- **Purpose**: The calculation of the running total of tradeable pairs over time for each chain.
- **Logic**: A cumulative sum is applied over the daily new pair counts, partitioned by chain and product, and ordered chronologically by timestamp. A running total is created to represent the total number of tradeable pairs available on each date for each product and chain. Through this process, pairs are ensured to remain counted as tradeable once created, reflecting the persistent nature of trading pair availability.
- **Key fields**: `tradeable_pairs` (cumulative count), `product_id`

### Component D: Final aggregation and standardization

- **Purpose**: The standardization of the final dataset and the application of chain availability filters.
- **Logic**: The intermediate results are passed through a standardization macro to ensure consistent schema formatting, validate chain and protocol identifiers, and apply business logic for handling missing data points. Daily time boundaries are maintained throughout the calculation, with a forward-fill strategy applied to ensure a continuous time series without gaps. No currency conversion is applied as this metric counts pairs rather than monetary values. The final cumulative count of unique tradeable pairs is filtered by chain availability periods to ensure data is only presented when each chain was actually supported by the protocol.
- **Key fields**: `timestamp`, `product_id`, `chain_id`, `tradeable_pairs`

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

Number of unique token pairs available for trading on the exchange.

PancakeSwapCAKE

Tradeable pairs

Tradeable pairs

Competitive landscape

Chain breakdown