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

Beethoven X is a non-custodial exchange protocol built on Fantom and Optimism. It was founded by an anonymous team and launched in 2021.

BEETS tokenholders own and govern the protocol. They currently take a cut of the total trading and yield fees (revenue). Beethoven X shares 50% of the Optimism revenues with Balancer (Beethoven X is an official friendly fork of Balancer).

github

twitter

discord

etherscan

website

Exchanges (DEX)

Beets

# Beets Supply-side fees Methodology

## 1. Overview

Supply-side fees represent the portion of total fees that flow to liquidity providers (LPs) in Beethoven X pools, excluding the protocol's share. The metric is calculated using the formula: supply-side fees = total fees × (1 - protocol fee tier). Beethoven X, as a fork of Balancer V2 operating on Fantom and Optimism, generates fees from two sources: trading fees on AMM swaps and flash loan fees. The calculation combines direct flash loan fee data with reverse-engineered trading fees derived from protocol fee collections.

## 2. Data sources

- **Flash loan events**: Parsed `FlashLoan` events from Balancer Vault contracts on Fantom and Optimism networks containing loan amounts and fee amounts
- **Protocol fee collections**: Parsed `PoolBalanceChanged` events from Vault contracts capturing protocol fees collected in pool tokens
- **LP token transfers**: ERC20 `Transfer` events for Balancer Pool Tokens (BPT) sent from the null address to protocol fee collector addresses
- **Fee tier updates**: Parsed `FlashLoanFeePercentageChanged` and `SwapFeePercentageChanged` events from ProtocolFeesCollector contracts defining protocol fee percentages over time
- **Transaction data**: Ethereum transaction records for resolving user addresses from transaction hashes
- **Token metadata**: Token decimals, symbols, and contract information for decimal correction and display names
- **End-of-day price feeds**: Daily USD price data for converting token amounts to dollar values

## 3. Step-by-step calculation

### Component A: Flash loan fee processing
- **Purpose**: Extract and process fees collected on flash loans, which have varying protocol fee allocations
- **Logic**: Parse `FlashLoan` events from Vault contracts to extract loan amounts and fee amounts paid by borrowers. Join with protocol fee tier updates to determine what portion goes to the protocol versus liquidity providers. When `protocol_fee_tier` equals 0, all flash loan fees flow to LPs as supply-side fees. Apply token decimal corrections by dividing amounts by 10^decimals, then convert to USD using end-of-day price feeds
- **Key fields**: `token_amount` (loan principal), `fee_amount` (flash loan fee), `protocol_fee_tier` (protocol's percentage share), `token_address` (borrowed asset)

### Component B: Trading fee derivation from protocol collections
- **Purpose**: Reverse-calculate total trading fees from protocol fee collections since direct trading fee events are not available
- **Logic**: Identify protocol fee collections from two sources: token amounts collected via `PoolBalanceChanged` events where protocol fees are extracted from pools, and BPT token mints directly to protocol fee collector addresses. Apply decimal corrections and USD conversion. Use the relationship: total trading fees = protocol fee amount ÷ protocol fee tier, since protocol fees represent a percentage of total fees. This reverse-calculation reconstructs the original trading volume fees
- **Key fields**: `amount` (protocol fee collected), `protocol_fee_tier` (protocol percentage), `token_address` (fee token), `account_address` (pool identifier)

### Component C: Protocol fee tier tracking
- **Purpose**: Apply time-based protocol fee percentages to determine fee splits between protocol and LPs
- **Logic**: Track protocol fee tier changes over time using `FlashLoanFeePercentageChanged` and `SwapFeePercentageChanged` events from ProtocolFeesCollector contracts. Convert percentage values from 18-decimal fixed-point format to decimal percentages by dividing by 10^18. Use lead window functions to create validity ranges where each fee tier applies from its event timestamp until the next change event
- **Key fields**: `protocol_fee_tier` (decimal percentage), `id` (event sequence), `next_id` (validity range end)

### Final aggregation
- **Combining components**: Union flash loan fees (when protocol tier = 0) with derived trading fees from protocol collections. Both fee streams are aggregated daily and converted to USD values
- **Currency conversion**: Apply end-of-day USD prices matched by timestamp, chain, and token address. Multiply token amounts by price per unit after decimal correction
- **Time aggregation**: Truncate all timestamps to daily boundaries and group by day. Fill missing days with zero values to maintain continuous time series
- **Final calculation**: For each day's total fees, calculate supply-side portion using: supply-side fees = total fees × (1 - protocol fee tier). When protocol fee tier is 0 (flash loans), the entire fee amount becomes supply-side fees. When protocol fee tier is positive (trading), subtract the protocol's percentage share to get the LP portion

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

Portion of fees distributed to service providers or supply-side participants.

BeetsBEETS

Supply-side fees

Supply-side fees

Competitive landscape

Chain breakdown