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

## 1. Overview

The Thena expenses metric measures the total daily operating costs incurred by the Thena decentralized exchange protocol. This includes both operating expenses (derived from trading fee allocations for referral rewards and lottery operations) and token incentives (liquidity mining rewards distributed to users). The metric answers the business question: "What are Thena's daily operational expenditures across all expense categories?" The calculation combines percentage-based operating expense allocations with direct token incentive distributions, converting all amounts to USD for standardized reporting.

## 2. Data sources

The calculation utilizes several key blockchain data sources and external feeds:

- **Trading fee events**: Parsed `Pair_Fees_event` logs from BSC and opBNB chains capturing fee collection in both tokens of trading pairs
- **Liquidity incentive events**: Parsed `Gauge_Harvest_event` and `GaugeV2_Harvest_event` logs from BSC capturing THE token distributions to liquidity providers
- **Factory events**: Parsed pool and pair creation events including `PairFactory_PairCreated_event`, `AlgebraFactory_Pool_event`, `AlgebraFactoryV2_Pool_event`, and `AlgebraFactoryV2_CustomPool_event` from BSC and opBNB
- **Gauge creation events**: Parsed `Voter_GaugeCreated_event`, `VoterV3_GaugeCreated_event`, and `GaugeFactoryV2_CreateGauge_event` logs from BSC establishing relationships between incentive gauges and trading pools
- **End-of-day price feeds**: Token price data for USD conversion of all fee and incentive amounts
- **Token metadata**: Token symbols and decimal configurations for proper amount calculations and pair naming

## 3. Step-by-step calculation

### Component A: Operating expenses from trading fees

- **Purpose**: Calculate operating expenses as a fixed percentage of trading fee revenue, representing costs for referral rewards and lottery operations
- **Logic**: Extract trading fee events from `Pair_Fees_event` logs containing `amount0` and `amount1` fields for both tokens in each trading pair. Join with factory-created trading pair metadata to obtain token addresses, decimals, and symbols. Aggregate fees daily by truncating block timestamps to day boundaries. Correct token decimals by dividing raw amounts by 10 raised to the token's decimal count. Convert both token amounts to USD using end-of-day price feeds matched by timestamp, token address, and chain. Sum the USD values of both tokens per trading pair per day. Apply a hardcoded 12% rate to the total USD trading fees to derive operating expenses, representing the maximum referral fee split used for lottery operations when referral rewards go unclaimed.
- **Key fields**: `block_timestamp` for daily aggregation, `token0_amount` and `token1_amount` from fee events, `token0_decimals` and `token1_decimals` from pair metadata, `price_usd` from price feeds, calculated `fees` as the sum of converted amounts

### Component B: Token incentives from liquidity mining

- **Purpose**: Calculate token incentive expenses from THE token distributions to liquidity providers through the gauge system
- **Logic**: Extract liquidity incentive distribution events from various gauge harvest event logs (`Gauge_Harvest_event`, `GaugeV2_Harvest_event`) containing THE token `reward` amounts distributed to users. The THE token address is hardcoded as `0xf4c8e32eadec4bfe97e0f595add0f4450a863a11`. Join harvest events with gauge-to-pool mapping data from gauge creation events to link incentive distributions back to specific trading pools. Further join with trading pair metadata to obtain pool names and token information for proper attribution. Aggregate incentive amounts daily by truncating block timestamps. Convert THE token amounts to USD using end-of-day price feeds and apply decimal correction based on THE token metadata. Sum all incentive distributions per day per trading pool.
- **Key fields**: `block_timestamp` for daily aggregation, `reward` amounts from harvest events, `account_address` linking gauges to pools, THE `token_address` for price lookups, `amount` after decimal correction and USD conversion

### Final aggregation

- **Combining components**: Union the daily operating expense amounts with daily token incentive amounts using UNION ALL operation, treating both as expense line items with consistent schema including timestamp, chain, and product identifiers
- **Currency conversion**: All amounts converted to USD using end-of-day token price feeds matched by timestamp granularity (day), token address, and blockchain network
- **Time aggregation**: Daily boundaries established by truncating blockchain event timestamps to day level, ensuring consistent reporting periods across both expense types
- **Final calculation**: Sum all expense amounts per day per chain per product, with the `finalize_metric_expenses` macro applying standardized formatting, zero-filling for missing data points, and chain availability filtering to ensure complete time series data

## Critical guidelines

- **No SQL code**: Use natural language explanations only. Do not include SQL snippets, code blocks, or pseudo-SQL
- **Use backticks for technical references**: Always wrap event names, contract addresses, function signatures, and field names in backticks (e.g., `Swap` event, `0x1234...abcd` address, `amount` field)
- **Clean up field names**: Remove internal technical prefixes from field names when referencing them. For example, if you see `value`, `balanceIncrease`, or `amount` in the SQL, reference them as `value`, `balanceIncrease`, and `amount` in your explanations. The `in_` prefix is an internal implementation detail used to avoid SQL variable name clashes and should not appear in the methodology documentation.
- **Use sentence case**: Use sentence case for all headings and subheadings (e.g., "Component A: Balance calculation" not "Component A: Balance Calculation"). Only capitalize proper nouns, acronyms (like USD, ERC20), and the first word of each heading.
- **Describe data sources naturally**: Avoid listing specific table names like ethereum event logs or `schema.table_name`. Instead, describe the data source type naturally (e.g., "Ethereum event logs", "end-of-day token price feeds", "parsed `Transfer` events from Ethereum, Base, and Arbitrum"). Focus on what the data represents rather than where it's stored.
- **Focus on data types, not table names**: Describe what data is being used (e.g., "parsed `Transfer` events from Ethereum and Arbitrum", "end-of-day token price feeds", "transaction traces") rather than specific table names. The goal is to explain the nature and source of the data, not the database schema.
- **Trace complete lineage**: Follow the data flow from raw blockchain data to final metric
- **Explain business logic**: Clearly articulate WHAT the calculation does and WHY it's structured that way
- **Detail data processing**: Explain how entities (addresses, tokens, transactions) are identified, classified, and processed
- **Highlight protocol-specifics**: Call out unique aspects of this protocol's data structure or business logic
- **Be precise**: Provide exact field names, conditions, calculations, and business rules where relevant

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

Total project operating and incentive expenses.

ThenaTHE

Archived

Expenses

Expenses

Competitive landscape

Chain breakdown