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 revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) measures the daily revenue generated per active user on the Beethoven X protocol. This metric is calculated by dividing daily protocol revenue by the number of daily active users, providing insight into user monetization effectiveness. The calculation covers both trading revenue from swap fees and flashloan revenue, across Beethoven X deployments on Fantom and the Balancer-managed deployment on Optimism.

## 2. Data sources

The calculation relies on several categories of blockchain data:

- **Protocol event logs**: Parsed `Vault_PoolBalanceChanged_event` logs from Beethoven V1 on Fantom and Balancer V2 on Optimism, capturing protocol fee collections in various tokens
- **Trading event logs**: Parsed `Vault_Swap_event` logs from both deployments, capturing user trading activity  
- **Flashloan event logs**: Parsed `Vault_FlashLoan_event` logs from both deployments, capturing flashloan user activity and associated fees
- **Pool registration logs**: Parsed `Vault_PoolRegistered_event` logs used to identify pool tokens (BPT tokens)
- **Fee configuration logs**: Parsed `ProtocolFeesCollector_SwapFeePercentageChanged_event` logs tracking protocol fee tier changes over time
- **Token transfer data**: On-chain token transfer records for BPT tokens transferred to protocol fee collectors
- **Transaction data**: Fantom and Optimism transaction records to identify user addresses initiating protocol interactions
- **External data**: End-of-day token price feeds for USD conversion and token metadata including decimals and symbols

## 3. Step-by-step calculation

### Component A: Protocol fee collection
- **Purpose**: Captures all protocol fees collected by Beethoven X from trading and pool operations
- **Logic**: Extracts fees from `Vault_PoolBalanceChanged_event` logs where protocol fees are collected in various tokens. The events contain arrays of token addresses and corresponding protocol fee amounts that are unnested and paired together. Additionally captures BPT token transfers from the null address to protocol fee collector addresses, representing protocol fees collected in pool tokens. Excludes zero amounts and aggregates fees by transaction to avoid double-counting
- **Key fields**: `poolid` (pool identifier), `tokens` (array of token addresses), `protocolfeeamounts` (array of fee amounts), `block_timestamp`, `transaction_hash`

### Component B: Flashloan fee collection  
- **Purpose**: Captures fees generated from flashloan operations
- **Logic**: Extracts flashloan events from `Vault_FlashLoan_event` logs, including the loan amount and fee charged. Currently, protocol fee tiers for flashloans are set to zero, meaning no protocol revenue is generated from flashloans, but the infrastructure tracks these events for future fee implementation
- **Key fields**: `token` (flashloan token), `amount` (loan amount), `feeAmount` (fee charged), `user_address` (flashloan user)

### Component C: Fee tier application
- **Purpose**: Determines what portion of collected fees becomes protocol revenue
- **Logic**: Uses `ProtocolFeesCollector_SwapFeePercentageChanged_event` logs to track protocol fee tier changes over time. Each fee collection event is matched with the applicable fee tier based on event timing. Fee tiers are stored as 18-decimal values and converted to decimal percentages. Protocol revenue equals total fees multiplied by the protocol fee tier
- **Key fields**: `newSwapFeePercentage` (fee tier as 18-decimal integer), `block_timestamp` (when tier change occurred)

### Component D: Trading user identification
- **Purpose**: Identifies unique users who traded on the protocol each day  
- **Logic**: Extracts user addresses from `Vault_Swap_event` logs, filtering out pool join and exit transactions by excluding swaps where either token matches the pool's BPT token address. Links swap events to transaction records to identify the initiating user address. Aggregates users by day using timestamp truncation
- **Key fields**: `tokenIn`, `tokenOut` (swap tokens), `poolid` (identifies pool BPT token), `user_address` (transaction initiator)

### Component E: Flashloan user identification
- **Purpose**: Identifies unique users who used flashloans each day
- **Logic**: Extracts user addresses from `Vault_FlashLoan_event` logs and links them to transaction records to identify initiating users. Users are classified as "Flashloan Trader" type to distinguish from regular traders
- **Key fields**: `user_address` (flashloan initiator), `block_timestamp`

### Component F: User aggregation with HyperLogLog
- **Purpose**: Counts distinct active users while avoiding double-counting users who both trade and use flashloans
- **Logic**: Combines trading users and flashloan users into a unified dataset, then applies HyperLogLog sketches to count distinct users per day. HLL allows approximate distinct counting that handles users appearing in multiple activity types. Breaks down user counts by dimensions including chain, user type, and product while maintaining overall distinct counts
- **Key fields**: `user_dau` (user identifier for distinct counting), `timestamp` (daily boundary), `chain`, `user_type`

### Final aggregation
- **Combining components**: Daily protocol revenue is calculated by summing all fee collections (protocol fees and flashloan fees) multiplied by their respective protocol fee tiers. Daily active users are counted using HLL aggregation across all user activity types
- **Currency conversion**: All token amounts are first scaled by token decimals (dividing by 10^decimals), then converted to USD using end-of-day price feeds matched by date, token address, and chain
- **Time aggregation**: Both revenue and user data are truncated to daily boundaries using timestamp truncation. Missing days are filled with zeros to ensure complete time series
- **Final calculation**: ARPU equals daily protocol revenue in USD divided by daily active user count. The result shows average revenue generated per user per day, with zero values for days with no users or revenue

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

BeetsBEETS

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape