Liquidity providers deposit funds into Balancer and receive trading fees from traders (supply-side fees). In addition, Balancer provides liquidity providers with additional yield using boosted pools.

Balancer is a non-custodial exchange protocol built on Ethereum. Balancer was founded by Fernando Martinelli and launched in 2018.

BAL tokenholders own and govern the protocol. They currently take a cut of the total trading and yield fees (revenue). Balancer's investors include DeFiance Capital, Three Arrows Capital, Alameda Research, etc.

governance

github

twitter

discord

etherscan

website

Exchanges (DEX)

Balancer

# Balancer Tradeable pairs Methodology

## 1. Overview

The Balancer tradeable pairs metric measures the cumulative number of active trading pairs (liquidity pools) available on the Balancer decentralized exchange, segmented by liquidity cohorts. This metric tracks the growth of tradeable assets over time and provides insight into the depth of liquidity across different pool sizes. The calculation combines pool creation events with liquidity data to provide both a cumulative count and liquidity-based categorization.

## 2. Data sources

- **Pool creation events**: Parsed `PoolCreated` events from approximately 130 different Balancer v2 factory contracts across Ethereum, Arbitrum, Avalanche, Base, Gnosis, and Polygon networks (Optimism is excluded due to the BeethovenX partnership)
- **Pool reserve data**: End-of-day snapshots of token balances held in Balancer v2 pools from the internal pricing system
- **Token metadata**: Token symbol and chain mapping information for pool identification
- **Price feeds**: End-of-day token price feeds for USD conversion of pool reserves

## 3. Step-by-step calculation

### Component A: Pool discovery and creation tracking
- **Purpose**: Identify all Balancer v2 pools and when they first became available for trading
- **Logic**: Collect `PoolCreated` events from multiple factory contract types including WeightedPool, StablePool, ComposableStablePool, LinearPool variants (Aave, ERC4626, Yearn), ManagedPool, and LiquidityBootstrappingPool factories across supported chains. Extract the pool address (`pool`) and creation timestamp (`block_timestamp`) from each event. Determine the first appearance date for each unique pool by truncating the creation timestamp to daily granularity and taking the minimum date per pool address and chain combination.
- **Key fields**: Pool address (`account_address`), creation timestamp (`block_timestamp`), and chain identifier

### Component B: Daily pair counting and cumulative aggregation
- **Purpose**: Track the daily introduction of new tradeable pairs and maintain a cumulative count
- **Logic**: Group pools by their first appearance date and count distinct pool addresses per day per chain. Apply zero-filling to ensure complete daily time series with no gaps, setting pair count to zero for days without new pool creations. Calculate cumulative tradeable pairs by summing the daily new pair counts over time, partitioned by chain and ordered chronologically.
- **Key fields**: Daily timestamp (`timestamp`), chain identifier, and new pair count (`pair_count`)

### Component C: Liquidity cohort classification
- **Purpose**: Categorize pools based on their USD reserve levels to provide liquidity depth insights
- **Logic**: Use end-of-day pool reserve snapshots that capture token balances at hour 0 of each day, shifted back by one day to represent end-of-previous-day balances. Convert token reserves to USD values using end-of-day price feeds and token decimal adjustment. Apply liquidity cohort thresholds to categorize pools: greater than $1M, $500K-$1M, $100K-$500K, $25K-$100K, $5K-$25K, and less than $5K. Count distinct pools in each liquidity cohort per day per chain.
- **Key fields**: Pool address (`account_address`), USD reserve value (`reserve`), and liquidity cohort classification

### Final aggregation
- **Combining components**: The final result combines three data streams: the base cumulative count of all pools (assigned to the lowest liquidity cohort), positive counts for pools in each specific liquidity cohort based on their actual reserves, and negative counts to subtract pools from the base cumulative count that belong to higher liquidity cohorts (preventing double-counting)
- **Currency conversion**: Token reserves are converted to USD using end-of-day price feeds with appropriate decimal adjustments for each token
- **Time aggregation**: All calculations use daily boundaries with timestamps truncated to day granularity
- **Final calculation**: The metric outputs tradeable pairs segmented by liquidity cohorts, where the base cumulative count is corrected by subtracting pools that qualify for higher liquidity categories, ensuring each pool is counted exactly once in its appropriate liquidity tier

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

Number of unique token pairs available for trading on the exchange.

BalancerBAL

Tradeable pairs

Tradeable pairs

Competitive landscape

Chain breakdown