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 (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for Beethoven X measures the count of unique user addresses that interacted with Beethoven X liquidity pools within any 30-day rolling period. This metric captures both regular traders who execute swaps and users who take flash loans from the protocol. The calculation uses HyperLogLog data structures to efficiently estimate unique user counts across multiple dimensional breakdowns while maintaining accuracy for large user sets.

## 2. Data sources

- **Blockchain events**: Parsed `Vault_Swap_event` logs from Beethoven V1 Fantom contracts and Balancer V2 Optimism contracts (co-managed by Beethoven X)
- **Flash loan events**: Parsed `Vault_FlashLoan_event` logs from the same contract sources
- **Transaction data**: Fantom and Optimism transaction records containing originating user addresses
- **Chain coverage**: Fantom (Beethoven V1) and Optimism (Balancer V2 co-deployment)

## 3. Step-by-step calculation

### Component A: Daily active user identification

- **Purpose**: Identify unique users who interact with Beethoven X pools each day, categorized by activity type
- **Logic**: Extract user addresses from blockchain transactions that triggered swap or flash loan events. For swap events, filter out pool management operations (joins/exits) by excluding transactions where either `tokenIn` or `tokenOut` matches the pool contract address (extracted from the first 42 characters of `poolId`). User addresses come from the `from_address` field of the underlying transaction records. Two user types are tracked: 'Trader' for users executing swaps and 'Flashloan Trader' for users taking flash loans
- **Key fields**: `user_address` (transaction originator), `block_timestamp` (truncated to day), `chain` (Fantom or Optimism), `user_type` (Trader or Flashloan Trader)

### Component B: HyperLogLog initialization and daily aggregation

- **Purpose**: Convert daily user lists into efficient probabilistic data structures for set operations
- **Logic**: Group daily user addresses by timestamp, chain, user type, and product dimensions. Initialize HyperLogLog sketches with 15-bit precision for each group to enable approximate counting of unique users. This approach allows efficient merging of user sets across different time periods without storing individual user addresses
- **Key fields**: `timestamp` (daily), `hll` (HyperLogLog sketch), `chain_id`, `user_type`, `product_id`

### Component C: Rolling window construction

- **Purpose**: Create 30-day rolling windows for each day to calculate monthly active users
- **Logic**: Generate a complete date spine covering all days in the analysis period. For each day in the spine, create associations with the 30 preceding days (including the current day) using timestamp array generation. This creates a cross-join structure where each target date is linked to all daily HLL sketches from its 30-day lookback window. The window includes the target date and the 29 preceding days
- **Key fields**: `timestamp` (target date), `joinday` (days within the 30-day window)

### Component D: Dimensional MAU calculation

- **Purpose**: Calculate unique user counts across different dimensional breakdowns
- **Logic**: For each dimensional breakdown, merge HLL sketches within 30-day windows and extract cardinality estimates. Four breakdowns are calculated: project-level (all users combined), chain-level (by blockchain), user-type-level (by activity type), and product-level (by product). HLL merging operations combine sketches from multiple days within each window, then cardinality extraction provides the estimated unique user count
- **Key fields**: `dimensions` (breakdown type), `user_mau` (estimated unique user count), dimension-specific fields (`chain_id`, `user_type`, `product_id`)

### Final aggregation

- **Combining components**: Union all dimensional breakdowns into a single result set, with null values for non-applicable dimension fields in each breakdown
- **Time aggregation**: Daily timestamps represent the end date of each 30-day rolling window
- **Final calculation**: Each row contains the estimated count of unique users who were active within the 30-day period ending on the specified timestamp, broken down by the specified dimension
- **Quality controls**: Missing days in the time series are filled with zero values to ensure complete temporal coverage

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

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

BeetsBEETS

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown