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 Total value locked Methodology

## 1. Overview

Total value locked (TVL) is calculated as the total USD value of assets deposited and held within SushiSwap's automated market maker (AMM) liquidity pools. It is used as a leading indicator for trading activity and liquidity depth. Asset movements into and out of liquidity pools (including deposits, withdrawals, trades, and fees) are tracked to compute the net change in assets over time, representing the cumulative value locked in the protocol.

## 2. Data sources

- **Blockchain events**: `PairCreated` events from `Factory` contracts, `Sync` events from `Pair` contracts, and `PoolCreated`, `Mint`, `Collect`, `CollectProtocol`, `Swap`, and `Flash` events from `Pool` contracts, covering Ethereum, Arbitrum, Base, Polygon, and 6 other chains
- **External data**: End-of-day asset price feeds and asset metadata

## 3. Step-by-step calculation

### Component A: Trading pair identification

- **Purpose**: Definition of the universe of valid SushiSwap liquidity pools eligible for TVL calculation
- **Logic**: Trading pair addresses are extracted from factory creation events across both V2 and V3 deployments on all supported chains. V2 pairs are identified from `PairCreated` events containing the pair address, `token0_address`, and `token1_address`. V3 pools are identified from `PoolCreated` events containing the pool address, `token0_address`, `token1_address`, and fee tier. Each pair is enriched with asset metadata including decimal precision and symbols. A denylist is applied to filter out specific low-liquidity trading pairs that lack reliable price feed support.
- **Key fields**: `account_address`, `token0_address`, `token1_address`, `token0_decimals`, `token1_decimals`, `account_name`, `fee_tier`, `chain`, `version`

### Component B: V2 asset flow tracking

- **Purpose**: Calculation of daily net asset changes for SushiSwap V2 liquidity pools using reserve tracking
- **Logic**: `Sync` events from `Pair` contracts are processed to extract current reserve amounts for both assets in each pair. For each day, the last reserve update event is identified to capture the final reserve amounts. The daily change is calculated by subtracting the previous day's final reserves from the current day's final reserves. If it is the first day of activity for a pair, the full reserve amount is used as the change. Asset amounts are normalized by decimal precision.
- **Key fields**: `reserve0_amount`, `reserve1_amount`, `token0_amount`, `token1_amount`, `block_timestamp`, `account_address`, `chain`

### Component C: V3 asset flow aggregation

- **Purpose**: Calculation of daily net asset changes for SushiSwap V3 liquidity pools by aggregating individual transaction events
- **Logic**: Multiple event types affecting pool asset balances are combined. `Mint` events from `Pool` contracts are processed for liquidity deposits (positive asset amounts). `Collect` and `CollectProtocol` events from `Pool` contracts are processed for withdrawals, with amounts treated as negative flows. `Swap` events from `Pool` contracts are included to represent trading activity. For flash loans from `Flash` events, the borrowed amounts are multiplied by the pool's fee tier to capture the fee revenue retained by the pool. All flows are aggregated by day and pool address, and asset amounts are normalized by decimal precision.
- **Key fields**: `token0_amount`, `token1_amount`, `account_address`, `fee_tier`, `block_timestamp`, `chain`, `version`

### Component D: Net deposits calculation

- **Purpose**: Computation of the net change in assets for each trading pair
- **Logic**: Combined V2 and V3 asset flows are aggregated by trading pair and day, ensuring that positive values represent net inflows (deposits) and negative values represent net outflows (withdrawals). Specific problematic trading pairs on Base chain are excluded due to data quality issues. Temporal aggregation is performed to handle missing days by carrying forward the previous cumulative balances.
- **Key fields**: `timestamp`, `chain_id`, `token0_address`, `token1_address`, `token0_amount`, `token1_amount`, `account_address`

### Component E: USD conversion and aggregation

- **Purpose**: Conversion of net asset changes to USD and aggregation to calculate total TVL
- **Logic**: Normalized asset amounts are converted to USD by multiplying the daily net changes of each asset by their corresponding end-of-day asset prices. The USD values of both assets in a pair are summed to obtain the total daily net deposits in USD. Daily net deposits are cumulatively aggregated over time to represent the total value locked. Missing days are filled with zero values to ensure complete time series data. The final TVL is calculated as the sum of cumulative net deposits across all trading pairs and chains.
- **Key fields**: `timestamp`, `chain_id`, `tvl`

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

Total value locked (TVL)

Total value locked (TVL) — value deposited into the project's applications.

SushiSwapSUSHI

Total value locked

Total value locked

Competitive landscape

Chain breakdown