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 revenue per user (ARPU) Methodology

## 1. Overview

Average revenue per user (ARPU) measures the daily revenue generated per active user across SushiSwap's decentralized exchange operations. It is calculated as total daily revenue divided by active users (daily), reflecting how effectively the protocol is able to monetize individual users on a daily basis. Insight into user value generation and revenue efficiency across the SushiSwap V2 and SushiSwap V3 automated market maker (AMM) protocols is provided by this metric.

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

## 3. Step-by-step calculation

### Component A: Trading volume calculation

- **Purpose**: Calculates daily trading volumes from swap events across SushiSwap V2 and SushiSwap V3 protocols
- **Logic**: Trading activity is captured through `Swap` events extracted from `Pair` contracts for SushiSwap V2 and `Pool` contracts for SushiSwap V3. For SushiSwap V2, asset changes are calculated as the difference between incoming and outgoing asset amounts, while direct asset amounts are used for SushiSwap V3. Trading pair data is joined to retrieve asset addresses and decimals, and asset amounts are normalized by decimal precision. Normalized amounts are converted to USD using end-of-day price feeds for both assets in each pair. To prevent price manipulation, anti-manipulation filtering is applied by taking the lesser of the two asset USD values. Daily trading volumes are aggregated by truncating timestamps to day boundaries.
- **Key fields**: `token0_amount`, `token1_amount`, `account_address`, `user_address`, `block_timestamp`

### Component B: Flash loan volume calculation
- **Purpose**: Calculates daily flash loan volumes from SushiSwap V3 flash events
- **Logic**: Flash loan events are extracted from `Flash` events from `Pool` contracts. Direct asset amounts are used without calculating differences. Trading pair metadata is joined to retrieve asset addresses and decimals, asset amounts are normalized by decimal precision, and values are converted to USD using end-of-day price feeds. Unlike trading volumes, the USD values of both assets are summed to represent the total borrowed amount. Daily flash loan volumes are aggregated by truncating timestamps to day boundaries.
- **Key fields**: `token0_amount`, `token1_amount`, `account_address`, `user_address`, `block_timestamp`

### Component C: Protocol fee tracking

- **Purpose**: Tracks protocol fee rates for accurate revenue calculation, especially for V3 pools with dynamic fees
- **Logic**: Protocol fee updates are tracked by extracting `SetFeeProtocol` events from `Pool` contracts. Fee protocol values are converted to tier percentages by taking reciprocals. The greatest of the two asset fee tiers is selected. To establish a daily record, the last fee tier set on each day is retained, representing the rate in force at the close of the day. Missing days are filled forward with the most recently available protocol fee tier. For pools without explicit fee updates, the protocol fee tier defaults to zero.
- **Key fields**: `protocol_fee_tier`, `account_address`, `block_timestamp`

### Component D: Fee and revenue calculation

- **Purpose**: Calculates protocol revenue from trading and flash loan fees
- **Logic**: Fees are calculated for both trading and flash loan volumes using pool-specific fee tiers retrieved from trading pair metadata. Gross fees are determined by multiplying volumes by their respective fee rates. For SushiSwap V2, protocol revenue is calculated by applying a fixed protocol fee share of 1/6 (approximately 16.67%) to the gross fees. For SushiSwap V3, protocol revenue is calculated by multiplying gross fees by the dynamic protocol fee tiers tracked from `SetFeeProtocol` events.
- **Key fields**: `fees`, `fee_tier`, `protocol_fee_tier`, `trading_volume`, `flash_loan_volume`

### Component E: Daily active user calculation

- **Purpose**: Counts unique users engaging with SushiSwap protocols daily
- **Logic**: User addresses are extracted from both trading and flash loan activities by joining swap and flash events with transaction data to identify the originating transaction sender address. Unique user addresses are aggregated daily across both activities, and a union is performed to prevent double-counting. Active users (daily) are calculated by counting distinct user addresses per day, with breakdowns generated by chain, user type, and product.
- **Key fields**: `user_address`, `user_dau`, `timestamp`

### Component F: Final aggregation and ARPU calculation

- **Purpose**: Combines revenue and user metrics to calculate the final average revenue per user
- **Logic**: Daily protocol revenue and active users (daily) are calculated independently. Daily protocol revenue is divided by active users (daily) to calculate the average revenue per user (ARPU). All asset amounts are converted to USD using end-of-day price feeds matched by timestamp, asset address, and chain. Missing days are filled with zeros, and chain availability filters are applied to ensure data quality.
- **Key fields**: `revenue`, `user_dau`, `arpu`

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

SushiSwapSUSHI

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape