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 Active users (daily) Methodology

## 1. Overview

Active users (daily) measures the number of unique addresses that make a revenue-generating transaction with SushiSwap on a given day. Users who perform trading activities (swaps) or utilize flash loan functionality across SushiSwap V2 and V3 protocols are captured. This metric is used to determine how many distinct users actively engage with SushiSwap's decentralized exchange services each day. Unique user addresses from swap events and flash loan events are aggregated, ensuring users active in multiple activities on the same day are counted only once.

## 2. Data sources

- **Blockchain events**: `Swap` events from `Pair` contracts (V2) and `Pool` contracts (V3), and `Flash` events from `Pool` contracts (V3), joined with transaction records to extract sender addresses, covering Arc, Arbitrum, Avalanche, Base, and 6 other chains
- **External data**: Denylist of trading pair contract addresses with limited price feed support due to low-liquidity assets

## 3. Step-by-step calculation

### Component A: V2 trading activity extraction

- **Purpose**: Identifies users who performed swaps on SushiSwap V2 protocols
- **Logic**: Parsed `Swap` events from `Pair` contracts are processed across 8 blockchain networks. Swap events are joined with transaction records to extract the actual user address from the `from_address` field rather than using the contract sender address. Net asset amounts for each swap are calculated by taking the difference between input amounts (`amount0In`, `amount1In`) and output amounts (`amount0Out`, `amount1Out`) for both assets in the pair. Data is filtered to the specified incremental processing window when running in incremental mode.
- **Key fields**: `block_timestamp` for timing, `from_address` as the user identifier, `transaction_hash` for transaction linking, asset amount deltas for swap validation

### Component B: V3 trading activity extraction
- **Purpose**: Identifies users who performed swaps on SushiSwap V3 protocols
- **Logic**: Parsed `Swap` events from `Pool` contracts are processed across 10 blockchain networks. Swap events are joined with transaction records to extract user addresses from the `from_address` field. Direct `amount0` and `amount1` values from V3 events are used without calculating differences. Denylist filtering is applied to exclude trading pairs containing low-liquidity assets with limited price feed support, specifically excluding 6 hardcoded contract addresses across Polygon, Arbitrum, and BSC networks. Data is filtered to the incremental processing window when applicable.
- **Key fields**: `block_timestamp` for timing, `from_address` as user identifier, `transaction_hash` for linking, direct `amount0` and `amount1` values

### Component C: V3 flash loan activity extraction

- **Purpose**: Identifies users who utilized flash loan functionality on SushiSwap V3
- **Logic**: Parsed `Flash` events from `Pool` contracts are processed across the same 10 networks as V3 swaps. Flash loan events are joined with transaction records to extract user addresses from the `from_address` field rather than the contract sender. The same denylist filtering as V3 swaps is applied to exclude problematic trading pairs. Asset amounts involved in flash loans (`amount0`, `amount1`) are extracted for completeness. Data is filtered to the incremental processing window when applicable.
- **Key fields**: `block_timestamp` for timing, `from_address` as user identifier, `transaction_hash` for linking, flash loan amounts for validation

### Component D: Final aggregation

- **Purpose**: Combines and aggregates all user activities to calculate active users (daily)
- **Logic**: All three activity components are combined to create a unified dataset of user activities while automatically deduplicating users who appear in multiple activity types on the same day. Timestamps are truncated to daily boundaries to group all activities by calendar day. All identified users are classified as 'Trader' type regardless of their specific activity (swap or flash loan). Final results are filtered based on chain availability configurations to ensure only supported networks are included in the output. The final metric is calculated as the count of distinct `user_address` values per day per chain, where each user address corresponds to a unique wallet that performed at least one qualifying activity (V2 swap, V3 swap, or V3 flash loan) on that specific day and chain.
- **Key fields**: `timestamp` for daily grouping, `chain` for network identification, `user_address` for distinct user counting

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

Unique revenue-generating users over a fixed 24-hour window.

SushiSwapSUSHI

Active users (daily)

Active users (daily)

Competitive landscape

Chain breakdown