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 Liquidity turnover Methodology

## 1. Overview

Liquidity turnover is calculated as the ratio of daily trading volume to total value locked (TVL) on SushiSwap, with both metrics denominated in USD. This metric is used to evaluate how efficiently liquidity is utilized to facilitate trades. Higher turnover is indicative of more efficient capital utilization, while lower turnover is associated with excess idle liquidity or reduced trading demand.

## 2. Data sources

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

## 3. Step-by-step calculation

### Component A: Trading volume calculation

- **Purpose**: Measures the total USD value of assets traded on SushiSwap daily
- **Logic**: `Swap` events are collected from SushiSwap V2 and V3 contracts. For V2, net asset changes are calculated by subtracting `amount0Out` and `amount1Out` from `amount0In` and `amount1In`. For V3, `amount0` and `amount1` values are used directly from swap events. Swap events are joined with blockchain transaction records to identify the originating user address. Swaps from denylisted trading pairs with poor price feed coverage are excluded. Asset amounts are normalized by decimal precision using asset metadata. Both asset amounts are converted to USD using end-of-day price feeds, and the minimum USD value between the two assets is selected to filter out potential price manipulation. The minimum USD values are aggregated daily.
- **Key fields**: `amount0In`, `amount0Out`, `amount1In`, `amount1Out`, `amount0`, `amount1`

### Component B: Total value locked calculation

- **Purpose**: Measures the total USD value of assets deposited in SushiSwap liquidity pools
- **Logic**: Net asset flows into and out of liquidity pools are tracked using different approaches for V2 and V3. For V2, `Sync` events containing `reserve0` and `reserve1` values are used to represent current pool reserves, and daily changes in reserves are calculated as asset flows. For V3, multiple event types are combined: `Mint` events (liquidity deposits) are added, `Collect` and `CollectProtocol` events (withdrawals) are subtracted, `Swap` events (net trading impact on reserves) are included, and `Flash` events multiplied by the pool's fee tier (flash loan fees collected) are included. Events from denylisted trading pairs are excluded. All events are joined with trading pair dimension data to retrieve asset addresses and decimal information. Asset amounts are normalized by decimal precision and converted to USD using end-of-day price feeds. The USD values of both assets are summed to determine the total pool value. Net flows are aggregated daily to calculate cumulative TVL over time.
- **Key fields**: `reserve0`, `reserve1`, `amount0`, `amount1`, `fee_tier`

### Component C: Trading pair and protocol data

- **Purpose**: Provides metadata and protocol configuration parameters needed for calculations and filtering
- **Logic**: `PairCreated` events from V2 factories and `PoolCreated` events from V3 factories are used to map pool contract addresses to their underlying asset pairs. Asset addresses and fee tiers are extracted from these creation events. These are joined with asset metadata to retrieve decimal places and symbols. A denylist of pool addresses is maintained to exclude pools with limited price feed support. Protocol fee tier changes are tracked using `SetFeeProtocol` events from V3 pools. For each day, the greatest of the two asset fee tiers is kept, and the last tier set on each day is selected as the active tier. A fill-forward strategy is applied to propagate the active protocol fee tier to subsequent days.
- **Key fields**: `account_address`, `token0_address`, `token1_address`, `fee_tier`, `protocol_fee_tier`

### Component D: Liquidity turnover calculation

- **Purpose**: Calculates the final liquidity turnover ratio
- **Logic**: Daily trading volume and TVL are calculated independently and joined by day. Liquidity turnover is calculated by dividing daily trading volume by TVL. Missing data points are filled with zeros.
- **Key fields**: `trading_volume`, `tvl`, `liquidity_turnover`

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

Trading volume divided by total liquidity.

SushiSwapSUSHI

Liquidity turnover

Liquidity turnover

Competitive landscape