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

## 1. Overview

Balancer revenue represents the protocol's total earnings from its decentralized exchange operations across multiple blockchain networks. The metric combines two primary revenue streams: direct protocol fees from trading and yield activities on most chains, and partnership revenue sharing with Beethoven X specifically on Optimism. Revenue is calculated by applying protocol fee tiers to collected fees and aggregating across all supported chains and time periods.

## 2. Data sources

The calculation relies on several core blockchain data sources:

- **Balancer V2 Vault events**: Parsed `FlashLoan`, `PoolBalanceChanged`, and `PoolRegistered` events from Balancer V2 Vault contracts across Ethereum, Arbitrum, Avalanche, Base, Gnosis, Optimism, and Polygon networks
- **Protocol fee collector transfers**: Token transfer events to and from the protocol fees collector address (`0xce88686553686da562ce7cea497ce749da109f9f`) across all supported chains
- **Protocol fee updates**: Parsed `SwapFeePercentageChanged` and `FlashLoanFeePercentageChanged` events from ProtocolFeesCollector contracts tracking fee tier modifications over time
- **Transaction records**: Blockchain transaction data providing user addresses and transaction context
- **Token metadata**: Token contract information including decimal precision and symbol data for proper amount calculations
- **End-of-day price feeds**: Daily USD price data for converting token amounts to dollar values

## 3. Step-by-step calculation

### Component A: Flashloan fee collection
- **Purpose**: Captures fees generated from flashloan operations across Balancer pools
- **Logic**: Extracts `FlashLoan` events from Balancer V2 Vault contracts containing borrower address, token address, loan amount, and fee amount. Joins with flashloan fee tier update events using time-based matching to determine the applicable protocol fee percentage at the time of each flashloan. Corrects token amounts using decimal metadata and converts fee amounts to USD using end-of-day price feeds. Aggregates daily by chain, pool, and token
- **Key fields**: `amount` (loan amount), `feeAmount` (fee charged), `token` (borrowed token), `account_address` (pool address), `protocol_fee_tier` (fee percentage)

### Component B: Protocol fee collection from regular tokens
- **Purpose**: Captures protocol fees paid in standard ERC20 tokens from pool operations
- **Logic**: Extracts `PoolBalanceChanged` events from Vault contracts containing pool ID, token arrays, and protocol fee amount arrays. Unnests token addresses and corresponding fee amounts to create individual fee records. Joins with trading fee tier update events using time-based matching to determine applicable protocol fee percentages. Corrects token decimals and converts to USD using end-of-day price feeds
- **Key fields**: `poolid` (pool identifier), `tokens` (token address array), `protocolfeeamounts` (fee amount array), `protocol_fee_tier` (fee percentage)

### Component C: Protocol fee collection from LP tokens
- **Purpose**: Captures protocol fees paid in liquidity provider tokens (pool shares)
- **Logic**: Identifies LP token mints to the protocol fees collector by joining `PoolRegistered` events with token transfer records. Filters transfers where the sender is the zero address (indicating minting) and recipient is the protocol fees collector address. Uses the pool ID from registration events as the token address since Balancer pools are themselves ERC20 tokens. Applies the same decimal correction and USD conversion processes
- **Key fields**: `poolid` (used as token address), `value` (transfer amount), protocol fees collector address as recipient

### Component D: Fee tier application and revenue calculation
- **Purpose**: Applies protocol fee percentages to collected fees to determine Balancer's revenue share
- **Logic**: For each fee record, joins with the appropriate fee tier update events using time-based matching where the fee collection ID falls between consecutive update IDs. Uses protocol fee tier percentages that were active at the time of fee collection. For most chains, calculates revenue by dividing collected protocol fees by the protocol fee tier (to get total fees) then multiplying by the protocol fee tier (to get protocol revenue). For flashloans where protocol fee tier equals zero, uses the fee amount directly
- **Key fields**: `protocol_fee_tier` (percentage applied), calculated `revenue` amount

### Component E: Beethoven X partnership revenue
- **Purpose**: Calculates Balancer's revenue share from the partnership with Beethoven X on Optimism
- **Logic**: Specifically processes Optimism chain data by taking protocol fees collected, dividing by protocol fee tier to determine total fees generated, then multiplying by 50% to represent Balancer's revenue share under the partnership agreement. This separate calculation ensures Balancer receives appropriate revenue attribution for fees generated through the Beethoven X interface on Optimism
- **Key fields**: Partnership revenue calculated as `(amount / protocol_fee_tier) * 0.5`

### Final aggregation
- **Combining components**: Union all revenue streams including direct protocol fees from non-Optimism chains, flashloan fees, and Beethoven X partnership revenue from Optimism. Sum revenues by timestamp, chain, and business dimensions
- **Currency conversion**: All token amounts converted to USD using end-of-day price feeds matched by timestamp, token address, and chain
- **Time aggregation**: Daily aggregation using timestamp truncation to day boundaries, with revenue summed across all transactions within each day
- **Final calculation**: Total daily revenue equals the sum of all protocol fees multiplied by applicable protocol fee tiers plus partnership revenue sharing, aggregated across all chains and revenue sources

*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.

BalancerBAL

Revenue

Revenue

Competitive landscape

Chain breakdown