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 Total value locked Methodology

## 1. Overview

Total Value Locked (TVL) for Velodrome is measured as the total USD value of assets deposited in liquidity pools across all versions of the Velodrome DEX protocol. The fundamental question of how much capital is actively providing liquidity on the platform at any given time is addressed by this metric. The calculation approach varies by protocol version: reserve-based tracking is utilized for V1/V2 pools through `Sync` events, while flow-based tracking is utilized for V3 through deposit, withdrawal, trade, and flash loan events.

## 2. Data sources

- **Blockchain events**: `PairCreated` events from `PairFactory` contracts, `PoolCreated` events from `Factory` and `CLPoolFactory` contracts, `Sync` events from `Pair` and `Pool` contracts, `Mint`, `Collect`, `CollectFees`, and `Flash` events from `CLPool` contracts, and `Swap` events from `Pair`, `Pool`, and `CLPool` contracts, covering Optimism
- **External data**: End-of-day price feeds and asset metadata

## 3. Step-by-step calculation

### Component A: Trading pair identification

- **Purpose**: Valid Velodrome liquidity pools are identified across protocol versions
- **Logic**: Pool addresses are extracted from pool creation events across V1 `PairFactory`, V2 `Factory`, and V3 `CLPoolFactory` contracts. Each pool is linked to its underlying asset pair addresses (`token0_address` and `token1_address`), and asset metadata including decimal places and symbols is retrieved. Pool names are created by concatenating asset symbols. A predefined set of denylisted pools with limited price feed support due to low liquidity is excluded.
- **Key fields**: Pool `account_address`, `token0_address`, `token1_address`, `token0_decimals`, `token1_decimals`, and constructed `account_name`

### Component B: V1/V2 reserve-based asset flows

- **Purpose**: Daily net asset flows for V1 and V2 pools are calculated using reserve tracking
- **Logic**: `Sync` events from V1 `Pair` and V2 `Pool` contracts containing current reserve amounts for both assets in each pool are processed. For each day, the last recorded reserve amounts ordered by timestamp and log index are determined. Daily asset flow is calculated as the difference between the current day's final reserves and the previous day's final reserves. For the first day of data, the full reserve amount is used as the initial flow. Raw amounts are normalized by decimal precision.
- **Key fields**: Daily `token0_amount` and `token1_amount` flows representing net changes in pool reserves

### Component C: V3 flow-based asset flows
- **Purpose**: Daily net asset flows for V3 pools are calculated using event tracking
- **Logic**: Multiple V3 event types are combined with appropriate sign handling. `Mint` events from `CLPool` contracts are processed as positive flows (liquidity additions), while `Collect` events (representing position principal and owed fees) and `CollectFees` events (representing protocol and gauge fees) from `CLPool` contracts are processed as negative flows (withdrawals). `Swap` events from `CLPool` contracts are included where asset amounts represent the net change in pool reserves from trading activity. Additionally, `Flash` events from `CLPool` contracts are included to capture flash loan fees retained in the pool. All flows are aggregated by pool address and day. Raw amounts are normalized by decimal precision. Denylisted pools are excluded from all calculations.
- **Key fields**: Daily aggregated `token0_amount` and `token1_amount` representing net asset flows

### Component D: Net deposits calculation

- **Purpose**: Asset flows are processed through a standardized DEX calculation
- **Logic**: A standardized DEX calculation is applied to both V1/V2 and V3 asset flows to perform additional aggregation and validation. A consistent data structure is maintained, and edge cases in flow calculations are handled. Flows from all protocol versions are combined into a unified dataset grouped by timestamp, chain, product version, and pool address.
- **Key fields**: Validated daily `token0_amount` and `token1_amount` flows with consistent dimensions

### Component E: USD conversion and final aggregation

- **Purpose**: Asset flows are combined, converted to USD, and aggregated to produce the final TVL metric
- **Logic**: Asset flows from V1/V2 reserve-based calculations and V3 flow-based calculations are combined into a single dataset with consistent field mapping and business line classification. Daily asset flows are joined with end-of-day token price feeds for both assets in each pair. The daily amount of each asset is multiplied by its respective end-of-day USD price, and these values are summed to calculate the total net deposits per pool per day. Zero is used as the fallback price when price feeds are unavailable. The dataset is grouped by daily timestamp, chain, market sector, business segment, and product ID, and net deposits are summed across all pools to obtain protocol-level totals. Standardized validation is applied to ensure a complete time series with zero-filling for missing days, and all required identifiers are validated.

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

Total value locked (TVL)

Total value locked (TVL) — value deposited into the project's applications.

VelodromeVELO

Total value locked

Total value locked

Competitive landscape

Chain breakdown