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 assets Methodology

## 1. Overview

Tradeable assets measures the cumulative number of unique assets that have appeared in SushiSwap trading pairs over time. This metric reflects the breadth of the project's asset coverage and tracks the growth of asset diversity on the platform. Unique asset addresses are identified from all trading pairs created since the launch of SushiSwap, and a running cumulative count is maintained that increases as new assets are introduced to the platform.

## 2. Data sources

- **Blockchain events**: `PairCreated` and `PoolCreated` events from `Factory` contracts, covering Ethereum, Arbitrum, Base, Polygon, and 6 other chains
- **External data**: Asset metadata including symbols and decimal precision

## 3. Step-by-step calculation

### Component A: Trading pairs extraction

- **Purpose**: Trading pairs created on SushiSwap V2 and V3 are extracted across supported chains.
- **Logic**: Parsed factory contract events where new trading pairs are created are retrieved. For SushiSwap V2, `PairCreated` events containing `pair`, `token0`, and `token1` fields are used. For SushiSwap V3, `PoolCreated` events containing `pool`, `token0`, and `token1`, and `fee` fields are used. The block timestamp, both asset addresses, chain identifier, version (V2 or V3), and fee tier information are extracted. These are merged with asset metadata to add human-readable symbols and decimal precision, creating account names in the format "TOKEN0-TOKEN1".
- **Key fields**: `block_timestamp`, `account_address` (pair/pool address), `token0_address`, `token1_address`, `chain`, `version`, `fee_tier`

### Component B: Asset address consolidation

- **Purpose**: A comprehensive list of all unique assets appearing in trading pairs is created.
- **Logic**: Asset addresses are extracted from both positions in trading pairs and combined into a single list. All `token0_address` and `token1_address` values are aggregated to create a comprehensive list of asset addresses. These are aggregated by day-level timestamp and chain to prepare for uniqueness analysis. This ensures each asset is counted only once regardless of how many different pairs it appears in.
- **Key fields**: `timestamp` (truncated to day), `timestamp_grain`, `chain`, `token_address`

### Component C: First appearance tracking

- **Purpose**: The first appearance of each unique asset on each chain is tracked.
- **Logic**: For each unique combination of chain and asset address, the earliest timestamp when that asset first appeared in any trading pair is determined. Duplicate counting of the same asset across multiple pairs is eliminated, and the exact date each asset became tradeable on SushiSwap is established.
- **Key fields**: `timestamp` (first appearance date), `chain`, `token_address`

### Component D: Daily new asset counting

- **Purpose**: The number of new unique assets appearing each day on each chain is counted.
- **Logic**: First appearances are aggregated by day and chain, and the distinct number of asset addresses first appearing on each specific date is counted. A daily time series showing the incremental addition of new tradeable assets to the platform is created.
- **Key fields**: `timestamp`, `chain`, `asset_count` (new assets that day)

### Component E: Time series completion

- **Purpose**: A complete daily time series without gaps is ensured.
- **Logic**: Continuous daily records are created for each chain by inserting zero values for any missing dates. Correct operation of the cumulative calculation is ensured even if no new assets were added on certain days.
- **Key fields**: `timestamp`, `chain`, `asset_count` (filled with zeros where needed)

### Component F: Cumulative sum and final aggregation

- **Purpose**: The running cumulative sum of unique assets over time is calculated for each chain.
- **Logic**: The daily new asset counts are processed using a cumulative sum calculation. Data is aggregated at daily boundaries. The running cumulative sum of new assets over time within each chain is calculated, operating over all previous dates up to and including the current date, with separate counts maintained per blockchain. Final metric formatting is applied, including market sector classification as "exchanges", business segment as "dex", and chain availability filtering. Currency conversion is not applicable for this count-based metric.
- **Key fields**: `timestamp`, `chain`, `tradeable_assets`

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

Number of unique tokens tradeable on the exchange.

SushiSwapSUSHI

Tradeable assets

Tradeable assets

Competitive landscape

Chain breakdown