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 Trade count Methodology

## 1. Overview

Trade count measures the daily number of unique trading transactions on Balancer V2 decentralized exchange across supported blockchain networks. This metric counts each transaction hash only once per day, regardless of how many individual token swaps occurred within that transaction. The calculation excludes pool join/exit operations and focuses purely on trading activity. The metric provides insight into user engagement and trading frequency on the Balancer protocol.

## 2. Data sources

- **Balancer V2 Vault events**: Parsed `Vault_Swap` events from Ethereum, Arbitrum, Avalanche, Base, Gnosis, Optimism, and Polygon networks that capture individual token swaps
- **Blockchain transaction records**: Transaction data from each supported network to identify user addresses and transaction context
- **Token metadata**: Token information including contract addresses, symbols, and decimal precision for proper amount calculations
- **End-of-day token price feeds**: Daily USD price data for tokens to enable volume calculations in the intermediate processing step

## 3. Step-by-step calculation

### Component A: Raw trade extraction
- **Purpose**: Extract and identify valid trading transactions from Balancer V2 `Vault_Swap` events
- **Logic**: Query `Vault_Swap` events from Balancer V2 contracts across all supported chains. Filter out pool liquidity operations by excluding events where the `tokenIn` or `tokenOut` addresses match the pool address (derived from the first 42 characters of `poolid`). Join with blockchain transaction data to get user addresses. Create unique trade identifiers by combining block number and log index. Extract key trade information including tokens involved, amounts, pool address, and timestamp.
- **Key fields**: `block_timestamp`, `transaction_hash`, unique `id`, `account_address` (pool), `chain`, token addresses (`tokenIn`, `tokenOut`), and token amounts (`amountIn`, `amountOut`)

### Component B: Trade processing and validation
- **Purpose**: Process raw trades, normalize amounts, and calculate USD values for validation
- **Logic**: Aggregate raw token amounts at daily level for each trade to reduce processing overhead. Unpivot token data to handle both sides of each trade efficiently. Join with token metadata to get decimal precision and symbols. Join with end-of-day price feeds to calculate USD values. Re-pivot data to trade level and use the lesser of the two token USD values to filter out potential price manipulation. Join with fee tier update events using temporal logic to assign appropriate fee rates to each trade based on timing.
- **Key fields**: `timestamp` (daily), `transaction_hash`, `chain`, `trading_volume` (USD), `account_address`, `account_name` (token pair), and fee information

### Component C: Daily trade counting
- **Purpose**: Count unique trading transactions per day across different dimensions
- **Logic**: Take processed trades and count distinct transaction hashes per day, grouped by chain, market sector, business segment, and product dimensions. Apply chain-specific filtering to exclude Optimism network from final counts. This ensures each transaction is counted only once regardless of multiple swaps within the same transaction.
- **Key fields**: `timestamp`, `chain_id`, dimensional fields, and `trade_count` (distinct transaction hash count)

### Final aggregation
- **Combining components**: The processed trade data flows directly into the counting step without additional combination
- **Time aggregation**: Data is aggregated to daily boundaries using timestamp truncation, with each day representing a complete 24-hour period in UTC
- **Dimension grouping**: Results are grouped by chain, market sector (exchanges), business segment (dex), and product dimensions to enable cross-sectional analysis
- **Chain filtering**: Optimism network is explicitly excluded from the final trade count results
- **Final calculation**: The metric value equals the count of distinct transaction hashes per day that executed valid Balancer V2 token swaps, after applying all filtering criteria and excluding pool operation transactions

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

Number of trades executed on a decentralized exchange.

BalancerBAL

Trade count

Trade count

Competitive landscape

Chain breakdown