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 Revenue Methodology

## 1. Overview

Velodrome revenue represents the total value captured by the protocol through two primary revenue streams: trading fees that are distributed to veVELO (vote-escrowed VELO) token holders and voting incentives paid by third-party protocols to influence governance votes. This metric answers the question "How much total revenue does the Velodrome protocol generate?" and is calculated by summing USD-converted trading fee distributions to veVELO holders with voting incentive payments made to the protocol's governance system.

## 2. Data sources

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

- **Blockchain events**: Parsed Optimism blockchain events from Velodrome's smart contracts across three protocol versions (V1, V2, and V3/Slipstream), including `Claim` events from liquidity pools, `CollectFees` events from concentrated liquidity pools, and `NotifyReward` events from bribe voting contracts
- **Governance data**: `GaugeCreated` events from Velodrome's voting contracts that establish the relationship between liquidity pools and their associated gauge contracts
- **Protocol metadata**: Pool and pair creation events from factory contracts that map trading pairs to their underlying token addresses and establish the protocol version hierarchy
- **External data**: End-of-day token price feeds for USD conversion and token metadata containing symbols and decimal precision information
- **Data filtering**: A curated denylist of trading pairs with insufficient price feed coverage for low-liquidity tokens

## 3. Step-by-step calculation

### Component A: Trading fee claims processing
- **Purpose**: Captures trading fees distributed to veVELO holders from all Velodrome protocol versions
- **Logic**: Extracts fee claim events from three different contract versions - V1 `Pair_Claim_event`, V2 `Pool_Claim_event`, and V3 `CLPool_CollectFees_event` - each containing the fee collector address and amounts for two tokens in the trading pair. Events are filtered to exclude denylisted trading pairs that lack reliable price feeds. The process joins with trading pair metadata to identify token addresses and decimal precision, then aggregates daily while correcting for token decimals by dividing raw amounts by 10 raised to the power of each token's decimals. Both token amounts are converted to USD using end-of-day price feeds and summed together
- **Key fields**: `fee_collector_address` identifies who received the fees, `token0_amount` and `token1_amount` contain raw fee amounts, `account_address` specifies the trading pair contract, and `block_timestamp` provides timing information

### Component B: Voting incentives processing  
- **Purpose**: Captures payments made by third-party protocols to incentivize governance votes for specific liquidity pools
- **Logic**: Extracts `NotifyReward` events from Velodrome V2 bribe voting reward contracts, which contain the token address and amount of incentive payments. The raw token amounts are corrected for decimal precision using the standard macro process and converted to USD using end-of-day price feeds matched by timestamp, token address, and chain
- **Key fields**: `token_address` specifies the incentive token, `amount` contains the raw payment amount, and `account_address` identifies the bribe contract

### Component C: Fee collector validation
- **Purpose**: Ensures that fee claims are only counted when they go to legitimate veVELO holders rather than other entities
- **Logic**: Uses `GaugeCreated` events from Velodrome's voter contracts to establish a mapping between liquidity pools and their associated gauge contracts. Fee claims are filtered to only include those where the `fee_collector_address` matches a valid `incentive_account_address` from the gauge creation events, ensuring the fees are distributed to veVELO token holders through the proper governance mechanism
- **Key fields**: `incentive_account_address` from gauge creation events must match `fee_collector_address` from fee claim events

### Final aggregation
- **Combining components**: Trading fee claims and voting incentives are combined using a union operation, with both components sharing the same dimensional structure (timestamp, chain, market sector, business segment, product identification)
- **Currency conversion**: All amounts are converted to USD using end-of-day price feeds matched by exact timestamp, token address, and blockchain network, with null price matches defaulting to zero value
- **Time aggregation**: Events are aggregated to daily boundaries using timestamp truncation, with all intraday events summed together for each unique combination of dimensional attributes
- **Final calculation**: The total revenue equals the sum of all USD-converted trading fees that were distributed to veVELO holders plus all USD-converted voting incentive payments made to the protocol's governance system, standardized through the finalize metric macro which ensures consistent schema structure and fills any temporal gaps with zeros

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

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

VelodromeVELO

Revenue

Revenue

Competitive landscape

Chain breakdown