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 Trade count Methodology

## 1. Overview

The Thena trade count metric measures the daily number of unique trades executed across all Thena DEX versions (V1, V2, V3) on BSC and opBNB networks. This metric counts distinct transactions containing swap events, providing insight into trading activity and user engagement. The calculation aggregates swap transactions daily and applies a zero-filling strategy to ensure consistent time series data.

## 2. Data sources

The calculation relies on the following raw data sources:

- **Blockchain events**: Parsed `Swap` events from Thena V1 `Pair` contracts, Thena V2 `AlgebraPool` contracts, and Thena V3 `AlgebraPoolV2` contracts on BSC and opBNB networks
- **Transaction data**: BSC and opBNB transaction records containing trader addresses and transaction metadata
- **Trading pair data**: Factory creation events including `PairCreated` events from V1 `PairFactory` contracts, `Pool` events from V2 `AlgebraFactory` contracts, and `Pool`/`CustomPool` events from V3 `AlgebraFactoryV2` contracts
- **Fee structure data**: `Fee` events from V2/V3 `AlgebraPool` contracts and `CommunityFee` events for protocol fee tracking
- **External data**: Token metadata including symbols and decimal precision, and end-of-day token price feeds for USD conversion

## 3. Step-by-step calculation

### Component A: Raw trade extraction
- **Purpose**: Extract all swap events from Thena protocol versions across supported chains
- **Logic**: Parse `Swap` events from three protocol versions with different event structures. For V1, extract `amount0In`, `amount0Out`, `amount1In`, `amount1Out` fields and calculate net token changes by subtracting out-amounts from in-amounts. For V2, extract `amount0` and `amount1` fields directly. For V3, extract `amount0`, `amount1`, and `overrideFee` fields. Join each swap event with transaction data to obtain the trader address from the `from_address` field. Filter events using incremental processing based on block timestamps.
- **Key fields**: `transaction_hash`, `log_index`, `block_timestamp`, `account_address` (trading pair contract), `user_address` (trader), `token0_amount`, `token1_amount`, `fee`

### Component B: Fee tier integration
- **Purpose**: Apply current fee structures to each trade for accurate volume calculations
- **Logic**: Join trades with fee update events that occur at the block level. For V2/V3 protocols, use `Fee` events that set trading fees as basis points, converting to decimal by dividing by 1,000,000. For V1 trades or when fee events are unavailable, calculate fees directly from the `overrideFee` field. Additionally, join with protocol fee updates from `CommunityFee` events, taking the most recent protocol fee percentage for each trading pair on each day. Calculate final protocol fee as the product of trading fee and protocol fee percentage.
- **Key fields**: `fee_tier` (trading fee percentage), `protocol_fee_tier` (protocol's share of fees)

### Component C: Trading pair enrichment
- **Purpose**: Map trading pair contracts to their underlying tokens and metadata
- **Logic**: Join trades with trading pair dimension data derived from factory creation events. Extract token addresses for both sides of each pair along with their decimal precision and symbols. Create human-readable trading pair names by concatenating token symbols with a hyphen separator. This mapping enables proper token amount normalization and price lookups.
- **Key fields**: `token0_address`, `token1_address`, `token0_decimals`, `token1_decimals`, `account_name`

### Component D: Volume calculation and validation
- **Purpose**: Convert raw token amounts to USD values with manipulation protection
- **Logic**: Normalize token amounts by dividing by 10 raised to the token's decimal precision. Join with end-of-day price feeds for both tokens in each trading pair. Calculate USD values by multiplying normalized amounts by respective token prices. Apply price manipulation filtering by taking the minimum USD value between the two tokens in each swap, ensuring trades are valued at the lower of the two calculated amounts. This prevents artificially inflated volumes from price discrepancies or manipulation attempts.
- **Key fields**: `trading_volume` (USD value using minimum of token0/token1 calculations)

### Final aggregation
- **Combining components**: All trade data flows through the volume calculation pipeline, but the final trade count metric extracts only the essential fields needed for counting: `timestamp`, `transaction_hash`, `log_index`, and categorization fields (`chain`, `market_sector_id`, `business_segment_id`, `product_id`)
- **Currency conversion**: Not applicable for trade counting, though underlying volume calculations use end-of-day USD prices
- **Time aggregation**: Truncate all trade timestamps to daily boundaries using day-level timestamp truncation. Group trades by day along with dimensional attributes (chain, business categories, product version)
- **Final calculation**: Count distinct transaction hashes within each day and dimensional grouping. Apply the `finalize_metric_trade_count` macro with a zero-filling strategy to ensure consistent time series data, filling gaps with zero values for days without trades. Apply chain availability filtering to exclude data from unsupported network periods.

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

Number of trades executed on a decentralized exchange.

ThenaTHE

Archived

Trade count

Trade count

Competitive landscape

Chain breakdown