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 Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) measures the number of distinct users who performed at least one trade on the Thena protocol within any 7-day rolling window. This metric tracks user engagement and adoption across Thena's decentralized exchange (DEX) products on BSC and OpBNB chains. The calculation uses a 7-day rolling window approach where each day's WAU includes all users who traded on that day or any of the 6 preceding days.

## 2. Data sources

The WAU calculation relies on the following raw blockchain data sources:
- **Swap events**: Parsed `Pair_Swap_event` logs from Thena v1 contracts on BSC and OpBNB chains
- **Swap events**: Parsed `AlgebraPool_Swap_event` logs from Thena v2 contracts on BSC and OpBNB chains  
- **Swap events**: Parsed `AlgebraPoolV2_Swap_event` logs from Thena v3 contracts on BSC chain
- **Transaction data**: BSC and OpBNB transaction records containing user addresses and transaction metadata
- **Protocol metadata**: Thena contract addresses and version information for different protocol deployments

## 3. Step-by-step calculation

### Component A: Trade data collection
- **Purpose**: Aggregate all trading activity across Thena protocol versions and chains
- **Logic**: The system collects swap events from three different Thena protocol versions. For v1, it processes `Pair_Swap_event` logs from BSC and OpBNB chains, calculating token amount changes by subtracting `amount0Out` and `amount1Out` from `amount0In` and `amount1In`. For v2, it processes `AlgebraPool_Swap_event` logs using direct `amount0` and `amount1` values. For v3, it processes `AlgebraPoolV2_Swap_event` logs similarly to v2 but also captures `overrideFee` information. Each swap event is joined with transaction data to obtain the user address from the `from_address` field.
- **Key fields**: `user_address` (from transaction data), `block_timestamp`, `chain`, `product_id` (Thena V1/Thena Fusion/Thena Integral), and token amount fields

### Component B: Daily active users calculation  
- **Purpose**: Identify distinct users who traded each day
- **Logic**: Trading activity is grouped by day using `timestamp_trunc` on the block timestamp. For each day, the system identifies distinct user addresses and classifies all users as 'Trader' type since they performed swap transactions. The data is further segmented by chain, product version, and other dimensional attributes. Each daily user list is converted into a HyperLogLog (HLL) data structure for efficient distinct counting in subsequent aggregations.
- **Key fields**: `timestamp` (truncated to day), `user_dau` (distinct user address), `chain`, `user_type`, `product_id`

### Component C: Rolling window creation
- **Purpose**: Create 7-day rolling windows for weekly active user calculation
- **Logic**: A complete datespine is generated covering all days from the earliest trade date to the current date. For each day in the datespine, a 7-day window is created by generating an array of timestamps spanning from 6 days before the current day through the current day. This creates a "jointables" structure where each target date is associated with all 7 days in its rolling window. The daily HLL user data is then joined to this structure to ensure complete coverage across the rolling windows.
- **Key fields**: `timestamp` (target date), `joinday` (individual days within the 7-day window)

### Component D: Weekly aggregation by dimensions
- **Purpose**: Calculate distinct weekly active users across different dimensional breakdowns
- **Logic**: The system creates four separate dimensional views. For project-level analysis, it aggregates all users across chains and products using HLL merge operations. For chain-level analysis, it groups by chain while aggregating across products. For user-type analysis, it groups by user type (all 'Trader'). For product-level analysis, it groups by individual Thena product versions. Each aggregation uses `hll_count.merge_partial` to combine daily HLL structures and `hll_count.extract` to get the final distinct count.
- **Key fields**: `dimensions` (breakdown type), `chain_id`, `product_id`, `user_type`, `user_wau` (distinct count)

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using union operations to create a comprehensive view with different aggregation levels
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Daily boundaries are maintained with 7-day rolling windows applied to each day
- **Final calculation**: The final WAU value for any given day represents the distinct count of users who traded on that day or any of the 6 preceding days, calculated using HyperLogLog merge operations across the daily user sets within each rolling window

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

Unique revenue-generating users over a rolling 7-day window.

ThenaTHE

Archived

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown