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 Trading volume Methodology

## 1. Overview

The total value of trades executed on SushiSwap's decentralized spot exchange is measured by trading volume. Trading activity from both SushiSwap V2 (constant product AMM pools) and SushiSwap V3 (concentrated liquidity pools) is aggregated to provide a comprehensive view of exchange volume. Swap events from both protocol versions are utilized, decimal corrections are applied, values are converted to USD using end-of-day price feeds, and manipulation filtering is implemented to ensure data quality.

## 2. Data sources

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

## 3. Step-by-step calculation

### Component A: Trade data collection

- **Purpose**: To gather all swap transactions from SushiSwap V2 and V3 protocols
- **Logic**: Swap events are sourced from V2 `Swap` events across 8 chains and V3 `Swap` events across 10 chains. For V2 swaps, net asset amounts are calculated by subtracting `amountOut` from `amountIn` for both assets in the pair. For V3 swaps, direct `amount0` and `amount1` values from the swap events are used. Swap events are joined with blockchain transaction records to identify the user addresses initiating trades. Denylist filtering is applied to exclude V3 trading pairs with insufficient price feed coverage.
- **Key fields**: Block timestamp, transaction hash, account address (trading pair), user addresses, `token0_amount`, `token1_amount`, chain identifier, and protocol version

### Component B: Protocol fee tracking

- **Purpose**: To determine applicable protocol fee percentages for revenue calculations
- **Logic**: `SetFeeProtocol` events are collected from SushiSwap V3 pools. Protocol fee tiers are calculated by taking the reciprocal of the fee protocol values and selecting the greatest fee tier between both assets in each pair. The fee tiers are aggregated to a daily level by retaining the last fee tier set on each day. Missing daily values are filled forward using the most recent historical fee tier.
- **Key fields**: Protocol fee tier calculated as the maximum of `1/feeProtocol0` and `1/feeProtocol1`

### Component C: Trading pair metadata

- **Purpose**: To provide asset information needed for decimal correction and pair identification
- **Logic**: `PairCreated` events from V2 factories and `PoolCreated` events from V3 factories are sourced to identify all valid trading pairs. For V2 pairs, a hardcoded fee tier of 0.3% is applied. For V3 pools, dynamic fee tiers are extracted from the `fee` field in pool creation events. These events are joined with asset metadata to obtain decimal places for both assets, and human-readable pair names are created by concatenating asset symbols.
- **Key fields**: `token0_address`, `token1_address`, `token0_decimals`, `token1_decimals`, `fee_tier`, and `account_name`

### Component D: Daily volume aggregation

- **Purpose**: To calculate corrected asset amounts and aggregate by day
- **Logic**: Trade events are joined with trading pair metadata and daily protocol fee data. Timestamps are truncated to daily boundaries for time-based aggregation. Raw asset amounts are normalized by decimal precision. Absolute values of asset amounts are used to handle directional differences between V2 and V3 swap representations. Corrected asset amounts are summed by day, trading pair, and other dimensional attributes.
- **Key fields**: Daily `timestamp`, corrected `token0_amount` and `token1_amount` after decimal adjustment

### Component E: USD conversion and final aggregation

- **Purpose**: To convert asset volumes to USD and aggregate across all pairs
- **Logic**: Daily aggregated asset amounts are joined with end-of-day price feeds for both assets in each trading pair. Corrected asset amounts are multiplied by corresponding USD prices from end-of-day price feeds to obtain USD values. To filter out potential price manipulation or pricing errors, the smaller USD value between the two assets in each swap is selected. Filtered USD trading volumes are summed across all trading pairs and chains, with zero-filling applied for days with no trading activity to maintain a complete time series.
- **Key fields**: `trading_volume`, `timestamp`, and `chain`

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

Total value of spot trades executed on the exchange.

SushiSwapSUSHI

Trading volume

Trading volume

Competitive landscape

Chain breakdown