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

## 1. Overview

Beethoven revenue represents the total fees captured by the Beethoven X protocol (a fork of Balancer) from its decentralized exchange operations on Fantom and Optimism networks. The metric calculates protocol revenue by multiplying total fees by the applicable protocol fee tier percentage. This measures the actual revenue earned by the protocol from trading fees and flash loan fees, excluding fees that go to liquidity providers.

## 2. Data sources

The calculation relies on several raw blockchain data sources:
- **Blockchain events**: Parsed `Vault_FlashLoan_event` events from Beethoven V1 Fantom and Balancer V2 Optimism vault contracts
- **Protocol fee events**: Parsed `Vault_PoolBalanceChanged_event` events containing protocol fee amounts from pool operations
- **Fee tier changes**: `ProtocolFeesCollector_FlashLoanFeePercentageChanged_event` and `ProtocolFeesCollector_SwapFeePercentageChanged_event` events tracking protocol fee percentage updates
- **Token transfer data**: Token transfer events from blockchain transaction logs, specifically transfers from null address to protocol fee collector addresses
- **Pool registration**: `Vault_PoolRegistered_event` events to identify pool contract addresses and their associated LP tokens
- **Transaction data**: Fantom and Optimism transaction records providing transaction context and user addresses
- **External data**: End-of-day token price feeds for USD conversion and token metadata including symbols and decimal places

## 3. Step-by-step calculation

### Component A: Flash loan fee collection
- **Purpose**: Captures fees collected from flash loan operations
- **Logic**: Extracts flash loan events from Beethoven V1 Fantom and Balancer V2 Optimism vault contracts. Each flash loan event contains the borrowed token address, loan amount, and fee amount charged. The system joins these events with flash loan fee tier updates to determine the applicable protocol fee percentage at the time of each transaction. Fee amounts are extracted directly from the `feeAmount` field in the event logs, corrected for token decimals by dividing by 10^decimals, and converted to USD using end-of-day price feeds
- **Key fields**: `token_amount` (loan amount), `feeAmount` (fee charged), `token_address`, `protocol_fee_tier` from fee tier updates

### Component B: Protocol fee collection from trading
- **Purpose**: Captures protocol fees collected from trading and liquidity operations
- **Logic**: Processes two types of protocol fee collection. First, extracts protocol fees paid in regular tokens from `Vault_PoolBalanceChanged_event` events by unnesting the `protocolfeeamounts` array field alongside corresponding `tokens` array to match fees to specific tokens. Second, identifies protocol fees paid in LP tokens by tracking token transfers from the null address to protocol fee collector addresses, using pool registration events to identify which tokens are LP tokens. All collected fees are joined with trading fee tier updates to determine the applicable protocol fee percentage, then undergo decimal correction and USD conversion
- **Key fields**: `protocolfeeamounts` (array of fee amounts), `tokens` (array of token addresses), transfer `value` amounts, `protocol_fee_tier` from fee tier updates

### Component C: Fee tier tracking
- **Purpose**: Maintains historical record of protocol fee percentages over time
- **Logic**: Monitors protocol fee percentage changes through two event types. Flash loan fee changes are tracked via `ProtocolFeesCollector_FlashLoanFeePercentageChanged_event` events, while trading fee changes are tracked via `ProtocolFeesCollector_SwapFeePercentageChanged_event` events. Fee percentages are stored in wei format and converted to decimal by dividing by 10^18. The system uses window functions with lead operations to create validity ranges for each fee tier, enabling point-in-time lookups to match the correct fee percentage to each transaction
- **Key fields**: `newFlashLoanFeePercentage`, `newSwapFeePercentage`, with next event boundaries for range creation

### Component D: Fee unification and total fee calculation
- **Purpose**: Creates unified fee dataset and calculates total fees from collected protocol portions
- **Logic**: Combines flash loan fees and protocol fees into a single dataset. Flash loan fees are included where the protocol fee tier equals 0 (meaning no protocol fee is taken). Protocol fees represent only the portion collected by the protocol, so total fees are calculated by dividing the collected amount by the protocol fee tier percentage (reverse calculation). This yields the total fee amount that was charged, of which the protocol kept its percentage
- **Key fields**: Combined `fees` amounts, `protocol_fee_tier` for calculations

### Final aggregation
- **Combining components**: The unified fee dataset contains both direct fees (flash loans) and calculated total fees (from protocol collections)
- **Currency conversion**: All fee amounts are converted to USD using end-of-day price feeds matched by timestamp, token address, and chain
- **Time aggregation**: Fees are aggregated to daily granularity using timestamp truncation to day boundaries
- **Final calculation**: Revenue is calculated as fees multiplied by protocol fee tier percentage. For flash loans where protocol_fee_tier equals 0, revenue is 0. For trading fees, revenue equals the total calculated fees multiplied by the applicable protocol fee percentage, which should equal the original collected protocol fee amount

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

BeetsBEETS

Revenue

Revenue

Competitive landscape

Chain breakdown