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 user) Methodology

## 1. Overview

This metric calculates the average daily trading volume per daily active user for Beethoven X, a Balancer-based automated market maker (AMM) protocol. The metric answers the business question: "What is the average USD value of trading volume generated by each active user on a given day?" The calculation divides total daily trading volume by the count of unique daily active users, providing insight into user engagement intensity and capital efficiency.

## 2. Data sources

- **Blockchain events**: Parsed `Vault_Swap_event` logs from Fantom (Beethoven V1) and Optimism (Balancer V2) containing individual swap transactions
- **Flash loan events**: Parsed `Vault_FlashLoan_event` logs from Fantom and Optimism for flash loan transactions
- **Transaction data**: Fantom and Optimism transaction records to identify user addresses (transaction senders)
- **Fee update events**: `Pool_SwapFeePercentageChanged_event` and `ProtocolFeesCollector_SwapFeePercentageChanged_event` logs for historical fee tier tracking
- **External data**: End-of-day token price feeds for USD conversion and token metadata including symbols and decimal places
- **Chain availability**: Configuration data defining which chains are active for specific time periods

## 3. Step-by-step calculation

### Component A: Trading volume extraction and processing
- **Purpose**: Extract and process all trading activity to calculate USD trading volumes
- **Logic**: Parse `Vault_Swap_event` logs from both Fantom (Beethoven V1) and Optimism (Balancer V2 deployment). Extract the pool address from the first 42 characters of the `poolId` field. Filter out pool join/exit transactions by excluding swaps where either `tokenIn` or `tokenOut` matches the extracted pool address, ensuring only actual token-to-token trades are included. For each valid swap, capture the `amountIn`, `amountOut`, token addresses, and user address from the transaction sender
- **Key fields**: `poolId` for pool identification, `tokenIn`/`tokenOut` for traded tokens, `amountIn`/`amountOut` for quantities, transaction `from_address` for user identification

### Component B: Token amount normalization and USD conversion  
- **Purpose**: Convert raw token amounts to standardized USD values for aggregation
- **Logic**: Join trade data with token metadata to get decimal places for each token. Divide raw token amounts by 10 raised to the token's decimal power to get actual token quantities. Join with end-of-day price feeds to get USD prices for both tokens in each trade. Calculate USD value for both token amounts, then take the lesser of the two values using the `least()` function to prevent price manipulation from affecting volume calculations. This approach ensures volume calculations are based on the more conservative price estimate
- **Key fields**: `decimals` from token metadata, `price_usd` from price feeds, normalized `token0_amount` and `token1_amount`

### Component C: Fee tier integration
- **Purpose**: Apply current fee tiers to trades for comprehensive volume tracking
- **Logic**: Join trades with fee tier update events based on chain, pool address, and transaction ordering. Use range matching where the trade ID falls between a fee update ID and the next fee update ID (or current if it's the latest). This assigns the correct fee tier that was active at the time of each trade. Apply the same logic for protocol-level fee changes
- **Key fields**: `fee_tier` from pool fee updates, `protocol_fee_tier` from protocol fee updates, `id` for temporal ordering

### Component D: Daily active user identification
- **Purpose**: Count unique users who performed any trading activity each day
- **Logic**: Extract user addresses from two sources: regular swap transactions (using transaction sender from `Vault_Swap_event` logs) and flash loan transactions (using transaction sender from `Vault_FlashLoan_event` logs). Truncate timestamps to daily boundaries and classify users as either "Trader" or "Flashloan Trader" based on activity type. Use HyperLogLog (HLL) data structure to efficiently count unique users across all activity types and chains while avoiding double-counting users who perform multiple transaction types
- **Key fields**: `user_address` from transaction records, `block_timestamp` truncated to day, `user_type` classification

### Component E: HLL aggregation for user counting
- **Purpose**: Efficiently aggregate unique user counts across multiple dimensions
- **Logic**: Create HyperLogLog sketches for user addresses grouped by timestamp, chain, user type, and product dimensions. Merge HLL sketches across different groupings to create various aggregation levels including project-level totals, chain breakdowns, and user type breakdowns. Extract the final unique user count from the merged HLL sketch for the project-level dimension ('project_dbt_tag') which provides total unique users across all chains and activity types
- **Key fields**: `hll` sketches for efficient unique counting, `dimensions` for aggregation level identification

### Final aggregation
- **Combining components**: Join daily trading volume totals with daily active user counts using timestamp as the join key. The trading volume represents the sum of all USD trading volumes across all pools and chains for each day, while user DAU represents the unique count of users who performed any trading activity that day
- **Currency conversion**: USD conversion occurs at the individual trade level using end-of-day price feeds, with the conservative approach of taking the lesser USD value between the two tokens in each swap
- **Time aggregation**: All data is aggregated to daily boundaries using timestamp truncation, with missing days filled with zeros for both volume and user metrics
- **Final calculation**: Divide total daily trading volume by daily active user count using safe division to handle edge cases where user count might be zero, resulting in the average trading volume per active user for each day

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

Average trading volume (per user)

Trading volume divided by daily active users.

BeetsBEETS

Average trading volume (per user)

Average trading volume (per user)

Competitive landscape