Liquidity providers deposit funds into Velodrome and stake their LP tokens to receive VELO tokens in proportion to their share of the votes (token incentives).

Velodrome is a non-custodial exchange protocol built on Optimism. Velodrome was founded by veDAO members and launched in 2022.

VELO tokenholders own and govern the protocol. They vote which pools they wish to earn trading fees from (revenue), while the pools' unstaked liquidity providers earn the remainder of the trading fees (supply-side fees).

github

twitter

discord

etherscan

website

Exchanges (DEX)

Velodrome

# Velodrome Supply-side fees Methodology

## 1. Overview

Supply-side fees for Velodrome represent trading fees claimed directly by liquidity providers (LPs) who choose to receive trading fees rather than VELO token incentives. This metric captures the actual fees earned by LPs across all Velodrome protocol versions (V1, V2, and V3 Slipstream) on Optimism. The calculation tracks fee claim events, excludes claims made by liquidity incentive accounts, converts token amounts to USD, and aggregates daily.

## 2. Data sources

The calculation relies on several types of blockchain data and external feeds:

- **Fee claim events**: Parsed Optimism blockchain events including `Claim` events from Velodrome V1 Pair contracts, `Claim` events from Velodrome V2 Pool contracts, and `CollectFees` events from Velodrome V3 CLPool contracts
- **Trading pair metadata**: Parsed `PairCreated` events from V1 PairFactory contracts, `PoolCreated` events from V2 Factory contracts, and `PoolCreated` events from V3 CLPoolFactory contracts
- **Liquidity incentive data**: Parsed `GaugeCreated` events from V1 and V2 Voter contracts to identify gauge addresses used for liquidity incentives
- **Token metadata**: Token decimals and symbols for proper amount normalization and pair naming
- **End-of-day price feeds**: Daily USD prices for all tokens involved in fee claims

## 3. Step-by-step calculation

### Component A: Fee claim event extraction
- **Purpose**: Captures all fee claim transactions across Velodrome protocol versions
- **Logic**: Extracts fee claim events from three sources: V1 Pair `Claim` events with `sender` as collector, V2 Pool `Claim` events with `sender` as collector, and V3 CLPool `CollectFees` events with `recipient` as collector. Each event contains `amount0` and `amount1` fields representing fees claimed in both tokens of the trading pair. Events are classified by protocol version and assigned business metadata including 'Exchange AMM' as business line, 'exchanges' as market sector, and 'dex' as business segment. Product mapping assigns 'V1' for V1 events, 'V2' for V2 events, and 'Slipstream' for V3 events.
- **Key fields**: `block_timestamp`, `transaction_hash`, `log_index`, `address` (trading pair), `fee_collector_address`, `amount0`, `amount1`, `chain`, and business classification fields

### Component B: Trading pair enrichment
- **Purpose**: Adds token metadata and pair information to fee claim events
- **Logic**: Joins fee claims with trading pair data extracted from factory events across all versions. Factory events provide token addresses for each pair (`token0`, `token1`) and establish the relationship between pair addresses and their underlying tokens. Token metadata is joined to get decimal places for proper amount normalization and symbols for pair naming. Denylisted pairs with limited price feed support are excluded to ensure data quality.
- **Key fields**: `token0_address`, `token1_address`, `token0_decimals`, `token1_decimals`, `account_name` (token pair symbol)

### Component C: Liquidity incentive account filtering
- **Purpose**: Distinguishes supply-side fees from protocol incentive distributions
- **Logic**: Identifies liquidity incentive accounts (gauges) through `GaugeCreated` events from Voter contracts across V1 and V2. These gauge addresses receive fees on behalf of LPs who choose VELO incentives instead of direct fees. Fee claims where the `fee_collector_address` matches any gauge address are excluded, leaving only direct LP fee claims that represent true supply-side fees.
- **Key fields**: `incentive_account_address` (gauge addresses to exclude), `fee_collector_address` (claim recipient)

### Component D: Amount normalization and USD conversion
- **Purpose**: Converts raw token amounts to standard decimal format and USD values
- **Logic**: Raw token amounts are normalized by dividing by 10 raised to the power of each token's decimal places. Daily aggregation groups claims by timestamp truncated to day level while preserving transaction-level detail. USD conversion multiplies normalized amounts with end-of-day token prices for both tokens in each pair. Total fees per claim equal the sum of token0 USD value plus token1 USD value. Claims without available price data default to zero value.
- **Key fields**: `token0_amount` and `token1_amount` (normalized), `fees` (total USD value)

### Final aggregation
- **Combining components**: All processed fee claims are passed through the finalize metric macro which validates business IDs, ensures proper schema structure, and applies time boundary logic
- **Currency conversion**: Uses end-of-day token prices matched by timestamp, token address, and chain for accurate USD conversion
- **Time aggregation**: Data is aggregated at daily granularity with timestamp truncation to day boundaries
- **Final calculation**: The metric represents the total USD value of trading fees claimed directly by liquidity providers, calculated as the sum of USD-converted token amounts across all qualifying fee claim transactions, filtered to exclude incentive account claims and denylisted pairs

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

Portion of fees distributed to service providers or supply-side participants.

VelodromeVELO

Supply-side fees

Supply-side fees

Competitive landscape

Chain breakdown