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 Supply-side fees Methodology

## 1. Overview

Supply-side fees are measured as the portion of transaction fees that accrue to liquidity providers in SushiSwap's automated market maker (AMM) pools. This metric is used to determine the amount of fee revenue distributed to liquidity providers who supply capital to the protocol. Different methodologies are applied for SushiSwap V2 and SushiSwap V3, reflecting their distinct fee structures. For V2, supply-side fees are calculated as 5/6 (83.33%) of total fees, while for V3, they are calculated as total fees minus protocol fees.

## 2. Data sources

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

## 3. Step-by-step calculation

### Component A: SushiSwap V2 and V3 trading pair identification

- **Purpose**: To establish the universe of SushiSwap trading pairs and their fee structures across both V2 and V3.
- **Logic**: Trading pair addresses are extracted from factory creation events. For V2, `PairCreated` events from `Factory` contracts are parsed to identify pair contracts with a fixed fee tier of 0.3%. For V3, `PoolCreated` events from `Factory` contracts are parsed to identify pool contracts with variable fee tiers extracted from the fee field. These are joined with asset metadata to obtain asset addresses, decimal precisions, and symbols for each trading pair. A denylist of specific pool addresses with limited price feed support is applied to exclude low-quality data.
- **Key fields**: `account_address`, `token0_address`, `token1_address`, `fee_tier`, `token0_decimals`, `token1_decimals`, and `account_name`

### Component B: SushiSwap V2 and V3 trading volume calculation

- **Purpose**: To calculate daily USD trading volume for each trading pair from swap events.
- **Logic**: Swap events are extracted from both V2 and V3 pools. For V2, `Swap` events from `Pair` contracts are parsed, and asset amount changes are calculated as the difference between the incoming and outgoing amount fields. For V3, `Swap` events from `Pool` contracts are parsed, and direct asset amount fields are utilized. These amounts are joined with trading pair data and normalized by decimal precision. Daily trading volumes are aggregated and converted to USD using end-of-day price feeds. To prevent price manipulation, the lesser of the two asset USD values is selected. Denylisted trading pairs are excluded from V3 calculations.
- **Key fields**: `trading_volume`, `timestamp`, `chain`, `version`, `fee_tier`, and `protocol_fee_tier`

### Component C: SushiSwap V3 flash loan volume calculation

- **Purpose**: To calculate daily USD flash loan volume for V3 pools.
- **Logic**: `Flash` events are extracted from V3 `Pool` contracts containing flash loan amounts for both assets. These are joined with trading pair dimensions to normalize asset amounts by decimal precision. Flash loans are aggregated daily and converted to USD using end-of-day price feeds. Both asset USD values are summed to calculate total flash loan volume.
- **Key fields**: `flash_loan_volume`, `timestamp`, `chain`, `version`, `fee_tier`, and `protocol_fee_tier`

### Component D: SushiSwap V3 protocol fee tracking

- **Purpose**: To track daily protocol fee percentages for V3 pools to enable accurate supply-side fee calculations.
- **Logic**: `SetFeeProtocol` events are parsed from V3 `Pool` contracts to track updates to protocol fee percentages. The greatest of the two asset fee tiers is selected. To establish a daily fee tier, the last updated tier on each day is selected, and a fill-forward mechanism is applied to fill days without updates using the most recent historical value. This daily protocol fee tier is then joined to the daily aggregated trading and flash loan volumes.
- **Key fields**: `protocol_fee_tier`

### Component E: Fee calculation

- **Purpose**: To calculate total fees generated from both trading and flash loan activities.
- **Logic**: Trading volume is multiplied by the respective pool's fee tier to calculate trading fees. Flash loan volume is multiplied by the respective pool's fee tier to calculate flash loan fees. Both fee streams are combined into a unified dataset containing all necessary dimensions for supply-side fee calculation.
- **Key fields**: `fees`, `version`, `fee_tier`, and `protocol_fee_tier`

### Component F: Supply-side fee calculation and aggregation

- **Purpose**: To calculate the final supply-side fees by applying version-specific logic and aggregating the results.
- **Logic**: Version-specific logic is applied to determine the fees accruing to liquidity providers. For V2, total fees are multiplied by 5/6 (83.33%) to calculate the supply-side share. For V3, protocol fees are subtracted from total fees using the formula: `fees_supply_side = fees - (fees * protocol_fee_tier)`. The resulting supply-side fees are aggregated daily.
- **Key fields**: `fees_supply_side`

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

Portion of fees distributed to service providers or supply-side participants.

SushiSwapSUSHI

Supply-side fees

Supply-side fees

Competitive landscape

Chain breakdown