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 Trade count Methodology

## 1. Overview

The Beethoven X trade count metric measures the daily number of unique trading transactions on the Beethoven X decentralized exchange. This metric answers the business question "How many distinct trades occurred on Beethoven X per day?" and provides insight into trading activity and platform usage. The calculation counts distinct transaction hashes from swap events, ensuring each transaction is counted only once regardless of how many individual token swaps it contains.

## 2. Data sources

The calculation relies on several blockchain data sources:
- **Swap events**: Parsed `Vault_Swap_event` logs from Fantom (Beethoven V1) and Optimism (Balancer V2, co-managed by Beethoven X)
- **Transaction data**: Fantom and Optimism transaction records containing user addresses and transaction metadata
- **Fee tier events**: Pool-level `Pool_SwapFeePercentageChanged_event` logs tracking trading fee updates for individual pools
- **Protocol fee events**: Protocol-level `ProtocolFeesCollector_SwapFeePercentageChanged_event` logs tracking system-wide fee changes
- **Token metadata**: Token decimals, symbols, and identification data for proper amount calculations
- **External data**: End-of-day token price feeds for USD conversion (used in intermediate processing but not final count)

## 3. Step-by-step calculation

### Component A: Raw trade extraction
- **Purpose**: Extract all legitimate swap transactions from blockchain event logs
- **Logic**: Query `Vault_Swap_event` logs from both Fantom (Beethoven V1 contracts) and Optimism (Balancer V2 contracts co-managed by Beethoven X). Filter out pool join and exit transactions by excluding events where either `tokenIn` or `tokenOut` addresses match the pool address (extracted from the first 42 characters of `poolId`). Join with transaction records to obtain user addresses (`from_address`) and enable incremental processing based on block timestamps.
- **Key fields**: `transaction_hash` for unique transaction identification, `poolId` for pool address extraction, `tokenIn` and `tokenOut` for traded token addresses, `amountIn` and `amountOut` for trade amounts, `block_timestamp` for temporal ordering

### Component B: Fee tier tracking
- **Purpose**: Maintain historical records of trading fee changes at both pool and protocol levels
- **Logic**: Track pool-specific trading fee updates from `Pool_SwapFeePercentageChanged_event` logs and protocol-wide fee changes from `ProtocolFeesCollector_SwapFeePercentageChanged_event` logs. Convert fee percentages from wei format (18 decimals) to decimal format. Use window functions to determine the effective range of each fee tier by identifying the next update event for the same pool or protocol.
- **Key fields**: `swapFeePercentage` for pool fees, `newSwapFeePercentage` for protocol fees, `account_address` for pool identification, effective ID ranges for temporal fee application

### Component C: Trading volume calculation (intermediate)
- **Purpose**: Calculate USD trading volumes with proper decimal correction and fee attribution
- **Logic**: Aggregate trade data to daily level, truncating timestamps to day boundaries. Join with token metadata to correct decimal places for token amounts. Apply fee tier information based on trade timing - match trades to active fee tiers using ID ranges where trade ID falls between current and next fee update IDs. Convert token amounts to USD values using end-of-day price feeds. Use the lesser USD value between the two tokens in each trade pair to minimize price manipulation effects.
- **Key fields**: `token0_amount` and `token1_amount` for trade sizes, `decimals` for decimal correction, `fee_tier` and `protocol_fee_tier` for fee calculations, `price_usd` for currency conversion

### Component D: Trade count aggregation
- **Purpose**: Count distinct daily trading transactions grouped by relevant dimensions
- **Logic**: Take the processed trading volume data and aggregate by counting distinct `transaction_hash` values per day. Group results by `timestamp`, `timestamp_grain`, `chain`, `market_sector_id`, `business_segment_id`, and `product_id` to maintain dimensional breakdowns. This ensures each unique transaction is counted exactly once, regardless of the number of individual token swaps it contains.
- **Key fields**: `transaction_hash` for deduplication, dimensional grouping fields for proper aggregation structure

### Final aggregation
- **Combining components**: The trade count aggregation uses the trading volume intermediate model as its base, focusing on the distinct transaction hash counting rather than volume amounts
- **Currency conversion**: No currency conversion needed for the final count metric (only used in intermediate processing)
- **Time aggregation**: Daily boundaries determined by truncating block timestamps to day level using `timestamp_trunc` function
- **Final calculation**: Apply the `finalize_metric_trade_count` macro with `fill_zeros` strategy to ensure consistent time series with zero values for days without trading activity, standardize metric formatting, and apply chain availability filters to exclude unsupported chains from results

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

Number of trades executed on a decentralized exchange.

BeetsBEETS

Trade count

Trade count

Competitive landscape

Chain breakdown