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 Tradeable pairs Methodology

## 1. Overview

The tradeable pairs metric measures the cumulative number of unique trading pairs available on Beethoven X, segmented by liquidity cohorts. This metric tracks the growth of trading opportunities over time by counting pools that enable token-to-token swaps. Beethoven X operates on Fantom (native deployment) and Optimism (co-managed with Balancer), using various pool types including weighted pools, stable pools, and linear pools. The metric categorizes pairs by their total liquidity value to provide insights into the quality and depth of available trading pairs.

## 2. Data sources

The calculation relies on the following raw data sources:

- **Pool creation events**: Parsed `PoolCreated` events from multiple factory contracts across Fantom and Optimism chains, including WeightedPoolFactory, ComposableStablePoolFactory, StablePoolFactory, various LinearPoolFactory implementations (Yearn, ERC4626, Aave, Boo, Reaper, Tarot), LiquidityBootstrappingPoolFactory, and ManagedPoolFactory variants
- **Pool reserve data**: Hourly snapshots of token reserves held in each pool across both Fantom (Beethoven V1) and Optimism (Balancer V2) deployments
- **Token price feeds**: End-of-day USD price data for converting token reserves to dollar values
- **Token metadata**: Token symbols and decimal specifications for proper unit conversion

## 3. Step-by-step calculation

### Component A: Pool identification
- **Purpose**: Identifies all unique trading pairs and their first appearance dates
- **Logic**: Extracts pool addresses from `PoolCreated` events across multiple factory contracts on Fantom (Beethoven V1) and Optimism (Balancer V2). Events are sourced from various factory types including weighted pools, composable stable pools, standard stable pools, linear pools for different yield protocols, liquidity bootstrapping pools, and managed pools. Each pool creation event provides the `pool` address and `block_timestamp`. The logic determines the earliest appearance date for each unique pool address by chain, creating a comprehensive registry of all trading pairs
- **Key fields**: `block_timestamp` for creation timing, `pool` address as unique identifier, `chain` for network classification, `transaction_hash` and `log_index` for event uniqueness

### Component B: Daily pair counting
- **Purpose**: Aggregates new trading pairs created each day
- **Logic**: Groups pool first appearances by daily timestamps using timestamp truncation to day boundaries. Counts distinct pool addresses for each day and chain combination. This creates a time series showing the daily rate of new trading pair creation across the platform
- **Key fields**: `timestamp` truncated to day level, `chain` for network segmentation, `account_address` as pool identifier, `pair_count` as daily new pairs

### Component C: Gap filling
- **Purpose**: Ensures continuous daily time series with zero values for inactive days
- **Logic**: Applies zero-filling logic to create complete daily time series without gaps. Days with no new pool creations receive zero values rather than missing entries. This ensures consistent data structure for cumulative calculations and prevents issues with incomplete time series
- **Key fields**: `timestamp` as continuous daily series, `chain` as partition dimension, `pair_count` with zeros for missing days

### Component D: Liquidity cohort classification
- **Purpose**: Categories active pools by their total liquidity value
- **Logic**: Retrieves pool reserve data from hourly snapshots and converts token amounts to USD using end-of-day price feeds. Calculates total reserve value for each pool by summing all token reserves in USD. Assigns pools to liquidity cohorts using fixed thresholds: greater than $1M, $500K-$1M, $100K-$500K, $25K-$100K, $5K-$25K, and less than $5K. Pool reserves are sourced from both Beethoven V1 on Fantom and Balancer V2 on Optimism (co-managed deployment)
- **Key fields**: `timestamp` for daily snapshots, `account_address` as pool identifier, `reserve` in USD value, `liquidity_cohort` as categorical assignment

### Final aggregation
- **Combining components**: Merges daily new pair counts with liquidity cohort data to create comprehensive tradeable pairs metrics. The base calculation uses cumulative sums of daily new pairs partitioned by chain. Liquidity cohorts are calculated separately by counting active pools in each tier on each day
- **Currency conversion**: Token reserves are converted to USD using end-of-day price feeds via the `convert_usd` function, ensuring consistent valuation across different tokens and chains
- **Time aggregation**: Data is aggregated to daily boundaries with timestamp truncation. Pool reserves use the last available hourly snapshot for each day (hour 0 of the next day, then shifted back one day)
- **Final calculation**: The metric combines three components: 1) Cumulative count of all new pairs over time for the base "<$5k" category, 2) Daily count of pools in each specific liquidity cohort, and 3) Negative adjustment to remove double-counting by subtracting pools that appear in higher liquidity tiers from the base category. The `finalize_metric_tradeable_pairs` macro standardizes the final output schema and applies data validation

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

Number of unique token pairs available for trading on the exchange.

BeetsBEETS

Tradeable pairs

Tradeable pairs

Competitive landscape

Chain breakdown