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 Flash loan volume Methodology

## 1. Overview

The total USD value of flash loans executed on SushiSwap V3 pools across multiple blockchain networks is measured by SushiSwap flash loan volume. Borrowing activity where users temporarily borrow assets within a single transaction, typically for arbitrage or liquidation purposes, is quantified by this metric. Daily flash loan amounts from both assets in each trading pair are aggregated, converted to USD using end-of-day prices, and filtered using protocol-specific parameters and fee tier tracking.

## 2. Data sources

Several blockchain and external data sources are utilized:

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

## 3. Step-by-step calculation

### Component A: Flash loan event extraction

- **Purpose**: All flash loan transactions from SushiSwap V3 pools are identified and extracted.
- **Logic**: `Flash` events are parsed from `Pool` contracts across ten blockchain networks. Key fields are extracted, including `block_timestamp`, `transaction_hash`, `log_index`, contract `address`, `sender` (contract user), and asset amounts (`amount0` and `amount1`). Transaction data is joined to identify the originating user address (`from_address`). Denylist filtering is applied to exclude trading pairs with limited price feed support, ensuring data quality and accuracy.
- **Key fields**: `block_timestamp` for timing, `transaction_hash` and `log_index` for unique identification, `address` as the pool contract, `amount0` and `amount1` as raw asset amounts borrowed, `sender` as contract caller, and derived `user_address` from transaction data

### Component B: Protocol fee tier tracking

- **Purpose**: Protocol fee changes are tracked over time for accurate fee attribution.
- **Logic**: `SetFeeProtocol` events are parsed from `Pool` contracts to monitor protocol fee tier updates for each trading pair. Raw fee protocol values are transformed by calculating the reciprocal (1 divided by the protocol fee value) to obtain the fee tier percentage. The greatest fee tier between token0 and token1 is selected. Historically, protocol fees have been equal for both assets. The greatest fee tier is selected to safeguard the revenue metric in case of future differences in fee tiers. The last fee tier set on each day is retained, and a fill-forward operation is applied to propagate the most recent fee tier to subsequent days without updates. The same denylist filtering is applied as in the flash loan events.
- **Key fields**: `feeProtocol0New` and `feeProtocol1New` transformed to `protocol_fee_tier0` and `protocol_fee_tier1`, with final `protocol_fee_tier` as the filled-forward daily value

### Component C: Trading pair metadata integration

- **Purpose**: Asset metadata is provided and trading pairs are validated against factory-created pools.
- **Logic**: Trading pair data is combined from both `PairCreated` events from `Factory` contracts (V2) and `PoolCreated` events from `Factory` contracts (V3) across all supported chains. Asset addresses and fee tiers are extracted, and joined with asset metadata to retrieve decimal precision and symbols. Readable account names are created by concatenating asset symbols with a dash separator. Consistent chain and version labeling are applied for proper data organization.
- **Key fields**: `token0_address`, `token1_address`, `token0_decimals`, `token1_decimals`, `account_name` (asset pair), `fee_tier`, `chain`, and `version`

### Component D: Volume calculation and aggregation

- **Purpose**: Flash loan data is combined with metadata and USD-denominated volumes are calculated.
- **Logic**: Flash loan events are joined with the daily protocol fee updates on a daily basis to retrieve the protocol fee tier for each trading pair. These are joined with trading pair metadata to access asset decimals and validation. Flash loan amounts are aggregated by day, transaction hash, log index, and account details. Raw asset amounts are normalized by decimal precision. Normalized amounts are converted to USD by multiplying with end-of-day price data for both token0 and token1. The USD values of both assets are summed to calculate the total flash loan volume per transaction.
- **Key fields**: Daily aggregated `token0_amount` and `token1_amount` normalized for decimals, USD-converted values, and final `flash_loan_volume` as the sum of both asset values

### Final aggregation

- **Combining components**: Flash loan events are enriched with protocol fee tier history, trading pair metadata, and price data through multiple join operations, creating a comprehensive dataset with all necessary calculation inputs.
- **Currency conversion**: Asset amounts are normalized by decimal precision, then converted to USD by multiplying with end-of-day asset prices, ensuring standardized value representation across different assets and chains.
- **Time aggregation**: All flash loan events are aggregated to daily boundaries, with volumes summed across all transactions within each day.
- **Final calculation**: The flash loan volume is calculated as the sum of (token0 normalized amount × token0 USD price) plus (token1 normalized amount × token1 USD price), providing the total USD value of assets borrowed in each flash loan transaction, aggregated daily across all SushiSwap V3 pools.

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

Total value of assets borrowed and repaid within the same transaction.

SushiSwapSUSHI

Flash loan volume

Flash loan volume

Competitive landscape

Chain breakdown