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 Average trading volume (per trade) Methodology

## 1. Overview

Trading volume average per trade count measures the average USD value traded per transaction on Thena DEX. This metric provides insight into the typical trade size on the platform by dividing total daily trading volume by the number of distinct trades. The calculation aggregates swap data from Thena V1, V2, and V3 protocols across BSC and OpBNB chains, applies fee calculations, converts amounts to USD using end-of-day price feeds, and computes the daily average trade size.

## 2. Data sources

The calculation uses several blockchain and external data sources:

- **Swap events**: Parsed `Swap` events from Thena V1 `Pair` contracts, V2 `AlgebraPool` contracts, and V3 `AlgebraPoolV2` contracts on BSC and OpBNB chains
- **Transaction records**: BSC and OpBNB transaction data containing user addresses and transaction metadata
- **Fee events**: `Fee` events from Thena AlgebraPool contracts that update trading fee percentages
- **Protocol fee events**: `CommunityFee` events from Thena contracts that set protocol fee percentages
- **Pair creation events**: `PairCreated` events from Thena PairFactory contracts and `Pool` events from AlgebraFactory contracts defining trading pairs
- **Token metadata**: Token contract information including decimal places and symbols
- **Price feeds**: End-of-day USD price feeds for all tokens traded on Thena

## 3. Step-by-step calculation

### Component A: Raw trade extraction
- **Purpose**: Extract swap transactions from all Thena protocol versions and chains
- **Logic**: Collect swap events from Thena V1 (calculating token amount changes from `amount0In/Out` and `amount1In/Out` fields), V2 (using direct `amount0` and `amount1` fields), and V3 (using amounts plus optional `overrideFee` field). Join with transaction records to identify user addresses initiating each swap. Filter for incremental processing based on block timestamps.
- **Key fields**: `block_timestamp`, `transaction_hash`, `log_index`, `account_address` (trading pair), `user_address`, `token0_amount`, `token1_amount`, optional `fee`

### Component B: Fee tier enrichment
- **Purpose**: Determine the trading fee percentage for each swap
- **Logic**: Join swap data with fee update events from `Fee` events to get the trading fee tier. For V3 swaps, extract fee information from the `overrideFee` field when available. Convert fee values from basis points by dividing by 10^6. Use the most recent fee tier for each trading pair when specific swap fee data is unavailable.
- **Key fields**: `fee_tier` (as decimal percentage), `block_number` for fee event matching

### Component C: Protocol fee calculation
- **Purpose**: Apply protocol fee percentages to determine the portion retained by the protocol
- **Logic**: Join with protocol fee update events from `CommunityFee` events, using forward-filling to populate missing values across daily boundaries. For V2 contracts, take the maximum of `communityFee0New` and `communityFee1New` fields divided by 10^3. For V3 contracts, use `communityFeeNew` divided by 10^3. Multiply trading fee tier by protocol fee tier to get the final protocol fee percentage.
- **Key fields**: `protocol_fee_tier`, calculated as `fee_tier * protocol_fee_tier`

### Component D: Trading pair metadata integration
- **Purpose**: Enrich swap data with token information and trading pair details
- **Logic**: Join with trading pair dimension data derived from pair creation events. Match swaps to trading pairs using contract address and chain. Retrieve token addresses, decimal places, and symbols for both tokens in each pair. Create trading pair names by concatenating token symbols.
- **Key fields**: `token0_address`, `token1_address`, `token0_decimals`, `token1_decimals`, `account_name`

### Component E: Amount normalization and USD conversion
- **Purpose**: Convert raw token amounts to standard decimal format and USD values
- **Logic**: Normalize token amounts by dividing absolute values by 10^(token_decimals) for each token. Join with end-of-day price feeds to get USD prices for both tokens on the trade date. Calculate USD values for both token amounts. Apply price manipulation filtering by taking the minimum USD value between the two tokens to prevent inflated volume from price discrepancies.
- **Key fields**: `token0_amount` (normalized), `token1_amount` (normalized), `trading_volume` (minimum USD value)

### Component F: Daily aggregation for trading volume
- **Purpose**: Sum total trading volume by day
- **Logic**: Group trades by day using timestamp truncation. Sum the `trading_volume` field (minimum USD values) across all trades. Maintain dimensional attributes including chain, business classification, and product version for proper metric categorization.
- **Key fields**: `timestamp` (daily), `trading_volume` (aggregated sum)

### Component G: Daily aggregation for trade count
- **Purpose**: Count distinct trades by day
- **Logic**: Group the same trade data by day and count distinct transaction hashes to get the number of unique trades. Use the same dimensional grouping as trading volume to ensure consistency between the two metrics.
- **Key fields**: `timestamp` (daily), `trade_count` (distinct transaction count)

### Final aggregation
- **Combining components**: Join daily trading volume totals with daily trade counts on timestamp to align the metrics by day
- **Currency conversion**: USD conversion occurs during the amount normalization step using end-of-day price feeds matched to trade dates
- **Time aggregation**: Both metrics use daily boundaries created by truncating timestamps to day level
- **Final calculation**: Divide total daily trading volume by daily trade count using safe division to handle days with zero trades, resulting in the average USD value per trade for each day

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

ThenaTHE

Archived

Average trading volume (per trade)

Average trading volume (per trade)

Competitive landscape