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 Average trading volume (per trade) Methodology

## 1. Overview

The Beethoven trading volume average per trade count metric measures the average USD value per trade executed on Beethoven X decentralized exchange. This metric is calculated by dividing the total daily trading volume by the total number of unique trades for the same period. The calculation provides insight into the typical trade size and market participation patterns on the Beethoven platform, helping assess user behavior and liquidity utilization across both Fantom (Beethoven V1) and Optimism (Balancer V2) deployments.

## 2. Data sources

The metric relies on several core blockchain and external data sources:

- **Swap event logs**: Parsed `Vault_Swap` events from Beethoven V1 contracts on Fantom and Balancer V2 contracts on Optimism, containing token addresses, swap amounts, and pool identifiers
- **Fee update events**: Two types of fee change logs - `Pool_SwapFeePercentageChanged` events for individual pool trading fees and `ProtocolFeesCollector_SwapFeePercentageChanged` events for protocol-wide fee updates
- **Transaction records**: Fantom and Optimism transaction data providing user addresses and transaction metadata
- **Token price feeds**: End-of-day USD price data for all tokens involved in swaps, used for volume conversion
- **Token metadata**: Token contract information including decimal places and symbols for proper amount normalization and readable naming

## 3. Step-by-step calculation

### Component A: Raw trade data extraction
- **Purpose**: Extract and filter valid swap transactions from blockchain event logs
- **Logic**: Parse `Vault_Swap` events from both Beethoven V1 (Fantom) and Balancer V2 (Optimism) contracts. Filter out invalid swaps where either `tokenIn` or `tokenOut` matches the pool address (these represent pool token mints/burns rather than actual trades). Join with transaction records to obtain user addresses. Create unique identifiers using block number and log index formatting.
- **Key fields**: `tokenIn` and `tokenOut` addresses, `amountIn` and `amountOut` quantities, `poolid` for pool identification, transaction hash and user addresses

### Component B: Fee tier application
- **Purpose**: Apply the correct trading and protocol fee rates that were active at the time of each trade
- **Logic**: Join trade data with fee update events using temporal logic. For each trade, find the most recent fee update that occurred before or at the same time as the trade using ID range matching. Apply both pool-level trading fees from `Pool_SwapFeePercentageChanged` events and protocol-level fees from `ProtocolFeesCollector_SwapFeePercentageChanged` events. Use window functions with `lead()` to create valid ID ranges for each fee period.
- **Key fields**: `swapFeePercentage` and `newSwapFeePercentage` converted from wei (18 decimals) to decimal percentage

### Component C: Amount normalization and USD conversion
- **Purpose**: Convert raw token amounts to standardized USD values for volume calculation
- **Logic**: Join with token metadata to obtain decimal places for each token. Normalize raw amounts by dividing by 10 raised to the token's decimal places. Join with end-of-day price feeds to convert normalized amounts to USD values for both tokens in each swap. Apply anti-manipulation filtering by taking the lesser USD amount between the two tokens in each swap pair using the `least()` function.
- **Key fields**: `token0_amount` and `token1_amount` after decimal adjustment, `price_usd` from price feeds, final `trading_volume` as the minimum USD value

### Component D: Daily aggregation for trading volume
- **Purpose**: Aggregate individual trade volumes to daily totals
- **Logic**: Group trades by day using `timestamp_trunc` and sum the USD trading volumes. Maintain chain, business line, and product categorization. Include fee calculations by multiplying trading volume by applicable fee tiers.
- **Key fields**: Daily `trading_volume` sums, chain identifiers, business categorizations

### Component E: Daily aggregation for trade count
- **Purpose**: Count unique trades per day
- **Logic**: Group the same trade data by day and count distinct transaction hashes to determine the number of unique trades. This ensures that trades with multiple swap events within the same transaction are counted as single trades.
- **Key fields**: `trade_count` as count of distinct transaction hashes per day

### Final aggregation
- **Combining components**: Inner join the daily trading volume and daily trade count data on timestamp to ensure matching time periods
- **Currency conversion**: All volumes are already converted to USD using end-of-day price feeds during the intermediate processing
- **Time aggregation**: Both volume and trade count are aggregated to daily boundaries using `timestamp_trunc(day)`
- **Final calculation**: Divide the daily trading volume by the daily trade count using `safe_divide` to handle potential division by zero scenarios, producing the average USD volume per trade for each day

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

BeetsBEETS

Average trading volume (per trade)

Average trading volume (per trade)

Competitive landscape