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

## 1. Overview

SushiSwap revenue is measured as the protocol's share of trading fees collected from automated market maker (AMM) trading pairs and flash loans. Revenue is calculated by applying protocol fee shares to total fees generated from trading activity and flash loan usage. A fixed protocol fee share of 1/6 (approximately 16.67%) of total trading fees is applied for SushiSwap V2, while dynamic protocol fees are implemented for V3 on a per-pool basis.

## 2. Data sources

- **Blockchain events**: `PairCreated` and `PoolCreated` events from `Factory` contracts, `Swap` events from `Pair` contracts, `Swap`, `Flash`, and `SetFeeProtocol` events from `Pool` contracts, and blockchain transactions, 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: Trading pair identification

- **Purpose**: Identify all valid SushiSwap trading pairs and their fee structures.
- **Logic**: Trading pair addresses are extracted from `PairCreated` and `PoolCreated` events from `Factory` contracts. A fixed fee tier of 0.3% is used for V2 pairs, while variable fee tiers specified in the creation event are applied to V3 pools. Asset metadata is combined to retrieve decimal precision and symbols. Denylisted trading pairs with limited price feed support for low liquidity assets are excluded.
- **Key fields**: `account_address`, `token0_address`, `token1_address`, `fee_tier`, `token0_decimals`, `token1_decimals`

### Component B: Trading volume calculation

- **Purpose**: Calculate daily trading volumes in USD for all trading pairs.
- **Logic**: Swap events from both V2 and V3 protocols are processed. For V2, asset amount changes are calculated as the difference between incoming and outgoing amounts for each asset. For V3, direct amount values are used. Transactions are aggregated by day, with absolute values of asset amounts taken and normalized by decimal precision. Asset amounts are converted to USD using end-of-day price feeds. To prevent manipulation from inflated asset prices, the minimum USD value between the two assets in each pair is used to represent trading volume.
- **Key fields**: `token0_amount`, `token1_amount`, `contract_user_address`, `user_address`

### Component C: Flash loan volume calculation

- **Purpose**: Calculate daily flash loan volumes in USD for V3 pools.
- **Logic**: `Flash` events from V3 `Pool` contracts are processed to capture flash loan activity. The amount fields representing the flash loan amounts for each asset are extracted. Amounts are aggregated by day and normalized by decimal precision. Both asset amounts are converted to USD using end-of-day price feeds and summed to obtain the total flash loan volume.
- **Key fields**: `token0_amount`, `token1_amount`, `contract_user_address`, `user_address`

### Component D: Protocol fee tracking

- **Purpose**: Track protocol fee percentages for V3 pools over time.
- **Logic**: `SetFeeProtocol` events from V3 `Pool` contracts are processed to capture updates to protocol fee settings. The protocol fee tier is calculated as the inverse of the new protocol fee values. If different protocol fees are set for the two assets, the greater value is selected. The last protocol fee tier set on each day is selected and propagated to subsequent days to represent the active rate. This daily rate is then applied to the daily aggregated trades and flash loans.
- **Key fields**: `protocol_fee_tier0`, `protocol_fee_tier1`, `protocol_fee_tier`

### Component E: Fee calculation

- **Purpose**: Calculate total fees generated from trading and flash loan activity.
- **Logic**: Trading volumes are multiplied by their respective pool fee tiers to calculate trading fees. Flash loan volumes are multiplied by their respective pool fee tiers to calculate flash loan fees. Both fee streams are combined into a unified fee dataset.
- **Key fields**: `trading_volume`, `flash_loan_volume`, `fee_tier`

### Component F: Revenue calculation and aggregation

- **Purpose**: Calculate the final daily revenue metric.
- **Logic**: Revenue is calculated by multiplying total fees by the applicable protocol fee share. For V2, a fixed protocol fee share of 1/6 (approximately 16.67%) is applied. For V3, the dynamic protocol fee tier specific to each pool and day is applied. All volume and fee calculations are converted to USD using end-of-day prices applied at the transaction date. Data is aggregated on daily boundaries using timestamp truncation to the day level.
- **Key fields**: `fees`, `protocol_fee_tier`, `revenue`

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

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

SushiSwapSUSHI

Revenue

Revenue

Competitive landscape

Chain breakdown