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

Sushiswap is a non-custodial exchange protocol built on Ethereum (originally a fork of Uniswap). Sushiswap was founded by a pseudonym Chef Nomi and launched in 2020.

SUSHI 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)

SushiSwap

# SushiSwap Tradeable pairs Methodology

## 1. Overview

Tradeable pairs measures the cumulative number of unique trading pairs available on the SushiSwap decentralized exchange across all supported blockchain networks. The growth of trading options available to users is tracked by counting distinct liquidity pools that have been created over time. Factory contract events emitted when new trading pairs are deployed are monitored, maintaining a running total of the expanding universe of tradeable asset pairs on the platform.

## 2. Data sources

- **Blockchain events**: `PairCreated` events from SushiSwap V2 factory contracts and `PoolCreated` events from SushiSwap V3 factory contracts, covering Ethereum, Arbitrum, Avalanche, Base, and 6 other chains
- **External data**: Asset metadata including symbols and decimal precision

## 3. Step-by-step calculation

### Component A: Trading pair identification

- **Purpose**: Extract all trading pairs that have been created on SushiSwap across multiple blockchain networks and protocol versions
- **Logic**: Factory contract events are monitored across SushiSwap V2 and V3 deployments on multiple chains. For V2 protocols, `PairCreated` events containing the new pair contract address and the two asset addresses being paired are captured. For V3 protocols, `PoolCreated` events containing the pool address, asset addresses, and fee tier information are captured. Each event is processed to extract the block timestamp when the pair was created, the pair/pool contract address, the addresses of both assets in the pair, and the blockchain network. Fee tiers are normalized by decimal precision.
- **Key fields**: `block_timestamp` for when the pair was created, `account_address` for the pair/pool contract address, `token0_address` and `token1_address` for the constituent assets, `chain` for the blockchain network, `version` for V2 vs V3 protocol distinction, and `fee_tier` for V3 pool fee structure

### Component B: Asset metadata enrichment

- **Purpose**: Add readable asset information to make pairs identifiable and handle decimal precision correctly
- **Logic**: Extracted pair data is joined with asset metadata using asset contract addresses and chain information as matching keys. Asset symbols and decimal precision information are added for both assets in each pair through this enrichment. Readable pair names are created by concatenating the symbols of both assets with a hyphen separator. Missing asset information is handled gracefully to avoid excluding valid pairs.
- **Key fields**: `token0_decimals` and `token1_decimals` for handling asset precision, `account_name` as the formatted pair name combining both asset symbols

### Component C: Daily pair aggregation

- **Purpose**: Determine when each unique trading pair first became available and count new pairs by day
- **Logic**: The first appearance date for each trading pair is identified by finding the minimum block timestamp for each unique pair contract address per chain. Timestamps are truncated to daily granularity to establish clear daily boundaries. The data is then grouped by day and chain to count the number of distinct new pairs made tradeable each day. A time series showing the daily rate of new pair creation across each blockchain network is created.
- **Key fields**: `timestamp` as the daily date boundary, `pair_count` representing new pairs that became available each day

### Component D: Cumulative pair calculation

- **Purpose**: Calculate the running total of tradeable pairs over time
- **Logic**: Daily new pair counts are processed using a cumulative sum calculation to determine the total number of tradeable pairs available on any given date. Daily boundaries are established using timestamp truncation to the day level, ensuring consistent daily aggregation across all chains. A running cumulative sum is computed, partitioned by blockchain chain and ordered chronologically by timestamp, to produce the total count of unique tradeable pairs available on each date for each supported blockchain network.
- **Key fields**: `tradeable_pairs` representing the cumulative count of unique tradeable pairs

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

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

SushiSwapSUSHI

Tradeable pairs

Tradeable pairs

Competitive landscape

Chain breakdown