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 Trading volume Methodology

## 1. Overview

Trading volume measures the total USD value of tokens traded through Beethoven X decentralized exchange pools on a daily basis. Beethoven X operates on Fantom (V1) and co-manages Balancer deployment on Optimism (V2). The calculation aggregates all swap transactions, converts token amounts to USD using end-of-day prices, and applies price manipulation protection by taking the minimum USD value between the two tokens in each trade.

## 2. Data sources

The trading volume calculation uses several raw data sources:
- **Swap events**: Parsed `Vault_Swap` events from Beethoven V1 contracts on Fantom and Balancer V2 contracts on Optimism
- **Transaction data**: Fantom and Optimism transaction records containing user addresses
- **Fee tier events**: `Pool_SwapFeePercentageChanged` events tracking trading fee updates for individual pools
- **Protocol fee events**: `ProtocolFeesCollector_SwapFeePercentageChanged` events tracking protocol-level fee updates
- **Token metadata**: Token symbols and decimal precision for proper amount calculation
- **External data**: End-of-day token price feeds for USD conversion

## 3. Step-by-step calculation

### Component A: Trade extraction
- **Purpose**: Extract and validate all swap transactions from Beethoven/Balancer contracts
- **Logic**: Parse `Vault_Swap` events from both Fantom (Beethoven V1) and Optimism (Balancer V2) contracts. Each swap event contains `tokenIn`, `tokenOut`, `amountIn`, `amountOut`, and `poolId` fields. Filter out pool token joins and exits by excluding any swaps where either the input or output token address matches the pool address (extracted as first 42 characters of the 66-character `poolId`). Generate unique identifiers by combining block number and log index for chronological ordering.
- **Key fields**: `tokenIn` and `tokenOut` for traded token addresses, `amountIn` and `amountOut` for swap quantities, `poolId` for pool identification, `block_timestamp` for timing

### Component B: Transaction enrichment
- **Purpose**: Add user address information to swap events
- **Logic**: Join swap events with transaction records from both Fantom and Optimism networks using transaction hash. Extract the `from_address` field to identify the user initiating each trade.
- **Key fields**: `from_address` as the trading user, `transaction_hash` for joining events to transactions

### Component C: Fee tier tracking
- **Purpose**: Track dynamic trading fee rates for each pool over time
- **Logic**: Process `Pool_SwapFeePercentageChanged` events to build a time-based mapping of trading fees. Convert fee percentages from 18-decimal format to standard percentages by dividing by 10^18. Use window functions with lead() to create effective date ranges for each fee tier update, allowing swaps to be matched to the correct fee rate based on their chronological position.
- **Key fields**: `swapFeePercentage` for fee rates, `address` for pool identification, temporal ordering for range mapping

### Component D: Protocol fee tracking  
- **Purpose**: Track protocol-level fee changes across the entire platform
- **Logic**: Process `ProtocolFeesCollector_SwapFeePercentageChanged` events to track protocol-wide fee updates. Convert from 18-decimal format and create temporal ranges similar to pool-level fees. These protocol fees apply across all pools and are tracked separately from individual pool trading fees.
- **Key fields**: `newSwapFeePercentage` for protocol fee rates, temporal ranges for effective periods

### Component E: Daily aggregation and decimal correction
- **Purpose**: Aggregate trades by day and correct for token decimal precision
- **Logic**: Group all swaps by day, chain, pool address, and token pair. Sum the raw token amounts for both input and output tokens. Apply decimal correction by dividing each token amount by 10 raised to the power of that token's decimal precision from token metadata. Join with token metadata to get symbols for creating pool display names in format "TOKEN0-TOKEN1".
- **Key fields**: `token0_amount` and `token1_amount` after decimal correction, `account_name` as formatted token pair, daily `timestamp` boundaries

### Component F: USD conversion with manipulation protection
- **Purpose**: Convert token amounts to USD values while protecting against price manipulation
- **Logic**: Join daily aggregated amounts with end-of-day price feeds for both tokens involved in each trade. Calculate USD values by multiplying corrected token amounts by their respective USD prices. Apply price manipulation protection by taking the minimum USD value between the two tokens in each swap pair using the least() function. This prevents inflated trading volumes from manipulated token prices.
- **Key fields**: `price_usd` from price feeds, `trading_volume` as the final USD amount per trade

### Final aggregation
- **Combining components**: All swap data flows through the fee tier joins to attach current fee rates, then through USD conversion with manipulation protection
- **Currency conversion**: Uses end-of-day token price feeds matched by timestamp, token address, and chain to convert to USD
- **Time aggregation**: Trades are aggregated at daily boundaries using timestamp truncation to day level
- **Final calculation**: The final trading volume is the sum of all daily trade USD values (using the minimum between token pairs) across all pools, after applying the `finalize_metric_trading_volume` macro with zero-fill strategy for missing days

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

Total value of spot trades executed on the exchange.

BeetsBEETS

Trading volume

Trading volume

Competitive landscape

Chain breakdown