Validators process transactions and receive fees from users (supply-side fees).

Hedera is a decentralized enterprise-grade public network that uses proof-of-stake hashgraph consensus to offer low & fixed fees, 10k TPS, and instant transaction finality. Hedera was founded by Leemon Baird, Mance Harmon, etc. and launched in 2019.

HBAR holders own and govern the protocol. They currently take a cut of the total transaction and query fees paid by users (revenue). Hedera’s investors include BlockTower Capital, Continue Capital, Unanimous Capital, etc.

github

twitter

discord

website

Blockchains (L1)

Hedera

# Hedera Active users (weekly) Methodology

## 1. Overview

Weekly active users (WAU) measures the number of unique users who performed at least one HBAR transfer transaction on the Hedera network within a rolling 7-day period. This metric uses a sliding window approach where each day's WAU represents the count of distinct users who were active on that day or any of the previous 6 days. Users are identified as active when they initiate outgoing HBAR transfers, indicating genuine network participation rather than passive receipt of funds. The calculation uses HyperLogLog probabilistic counting for efficient computation and provides dimensional breakdowns by project, chain, user type, and product.

## 2. Data sources

- **Hedera HBAR transfers**: Native HBAR transfer transactions from the Hedera blockchain, including transaction metadata such as timestamps, transaction hashes, account addresses, and transfer amounts
- **Hedera transaction logs**: Complete transaction records containing block information, node details, and transaction types for all network activity
- **Hedera account data**: Account address information and transaction participation details for user identification and classification

## 3. Step-by-step calculation

### Component A: HBAR transfer processing
- **Purpose**: Extract and process all native HBAR transfer transactions from the Hedera blockchain
- **Logic**: The system retrieves all HBAR transfer records including transaction timestamps, account addresses, and transfer amounts. Each transfer record contains the sending account, receiving account, and the amount transferred. The data includes block-level information such as block number, transaction hash, and node information for complete transaction tracking.
- **Key fields**: `block_timestamp` for timing, `account_address` for user identification, `transfer_amount` for determining transaction direction, `transaction_hash` for deduplication

### Component B: Active user identification
- **Purpose**: Identify active users by filtering for accounts that initiate outgoing HBAR transfers
- **Logic**: The system filters HBAR transfer records to identify users who sent funds by selecting transactions where the `transfer_amount` is negative. This filtering logic distinguishes between active users (who initiate transfers) and passive recipients (who only receive funds). Users are identified by their account addresses and the data is aggregated to daily boundaries by truncating timestamps to the day level. Transaction hashes are preserved to ensure proper deduplication.
- **Key fields**: `user_address` from filtered account addresses, `timestamp` truncated to daily boundaries, `transaction_hash` for transaction tracking

### Component C: Daily active users aggregation  
- **Purpose**: Calculate daily unique active users with deduplication and metadata enrichment
- **Logic**: The system combines recent user activity data from 2025-01-01 onwards with historical user data from before that date. For each day, users are deduplicated by account address to ensure each user is counted only once per day regardless of the number of transactions they performed. The data is enriched with dimensional metadata including chain information, user type classifications, and product identifiers. The system uses HyperLogLog initialization to prepare the data for efficient unique counting in subsequent steps.
- **Key fields**: `user_dau` containing unique user addresses, `timestamp_grain` set to daily level, dimensional fields for `chain`, `user_type`, and `product_id`

### Component D: Sliding window construction
- **Purpose**: Create 7-day rolling windows for each day to enable WAU calculation
- **Logic**: The system generates a complete date spine covering all days in the analysis period to ensure no missing dates. For each day in the date spine, it creates a 7-day lookback window by generating timestamps for that day and the previous 6 days. This approach uses a cross join between the date spine and a 7-day timestamp array to create all day-to-window-day combinations. The daily HLL sketches are then joined with these window definitions to associate each day's users with all relevant 7-day windows they should be included in.
- **Key fields**: `timestamp` for the end of each 7-day window, `joinday` for individual days within each window, `hll` sketches containing user data

### Final aggregation
- **Combining components**: The system merges HyperLogLog sketches across each 7-day window to count unique users, using HLL's merge functionality to handle overlapping users across days within the window
- **Dimensional breakdowns**: WAU is calculated separately for four dimensional levels: project-level (overall network WAU), chain-level (by blockchain), user-type-level (by user classification), and product-level (by product category), with each breakdown nullifying non-relevant dimension fields
- **Time aggregation**: Each day represents the end point of a 7-day rolling window, with the WAU value representing unique users active within that 7-day period ending on that date
- **Final calculation**: The final WAU value for each day and dimension combination is extracted from the merged HyperLogLog sketch, providing an approximate count of unique users active within the rolling 7-day window, with missing days filled with zero values to maintain data continuity

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

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

HederaHBAR

Active users (weekly)

Active users (weekly)

Competitive landscape