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 Average trading volume (per trade) Methodology

## 1. Overview

Average trading volume (per trade) is calculated as total daily trading volume divided by daily trade count on SushiSwap. The typical trade size on the platform is measured by this metric, providing insight into user behavior and market dynamics. Trading volume data (the USD value of all swaps) is combined with trade count data (the number of unique transactions) across both SushiSwap V2 and SushiSwap V3 deployments on multiple blockchains.

## 2. Data sources

- **Blockchain events**: `Swap` events from `Pair` and `Pool` contracts, `PairCreated` and `PoolCreated` events from `Factory` contracts, and `SetFeeProtocol` events from `Pool` contracts, combined with native transaction records, 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: Raw trade data extraction

- **Purpose**: Extract all swap transactions from SushiSwap V2 and V3 contracts
- **Logic**: `Swap` events are extracted from `Pair` contracts (V2) and `Pool` contracts (V3) across all supported chains. For V2 swaps, asset amounts are calculated by taking the difference between input and output amounts. For V3 swaps, the `amount0` and `amount1` values are used directly. Swap events are joined with blockchain transaction records to resolve the transaction sender address. Trades from denylisted trading pairs with limited price feed support are filtered out.
- **Key fields**: `block_timestamp`, `transaction_hash`, `log_index`, `account_address`, `token0_amount`, `token1_amount`, `user_address`, `contract_user_address`

### Component B: Trading pair metadata and fee resolution

- **Purpose**: Enrich trade data with trading pair information and current fee structures
- **Logic**: Trades are joined with trading pair dimension data derived from `PairCreated` and `PoolCreated` events from `Factory` contracts to extract asset addresses, decimal precisions, and fee tiers. For V2, a standard fee tier of 0.003 (0.3%) is applied. For V3, the fee tier is retrieved from the pool creation event, and the daily protocol fee tier is resolved from `SetFeeProtocol` events from `Pool` contracts. The greatest of the two asset fee tiers is selected for each day, and the last updated tier of the day is filled forward to subsequent days. The daily protocol fee tier is then joined to the trades by day, contract address, version, and chain.
- **Key fields**: `token0_address`, `token1_address`, `token0_decimals`, `token1_decimals`, `fee_tier`, `protocol_fee_tier`, `account_name`

### Component C: Amount normalization and USD conversion

- **Purpose**: Convert raw asset amounts to standardized USD values
- **Logic**: Asset amounts are normalized by decimal precision. Normalized amounts are joined with end-of-day price feeds by daily timestamp, chain, and asset address to retrieve USD prices. USD values are calculated by multiplying the normalized asset amounts by their respective USD prices. To prevent price manipulation from affecting volume calculations, the lesser of the two USD values (the minimum of the first asset's USD value and the second asset's USD value) is selected as the final trading volume for each trade.
- **Key fields**: `trading_volume`, `timestamp`, `chain`

### Component D: Daily trading volume aggregation

- **Purpose**: Sum all trading volume within each day across all trading pairs and chains
- **Logic**: Trading volumes are grouped by daily timestamp and aggregated using sum aggregation. Groupings by chain, business line, market sector, and business segment are maintained. Chain availability filters are applied to ensure only data from supported chains and active time periods is included.
- **Key fields**: `timestamp`, `timestamp_grain`, `trading_volume`

### Component E: Daily trade count calculation

- **Purpose**: Count the number of distinct trades per day
- **Logic**: Distinct transaction hashes are counted and grouped by daily timestamp. Each unique transaction hash is treated as a single trade, regardless of the number of individual swaps or log entries within that transaction. The same grouping and chain availability filtering logic as the volume calculation is applied to maintain consistency.
- **Key fields**: `timestamp`, `timestamp_grain`, `trade_count`

### Final aggregation

- **Combining components**: Daily trading volume totals and daily trade counts are joined using the daily timestamp as the primary key.
- **Currency conversion**: All volume amounts are converted to USD using end-of-day price feeds during the intermediate calculation steps.
- **Time aggregation**: Daily boundary aggregation is applied using timestamp truncation to day-level granularity.
- **Final calculation**: Total daily trading volume is divided by the total daily trade count using safe division to calculate the average USD value per trade for each day.

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

SushiSwapSUSHI

Average trading volume (per trade)

Average trading volume (per trade)

Competitive landscape