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 Cost of revenue Methodology

## 1. Overview

Beethoven cost of revenue represents the revenue share that Beethoven X pays to Balancer for co-managing the Optimism deployment. This metric calculates 50% of Beethoven's protocol revenue generated on Optimism, which is paid to Balancer as compensation for their deployment management services. The calculation captures revenue from trading fees and flash loan fees across the Beethoven/Balancer ecosystem and applies the contractual revenue sharing arrangement.

## 2. Data sources

The calculation relies on several types of blockchain events and external data:

- **Flash loan events**: Parsed `FlashLoan` events from Balancer Vault contracts on Fantom and Optimism, containing loan amounts and fee details
- **Protocol fee events**: Parsed `PoolBalanceChanged` events from Balancer Vault contracts capturing trading-related protocol fee collections
- **Token transfer events**: Fantom and Optimism token transfer records identifying LP token fees paid to protocol fee collectors
- **Transaction data**: Fantom and Optimism transaction records for linking events to user addresses
- **Protocol configuration events**: Parsed `FlashLoanFeePercentageChanged` and `SwapFeePercentageChanged` events tracking protocol fee tier updates over time
- **Pool registration events**: Parsed `PoolRegistered` events from Balancer Vault contracts for identifying pool addresses
- **Token metadata**: Token symbols, decimal places, and contract addresses
- **External price data**: End-of-day token price feeds for USD conversion

## 3. Step-by-step calculation

### Component A: Flash loan fee collection
- **Purpose**: Captures fees generated from flash loan operations across the Beethoven ecosystem
- **Logic**: Extracts parsed `FlashLoan` events from Balancer Vault contracts on both Fantom (Beethoven V1) and Optimism (Balancer V2). For each flash loan, records the `token`, `amount`, and `feeAmount` fields. Joins with transaction data to identify user addresses. Time-based joins with protocol flashloan fee tier updates determine the protocol's share of fees at the time each flash loan occurred. Corrects token amounts using decimal metadata and converts to USD using end-of-day price feeds
- **Key fields**: `token` (token being flash loaned), `amount` (loan principal amount), `feeAmount` (fee charged for the loan), `protocol_fee_tier` (protocol's percentage share of the fee)

### Component B: Protocol fee collection  
- **Purpose**: Captures protocol fees collected from trading activities through two mechanisms
- **Logic**: First mechanism extracts protocol fees directly from `PoolBalanceChanged` events using the `tokens` and `protocolfeeamounts` arrays, representing fees collected in non-LP tokens. Second mechanism identifies LP token fees by tracking token transfers from the null address to protocol fee collector addresses, using pool registration events to identify valid LP tokens. Both mechanisms aggregate fees by transaction and join with protocol trading fee tier updates to back-calculate total trading volume from collected protocol fees. Corrects decimals and converts to USD using end-of-day price feeds
- **Key fields**: `tokens` and `protocolfeeamounts` arrays from balance change events, transfer `value` amounts for LP tokens, `protocol_fee_tier` (protocol's percentage of trading fees)

### Component C: Fee consolidation and daily aggregation
- **Purpose**: Combines all fee sources and normalizes to daily granularity  
- **Logic**: Merges flash loan fees and protocol fees into a unified dataset. For flash loans where `protocol_fee_tier` equals 0, uses fee amounts directly since no protocol revenue is generated. For protocol fees, calculates total fees by dividing collected protocol fee amounts by the protocol fee tier percentage. Aggregates all fees to daily timestamps, maintaining chain, version, account, and token-level granularity
- **Key fields**: `fees` (total fees in USD), `protocol_fee_tier` (determines revenue calculation), `timestamp` (daily aggregation boundary)

### Component D: Revenue calculation
- **Purpose**: Converts total fees into protocol revenue based on fee tier percentages
- **Logic**: Multiplies consolidated fees by their respective protocol fee tiers to determine actual protocol revenue. The calculation is `fees * protocol_fee_tier`, where the protocol fee tier represents the percentage of total fees that the protocol retains as revenue. Aggregates revenue across all tokens and accounts to get total daily revenue by chain
- **Key fields**: `revenue` (protocol's share of fees in USD), `chain_id` (blockchain identifier)

### Final aggregation: Cost of revenue calculation
- **Combining components**: Takes the total daily revenue calculated from fee collection and applies chain filtering to include only Optimism deployment revenue
- **Revenue share application**: Multiplies Optimism revenue by exactly 50% (defined as `balancer_revenue_share = 1/2`) to calculate the amount paid to Balancer for co-managing the deployment
- **Currency conversion**: All amounts are already converted to USD through the fee collection and consolidation steps using end-of-day price feeds
- **Time aggregation**: Maintains daily granularity with gap filling using zero values for days with no revenue
- **Final calculation**: Cost of revenue equals 50% of total protocol revenue generated on Optimism, representing the contractual revenue sharing arrangement between Beethoven X and Balancer for deployment management services

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

Expenses paid to third parties to deliver core service output.

BeetsBEETS

Cost of revenue

Cost of revenue

Competitive landscape

Chain breakdown