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 Supply-side fees Methodology

## 1. Overview

Supply-side fees represent the trading fees that flow to liquidity providers (LPs) on the Thena decentralized exchange. This metric captures fees earned by LPs who provide liquidity to trading pairs, excluding fees allocated to the protocol, NFT holders, referral programs, and liquidity mining incentives. The calculation varies across Thena's three versions: v1 uses direct fee claim events, while v2 and v3 calculate supply-side fees by subtracting protocol, NFT, and referral fees from total trading fees.

## 2. Data sources

- **Blockchain events**: Parsed `Pair_Claim_event` logs from Thena v1 on BSC and opBNB chains, capturing direct fee collections by liquidity providers
- **Trading events**: Parsed `Pair_Swap_event` logs from Thena v1, `AlgebraPool_Swap_event` logs from Thena v2, and `AlgebraPoolV2_Swap_event` logs from Thena v3 across BSC and opBNB chains
- **Fee configuration events**: Parsed `AlgebraPool_Fee_event` and `AlgebraPoolV2_Fee_event` logs that track dynamic trading fee rates for v2 and v3 pools
- **Protocol fee events**: Parsed `AlgebraPool_CommunityFee_event` and `AlgebraPoolV2_CommunityFee_event` logs that track protocol fee rates for revenue sharing
- **Factory events**: Parsed `PairFactory_PairCreated_event`, `AlgebraFactory_Pool_event`, and `AlgebraFactoryV2_Pool_event` logs to identify trading pairs and their token compositions
- **Governance events**: Parsed `Voter_GaugeCreated_event` and `GaugeFactoryV2_CreateGauge_event` logs to identify liquidity incentive distribution accounts
- **Transaction data**: BSC and opBNB transaction records to identify user addresses for trading activity
- **External data**: End-of-day token price feeds for USD conversion and token metadata containing decimal precision and symbol information

## 3. Step-by-step calculation

### Component A: V1 direct fee claims
- **Purpose**: Calculates fees claimed directly by v1 liquidity providers who opted out of THE token incentives
- **Logic**: Processes `Pair_Claim_event` logs from BSC and opBNB Thena v1 contracts. Excludes fee claims made by liquidity incentive accounts identified through gauge creation events. For each claim event, extracts `amount0` and `amount1` values representing fees in both tokens of the trading pair. Aggregates claims by day, trading pair, and fee collector address. Corrects token amounts by dividing by token-specific decimal precision. Converts both token amounts to USD using end-of-day price feeds and sums them to get total fee value per claim.
- **Key fields**: `fee_collector_address` for the LP claiming fees, `amount0` and `amount1` for token quantities claimed, `token0_address` and `token1_address` for the trading pair tokens

### Component B: V2/V3 calculated trading fees
- **Purpose**: Calculates total trading fees generated from v2 and v3 trading activity before fee sharing deductions
- **Logic**: Processes swap events from `AlgebraPool_Swap_event` (v2) and `AlgebraPoolV2_Swap_event` (v3) across BSC and opBNB. Extracts `amount0` and `amount1` representing token quantities exchanged in each swap. Joins swap data with fee tier information from `Fee_event` logs, using block-level matching to apply the correct fee percentage. For v3, uses override fees from individual swap events when available. Aggregates trading volume by day and trading pair, applying decimal corrections to token amounts. Calculates USD trading volume using the lesser value between the two tokens to prevent price manipulation. Multiplies trading volume by `fee_tier` percentage to determine total fees generated.
- **Key fields**: `amount0` and `amount1` for swap quantities, `fee` for v3 override fees, `fee_tier` for the trading fee percentage

### Component C: NFT fee deductions
- **Purpose**: Subtracts the portion of trading fees allocated to NFT holders in the v2 and v3 fee sharing model
- **Logic**: Uses the same trading volume data as Component B but applies NFT rate percentages to the non-protocol portion of fees. Calculates non-protocol fees by subtracting protocol fees from total fees using the formula `(fee_tier - protocol_fee_tier) * trading_volume`. Applies time-based NFT rates: 30% before February 27, 2023, and 22% afterward. Creates negative fee values to subtract from supply-side calculations.
- **Key fields**: `fee_tier` minus `protocol_fee_tier` for the non-protocol fee base, time-based NFT rate percentages

### Component D: Protocol fee deductions  
- **Purpose**: Subtracts protocol fees that go to the Thena treasury rather than liquidity providers
- **Logic**: Processes `CommunityFee_event` logs to track protocol fee rate changes over time. For v2, takes the maximum of `communityFee0New` and `communityFee1New` converted from basis points. For v3, uses `communityFeeNew` directly. Forward-fills missing protocol fee rates to ensure continuous coverage. Multiplies trading volume by `protocol_fee_tier` to calculate protocol fee amounts and creates negative values for deduction.
- **Key fields**: `communityFee0New`, `communityFee1New`, and `communityFeeNew` for protocol fee rates, `protocol_fee_tier` for the calculated percentage

### Final aggregation
- **Combining components**: Unions all fee components (positive fees from v1 claims and v2/v3 trading, negative deductions for NFT and protocol fees) into a single dataset aggregated by day, chain, and business classification
- **Currency conversion**: Converts all token amounts to USD using end-of-day price feeds matched by timestamp, token address, and chain
- **Time aggregation**: Groups all fee calculations by daily timestamps using `timestamp_trunc` to day boundaries
- **Final calculation**: Sums all positive and negative fee components to arrive at net supply-side fees, applies chain availability filters, and validates data completeness using the `finalize_metric_fees_supply_side` macro with zero-fill strategy for missing days

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

Portion of fees distributed to service providers or supply-side participants.

ThenaTHE

Archived

Supply-side fees

Supply-side fees

Competitive landscape

Chain breakdown