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 Revenue Methodology

## 1. Overview

Thena revenue represents the total USD value of fees and incentives captured by the Thena decentralized exchange across multiple versions (v1, v2, v3) and chains (BSC, opBNB). The metric combines four distinct revenue streams: fee claims from liquidity gauges, calculated NFT and referral fees from trading volumes, protocol fees, and voting incentives. The calculation applies different rate structures for v1 versus v2/v3, with v1 including referral fees and all versions subject to time-based NFT rate changes.

## 2. Data sources

**Blockchain events**: Parsed `Swap` events from Thena v1 pairs, v2 Algebra pools, and v3 Algebra pools across BSC and opBNB networks; parsed `Claim` events from v1 trading pairs; parsed fee update events (`Fee`, `CommunityFee`) from v2 and v3 pools

**Transaction data**: BSC and opBNB transaction records providing user addresses and transaction context

**Governance events**: Parsed reward payment events from external bribes, internal bribes, and voting incentive contracts

**Pair creation events**: Parsed trading pair and pool creation events from factory contracts establishing token pair relationships

**Gauge creation events**: Parsed gauge creation events linking trading pairs to fee collection addresses

**External data**: End-of-day token price feeds for USD conversion, token metadata including decimal precision and symbols

## 3. Step-by-step calculation

### Component A: Fee claims from gauges
- **Purpose**: Captures fees actually claimed from liquidity incentive gauges
- **Logic**: Extract daily `Claim` events from v1 trading pairs on BSC and opBNB, aggregate `amount0` and `amount1` values by day and trading pair, join with trading pair metadata to identify token addresses and decimal precision, correct raw token amounts by dividing by 10^decimals, convert both token amounts to USD using end-of-day price feeds, sum total USD value across both tokens
- **Key fields**: `amount0` and `amount1` representing claimed fee amounts, `fee_collector_address` linking to gauge addresses, `token0_address` and `token1_address` from pair metadata

### Component B: NFT and referral fees from trading volumes  
- **Purpose**: Calculates theoretical fees based on trading volumes and dynamic rate structures
- **Logic**: Extract swap events from all versions and chains, join with dynamic fee tier updates to get current fee percentage per trading pair and block, join with protocol fee updates to get protocol fee percentage, calculate trading volume by correcting token amounts for decimals and taking minimum USD value between token0 and token1 to prevent manipulation, apply version-specific formulas - v1 uses `volume * (fee_tier - protocol_fee_tier) * [(1 - referral_rate) * nft_rate + referral_rate]` where referral_rate is 0.12, v2 and v3 use `volume * (fee_tier - protocol_fee_tier) * nft_rate`, apply time-based NFT rate change from 0.3 to 0.22 after February 27, 2023
- **Key fields**: `amount0` and `amount1` from swap events, `fee_tier` from fee updates, `protocol_fee_tier` from community fee updates, calculated `trading_volume` in USD

### Component C: Protocol fees
- **Purpose**: Captures protocol's share of trading fees across all versions
- **Logic**: Use same trading volume calculation as component B, multiply by `protocol_fee_tier` which represents the protocol's percentage of total trading fees, apply across all trading pairs and versions without version-specific adjustments
- **Key fields**: Calculated `trading_volume` and `protocol_fee_tier`

### Component D: Voting incentives
- **Purpose**: Captures governance rewards paid to voters and participants
- **Logic**: Extract reward payment events from external bribe, internal bribe, and voting incentive contracts, correct raw token amounts using decimal metadata, convert to USD using end-of-day price feeds, aggregate by day and account
- **Key fields**: `reward` amounts, `rewardsToken` addresses for price lookups

### Final aggregation
- **Combining components**: Union all four revenue components with consistent timestamp, chain, and business classification fields, each component tagged with distinct `revenue_type` labels
- **Currency conversion**: All USD conversions use end-of-day price feeds with left joins, missing prices result in zero revenue for that component
- **Time aggregation**: All components aggregate to daily boundaries using `timestamp_trunc` to day level
- **Final calculation**: Sum all revenue components by day, chain, and business dimensions, apply chain availability filters and finalization macro for schema validation and gap filling with zeros where specified

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

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

ThenaTHE

Archived

Revenue

Revenue

Competitive landscape

Chain breakdown