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

## 1. Overview

Velodrome expenses represent the total value of VELO token incentives distributed to liquidity providers through the protocol's gauge reward system. This metric captures the protocol's cost of incentivizing liquidity provision across its automated market maker (AMM) pools. The calculation aggregates daily reward distributions from all active gauges and converts them to USD to provide a comprehensive view of the protocol's liquidity incentive expenditure.

## 2. Data sources

The calculation relies on several types of blockchain data and external feeds:
- **Blockchain events**: Parsed Optimism `Gauge_ClaimRewards_event` logs from Velodrome V1 and V2 gauge contracts capturing reward distributions
- **Governance events**: Parsed Optimism `Voter_GaugeCreated_event` logs from Velodrome voter contracts establishing gauge-to-pool relationships
- **Factory events**: Parsed Optimism pool/pair creation events from Velodrome factories (`PairFactory_PairCreated_event` for V1, `Factory_PoolCreated_event` for V2, `CLPoolFactory_PoolCreated_event` for V3)
- **Token metadata**: Token symbols and decimal configurations for proper amount normalization and display names
- **External data**: End-of-day price feeds for VELO token USD conversion

## 3. Step-by-step calculation

### Component A: Liquidity incentive events
- **Purpose**: Captures all VELO token reward distributions from Velodrome gauge contracts
- **Logic**: Extracts `Gauge_ClaimRewards_event` logs from both Velodrome V1 and V2 gauge contracts on Optimism. Each event represents a reward claim by a liquidity provider, containing the gauge contract address and the amount of VELO tokens distributed. The component standardizes the data format across protocol versions, assigning appropriate version labels and token addresses (V1 uses `0x3c8b650257cfb5f272f799f5e2b4e65093a11a05`, V2 uses `0x9560e827af36c94d2ac33a39bce1fe78631088db`). Business classification fields are applied consistently, categorizing all events under the 'Exchange AMM' business line within the 'exchanges' market sector.
- **Key fields**: `block_timestamp` for timing, `account_address` for the gauge contract, `amount` for VELO token quantity, `token_address` for the specific VELO token version

### Component B: Gauge-to-pool mapping
- **Purpose**: Establishes the relationship between gauge contracts (reward distributors) and their corresponding liquidity pools
- **Logic**: Processes `Voter_GaugeCreated_event` logs from Velodrome voter contracts across V1 and V2. Each event records when a new gauge is created for a specific liquidity pool, providing the essential mapping between the gauge address (where rewards are distributed) and the pool address (the actual trading pair). This mapping is crucial because reward events only contain gauge addresses, but the meaningful business context comes from understanding which trading pairs are being incentivized.
- **Key fields**: `gauge` address as the incentive distribution point, `pool` address as the associated trading pair, version and chain metadata

### Component C: Trading pair metadata
- **Purpose**: Enriches pool addresses with human-readable information about the underlying token pairs
- **Logic**: Aggregates pool creation events from multiple Velodrome factory contracts across different versions. V1 uses `PairFactory_PairCreated_event`, V2 uses `Factory_PoolCreated_event`, and V3 uses `CLPoolFactory_PoolCreated_event`. Each creation event captures the pool address along with its constituent token addresses (`token0` and `token1`). The component joins with token metadata to retrieve token symbols and decimal configurations, then constructs readable pool names by concatenating token symbols with a hyphen separator (e.g., 'ETH-USDC').
- **Key fields**: `account_address` for the pool contract, `token0_address` and `token1_address` for the paired tokens, `token0_decimals` and `token1_decimals` for proper amount handling, `account_name` as the formatted trading pair label

### Final aggregation
- **Combining components**: The reward events are joined with the gauge-to-pool mapping using gauge addresses, then further joined with trading pair metadata using pool addresses. This creates complete records showing which trading pairs received incentives and in what amounts
- **Currency conversion**: Raw VELO token amounts are converted from wei to proper token units using the token's decimal configuration, then converted to USD using end-of-day price feeds. The conversion applies the closing price from the same day as the reward distribution
- **Time aggregation**: Events are aggregated to daily boundaries using timestamp truncation to the day level. All rewards distributed within a calendar day are summed together
- **Final calculation**: The sum of all VELO token rewards (converted to USD) distributed across all gauges on each day represents the total daily expenses. The metric includes standard Token Terminal formatting with gap-filling logic that inserts zero values for days with no reward distributions, ensuring complete time series coverage

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

Total project operating and incentive expenses.

VelodromeVELO

Expenses

Expenses

Competitive landscape

Chain breakdown