Liquidity providers deposit funds into Thena and stake their LP tokens to receive THE tokens (token incentives).

Thena is a non-custodial exchange protocol built on BNB Chain. Thena was founded by an anonymous team and launched in 2023.

THE tokenholders own and govern the protocol. They vote for pools where they wish to receive trading fees and external bribes from, while pools receive THE emissions in respect to their share of votes.

github

twitter

discord

etherscan

website

Exchanges (DEX)

Thena

# Thena Tradeable pairs Methodology

## 1. Overview

The tradeable pairs metric tracks the cumulative number of unique trading pairs available on the Thena decentralized exchange (DEX). This metric answers the question "How many different token pair combinations can users trade on Thena over time?" The calculation identifies when new trading pairs are created across multiple protocol versions and chains, then maintains a running total to show the growth of available trading options on the platform.

## 2. Data sources

The calculation uses several key data sources:

- **Thena protocol events**: Parsed blockchain events from multiple Thena protocol versions including `PairCreated` events from v1 PairFactory contracts and `Pool` events from v2/v3 AlgebraFactory contracts
- **Multi-chain coverage**: Events from BSC (Binance Smart Chain) and OpBNB networks across Thena v1, v2, and v3 deployments
- **Token metadata**: Token symbol and decimal information used to create readable pair names and validate token addresses

## 3. Step-by-step calculation

### Component A: Trading pair identification
- **Purpose**: Identify all unique trading pairs created across Thena protocol versions and chains
- **Logic**: Extract pair creation events from six different contract sources: Thena v1 `PairCreated` events on BSC and OpBNB, Thena v2 `Pool` events on BSC and OpBNB, and Thena v3 `Pool` and `CustomPool` events on BSC. Each event contains the newly created pair/pool contract address and the two token addresses that form the trading pair. The data is deduplicated by pair address to ensure each unique trading pair is counted only once regardless of how many creation events may exist.
- **Key fields**: `account_address` (the pair/pool contract address), `token0_address` and `token1_address` (the two tokens in the pair), `block_timestamp` (when the pair was created), `chain` and `version` identifiers

### Component B: Pair enrichment and timing
- **Purpose**: Enrich trading pairs with metadata and determine first appearance dates
- **Logic**: Join each trading pair with token metadata to retrieve token symbols and decimals for both tokens in the pair. Create readable pair names by concatenating the token symbols with a hyphen separator. Determine the first appearance date of each unique pair by finding the minimum block timestamp when that pair address first appeared across all events, truncated to daily boundaries.
- **Key fields**: `token0_decimals`, `token1_decimals`, `account_name` (formatted as "TOKEN0-TOKEN1"), first appearance timestamp per pair

### Component C: Daily pair counting
- **Purpose**: Count new trading pairs created each day
- **Logic**: Group the first appearances by day and chain, counting distinct pair addresses to determine how many new trading pairs became available on each specific date. This creates a time series of daily new pair additions across all supported chains and protocol versions.
- **Key fields**: `pair_count` (number of new pairs per day), daily timestamp boundaries, chain identifiers

### Component D: Gap filling
- **Purpose**: Ensure complete time series data with no missing dates
- **Logic**: Fill any gaps in the daily time series with zero values for days when no new trading pairs were created. This ensures a continuous daily series from the first pair creation to the present, with explicit zero counts for inactive days rather than missing data points.
- **Key fields**: Filled `pair_count` values with zeros for missing dates

### Final aggregation
- **Combining components**: The daily new pair counts are processed using a cumulative sum calculation to create running totals of total available trading pairs
- **Time aggregation**: Data is aggregated at daily boundaries, with the cumulative sum calculated chronologically within each chain partition to maintain accurate running totals
- **Final calculation**: The final tradeable pairs metric represents the cumulative sum of daily new pairs over time, partitioned by chain to maintain separate running totals for BSC and OpBNB networks. The standardization macro applies consistent schema formatting and ensures data quality with forward-filling strategies for any remaining gaps.

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

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

ThenaTHE

Archived

Tradeable pairs

Tradeable pairs

Competitive landscape

Chain breakdown