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 Average revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) for Balancer measures the average daily revenue generated per active user of the protocol. This metric is calculated by dividing total daily revenue by the number of daily active users (DAU). The calculation captures revenue from protocol trading fees, flashloan fees, and partnership revenue sharing, while identifying users through their interaction with Balancer's swap and flashloan functionality across multiple chains.

## 2. Data sources

- **Balancer V2 Vault contract events**: Parsed `Swap`, `FlashLoan`, and `PoolBalanceChanged` events from Ethereum, Arbitrum, Avalanche, Base, Gnosis, Optimism, and Polygon networks
- **Protocol fee configuration events**: `SwapFeePercentageChanged` and `FlashLoanFeePercentageChanged` events from ProtocolFeesCollector contracts for fee tier tracking
- **Pool registration data**: `PoolRegistered` events from Vault contracts for LP token identification
- **Blockchain transaction records**: Native transaction data for user address identification across all supported chains
- **Token transfer events**: Native blockchain `Transfer` events for tracking LP token protocol fees
- **End-of-day token price feeds**: USD price data for all tokens involved in protocol operations
- **Token metadata**: Token symbol, decimal precision, and contract information

## 3. Step-by-step calculation

### Component A: Daily active user identification
- **Purpose**: Count distinct users who interact with Balancer protocol each day
- **Logic**: Extract user addresses from blockchain transaction records associated with `Swap` and `FlashLoan` events. Users are classified into two categories: 'Trader' for those executing swaps and 'Flashloan Trader' for those using flashloan functionality. Data is aggregated daily using timestamp truncation. Optimism chain users are excluded from the count as they are attributed to Beethoven X (a protocol partner)
- **Key fields**: `user_address` from transaction records, `block_timestamp` for daily aggregation, `chain` for filtering, user classification by interaction type

### Component B: Protocol fee collection tracking
- **Purpose**: Identify and quantify all protocol fees collected by Balancer
- **Logic**: Extract protocol fees from two primary sources. First, analyze `PoolBalanceChanged` events to identify non-pool LP token fees collected by the protocol fees collector address. Second, track LP token minting to the protocol fees collector through token transfer events where tokens are minted from the zero address to the collector. Unnest token arrays and fee arrays from the events to get individual token-fee pairs
- **Key fields**: `poolId` for pool identification, `tokens` and `protocolFeeAmounts` arrays, `amount` from transfer events, protocol fees collector address for filtering

### Component C: Fee tier determination
- **Purpose**: Determine the applicable protocol fee percentage for revenue calculation
- **Logic**: Track protocol fee tier changes through `SwapFeePercentageChanged` and `FlashLoanFeePercentageChanged` events. Create time windows by tracking the next fee change event for each fee tier update. Convert fee percentages from 18-decimal precision to standard decimal format. Apply the appropriate fee tier to each protocol fee collection based on temporal matching
- **Key fields**: `newSwapFeePercentage` and `newFlashLoanFeePercentage` converted from 18-decimal precision, event timestamps for temporal matching

### Component D: Token amount normalization
- **Purpose**: Convert raw token amounts to standard decimal format and USD values
- **Logic**: Apply token-specific decimal corrections using token metadata to convert raw amounts to human-readable values. Join with end-of-day price feeds to convert token amounts to USD values. Handle special cases like excluding specific problematic tokens from calculations
- **Key fields**: Token `decimals` for normalization, `price_usd` from price feeds, `token_address` and `chain` for matching

### Component E: Flashloan fee calculation
- **Purpose**: Calculate fees from flashloan operations
- **Logic**: Extract flashloan volume and fees from `FlashLoan` events. Apply protocol fee tiers when applicable. Convert token amounts using proper decimals and USD prices. Filter for zero protocol fee tier flashloans and exclude Optimism chain data
- **Key fields**: `amount` and `feeAmount` from flashloan events, `protocol_fee_tier` for fee calculation

### Component F: Revenue aggregation
- **Purpose**: Combine all revenue sources into total daily revenue
- **Logic**: Sum protocol fees multiplied by their respective fee tiers from trading and yield activities. Add flashloan fees where protocol fee tier equals zero. Include 50% revenue share from Beethoven X operations on Optimism chain (calculated as protocol fees divided by fee tier multiplied by 50%). Aggregate all revenue sources by day
- **Key fields**: `fees` multiplied by `protocol_fee_tier`, `revenue` from partnership agreements, daily timestamp aggregation

### Final aggregation
- **Combining components**: Daily revenue totals are divided by daily active user counts to calculate ARPU. Both components are aggregated to the same daily timestamp grain for consistent calculation
- **Currency conversion**: All token amounts are converted to USD using end-of-day price feeds matched by token address, chain, and date
- **Time aggregation**: Data is aggregated to daily boundaries using timestamp truncation to the day level
- **Final calculation**: ARPU equals total daily revenue in USD divided by total daily active users, providing the average revenue generated per user per day

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

BalancerBAL

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape