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 Trade count Methodology

## 1. Overview

The daily number of unique trades executed on the SushiSwap decentralized exchange is measured by the trade count metric. Distinct transactions containing swap events are counted to provide insight into trading activity and user engagement on the platform. Swap events from both SushiSwap V2 and V3 protocols are aggregated, with low-quality trades filtered out while preserving legitimate trading activity.

## 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 transaction records covering Ethereum, Polygon, Avalanche, Arbitrum, and 6 other chains
- **External data**: End-of-day price feeds and asset metadata

## 3. Step-by-step calculation

### Component A: Raw trade extraction

- **Purpose**: All swap events are extracted from SushiSwap V2 and V3 contracts across supported chains.
- **Logic**: Parsed swap event logs are queried from both protocol versions. For V2, asset amounts are calculated as the difference between `amountIn` and `amountOut` fields. For V3, direct `amount0` and `amount1` fields are used. Swap events are joined with transaction records to obtain user addresses. Essential identifiers including transaction hashes, log indexes, contract addresses, and timestamps are captured.
- **Key fields**: `transaction_hash`, `log_index`, `account_address`, `token0_amount`, `token1_amount`, `user_address`, `block_timestamp`

### Component B: Trading pair validation

- **Purpose**: A registry of valid trading pairs with metadata is created.
- **Logic**: Trading pair creation events are extracted from factory contracts. For V2, `PairCreated` events from `Factory` contracts are used with a fixed 0.3% fee tier. For V3, `PoolCreated` events from `Factory` contracts are used with variable fee tiers extracted from the fee field. These events are joined with asset metadata to obtain decimals and symbols for proper amount calculation. Pair names are generated by concatenating asset symbols.
- **Key fields**: `account_address`, `token0_address`, `token1_address`, `token0_decimals`, `token1_decimals`, `fee_tier`, `account_name`

### Component C: Protocol fee tracking

- **Purpose**: Protocol fee changes are tracked for V3 pools over time.
- **Logic**: `SetFeeProtocol` events are extracted from `Pool` contracts. Protocol fee tiers are calculated as the reciprocal of the fee protocol values. The maximum fee between the two asset fee tiers is selected to represent the effective protocol fee. For each pool, the last fee tier set on each day is selected and filled forward to subsequent days to maintain a continuous record of active fee tiers.
- **Key fields**: `account_address`, `protocol_fee_tier`, `timestamp`

### Component D: Trade processing and validation

- **Purpose**: Trades are combined with metadata and quality filters are applied.
- **Logic**: Raw trades are joined with trading pair metadata to validate legitimate pairs and obtain asset decimals. Trades from denylisted pairs with poor price feed coverage are excluded. The daily protocol fee tier is joined to each trade. Asset amounts are corrected by normalizing by decimal precision.
- **Key fields**: `transaction_hash`, `log_index`, `chain`, `account_address`, corrected `token0_amount` and `token1_amount`

### Component E: USD conversion and manipulation filtering

- **Purpose**: Asset amounts are converted to USD and price manipulation is filtered.
- **Logic**: Corrected asset amounts are joined with end-of-day price feeds for both assets in each trade. USD values are calculated for both asset amounts. A price manipulation filter is applied by taking the lesser USD value between the two assets. Inflated volumes from manipulated asset prices are thereby prevented.
- **Key fields**: `trading_volume`, `timestamp`, `chain`

### Component F: Final aggregation and standardization

- **Purpose**: Processed trades are aggregated daily and standardized.
- **Logic**: All processed trades are aggregated at the daily level. Unique transaction identifiers are preserved to count distinct transactions per day. Trades are grouped by day, chain, and business dimensions. Final metric standardization is applied with missing days filled with zeros, and chain availability filtering is performed to ensure data completeness.
- **Key fields**: `timestamp`, `chain_id`, `trade_count`

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

Number of trades executed on a decentralized exchange.

SushiSwapSUSHI

Trade count

Trade count

Competitive landscape

Chain breakdown