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 Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) measures the number of unique users who interact with Beethoven X protocol over a rolling 7-day period. This metric captures both trading activity and flashloan usage across Beethoven X's deployments on Fantom and Optimism networks. The calculation uses HyperLogLog data structures for efficient distinct user counting and provides breakdowns across multiple dimensions including chain, user type, and product categories.

## 2. Data sources

- **Blockchain events**: Parsed `Vault_Swap` events from Beethoven X Fantom contracts and Balancer Optimism contracts (since Balancer co-manages the Beethoven X Optimism deployment)
- **Flashloan events**: Parsed `Vault_FlashLoan` events from the same contract deployments
- **Transaction data**: Fantom and Optimism transaction records to identify originating user addresses for each activity
- **External data**: Chain availability filters to ensure data quality across supported networks

## 3. Step-by-step calculation

### Component A: Trading activity extraction
- **Purpose**: Identifies users who performed token swaps on Beethoven X AMM pools
- **Logic**: Extracts `Vault_Swap` events from Beethoven X Fantom (v1) and Balancer Optimism (v2) contracts. Filters out pool joins and exits by excluding swaps where `tokenIn` or `tokenOut` addresses equal the pool address (derived from the first 42 characters of `poolId`). Joins swap events with transaction records to obtain the originating `user_address` from the `from_address` field. Creates unique identifiers using block number and log index concatenation
- **Key fields**: `transaction_hash`, `user_address`, `tokenIn`, `tokenOut`, `amountIn`, `amountOut`, `block_timestamp`, `poolId`

### Component B: Flashloan activity extraction  
- **Purpose**: Identifies users who utilized flashloan functionality
- **Logic**: Extracts `Vault_FlashLoan` events from the same contract deployments. Joins with transaction records to identify the originating user address. Captures flashloan amounts and associated fees
- **Key fields**: `transaction_hash`, `user_address`, `token`, `amount`, `feeAmount`, `block_timestamp`

### Component C: Daily active user calculation
- **Purpose**: Aggregates both activity types into daily distinct user counts
- **Logic**: Combines trading and flashloan users with distinct user type labels ('Trader' for swap users, 'Flashloan Trader' for flashloan users). Truncates `block_timestamp` to daily granularity using `timestamp_trunc`. Groups by day, chain, user type, and other dimensional attributes while preserving individual `user_address` values for later distinct counting
- **Key fields**: `timestamp` (daily), `chain`, `user_type`, `user_address`, `market_sector_id`, `business_segment_id`, `product_id`

### Component D: HyperLogLog initialization
- **Purpose**: Converts daily user data into efficient data structures for distinct counting
- **Logic**: Initializes HyperLogLog structures for each daily user set using `hll_count.init()` with precision parameter 15. Groups by timestamp, chain, user type, and product dimensions to create HLL sketches that can be efficiently merged for window calculations
- **Key fields**: `hll` (HyperLogLog structure), dimensional grouping fields

### Component E: Rolling window generation
- **Purpose**: Creates 7-day rolling windows for WAU calculation
- **Logic**: Generates a complete date spine covering the full time range to handle missing days. For each date in the spine, creates join keys for the current day and the previous 6 days using `generate_timestamp_array` with 1-day intervals. This produces a cartesian product where each target date is associated with its 7-day lookback period
- **Key fields**: `timestamp` (target date), `joinday` (dates within the 7-day window)

### Component F: Window aggregation
- **Purpose**: Merges HyperLogLog structures within each 7-day window
- **Logic**: Joins the window definitions with the daily HLL data on matching dates. For each target date and dimensional combination, merges all HLL structures from the 7-day period using `hll_count.merge_partial()`. Extracts the final distinct count using `hll_count.extract()` to produce the WAU value
- **Key fields**: `user_wau` (distinct user count), dimensional breakdowns

### Component G: Multi-dimensional breakdowns
- **Purpose**: Provides WAU metrics across different analytical dimensions
- **Logic**: Creates four separate dimensional views by grouping the window-aggregated data differently. Project-level aggregation combines all chains and user types. Chain-level breakdown maintains chain separation but combines user types. User-type breakdown separates traders from flashloan users. Product-level breakdown maintains product category separation. Null values are used for non-applicable dimensions in each view
- **Key fields**: `dimensions` (breakdown type), `chain_id`, `user_type`, `product_id`, `user_wau`

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using `UNION ALL` to create a single result set with multiple analytical perspectives
- **Time boundaries**: Daily boundary logic uses `timestamp_trunc` for consistent daily aggregation across time zones
- **Missing day handling**: The `finalize_metric_user_wau` macro applies a zero-fill strategy to populate missing days with zero values, ensuring complete time series data
- **Final calculation**: The final WAU value represents the distinct count of users who performed any qualifying activity (trading or flashloan usage) within the rolling 7-day period, calculated using probabilistic HyperLogLog structures for computational efficiency

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

Unique revenue-generating users over a rolling 7-day window.

BeetsBEETS

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown