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 (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) measures the count of unique addresses that have initiated at least one HBAR transfer transaction on the Hedera network within a rolling 30-day period. This metric identifies genuine user activity by focusing on transaction senders rather than recipients, providing insight into active network participation and user engagement on Hedera.

The calculation uses a rolling 30-day window approach with HyperLogLog (HLL) data structures for efficient distinct user counting across large datasets. The metric supports multiple dimensional breakdowns including project-level, chain-level, user type, and product-level analysis.

## 2. Data sources

- **Hedera HBAR transfers**: Native HBAR transfer events from the Hedera blockchain containing transaction details, account addresses, transfer amounts, block timestamps, and transaction metadata
- **Transaction data**: Hedera blockchain transaction records including transaction hashes, block numbers, transaction types, and node information
- **Account data**: Hedera account address information for user identification and classification

## 3. Step-by-step calculation

### Component A: HBAR transfer extraction
- **Purpose**: Extract all native HBAR transfer events from the Hedera blockchain
- **Logic**: Raw HBAR transfer events are collected including all transaction details such as `block_timestamp`, `transaction_hash`, `account` addresses, `transfer_amount`, and transaction metadata. This provides the foundational dataset of all HBAR movement on the network
- **Key fields**: `block_timestamp` for temporal analysis, `account_address` for user identification, `transfer_amount` for determining transfer direction, `transaction_hash` for unique transaction identification

### Component B: User identification and activity filtering
- **Purpose**: Identify active users by filtering to transaction senders only
- **Logic**: The system filters HBAR transfers to include only outgoing transfers where `transfer_amount` is negative, indicating the account is sending HBAR rather than receiving it. This approach identifies genuine user-initiated activity rather than passive receipt of funds. User addresses are extracted from these sending transactions and timestamped to the day level
- **Key fields**: `user_address` from accounts with negative transfer amounts, `timestamp` truncated to daily granularity, `transaction_hash` for deduplication

### Component C: Daily active user aggregation  
- **Purpose**: Create daily snapshots of unique active users
- **Logic**: User addresses are grouped by day to create Daily Active User (DAU) datasets. The process handles data in two segments: historical data (pre-2025) processed as a static table, and recent data (2025 onwards) processed incrementally. Users are deduplicated within each day to ensure each address is counted only once per day regardless of transaction volume
- **Key fields**: `timestamp` at day level, `user_address` for distinct counting, dimensional attributes like `chain`, `user_type`, and `product_id`

### Component D: Rolling window construction
- **Purpose**: Create 30-day rolling windows for MAU calculation
- **Logic**: A datespine generates all calendar days in the analysis period. For each day, the system creates a 30-day lookback window by generating timestamps for the current day and the previous 29 days. This creates joinable date ranges that connect each target date with its relevant 30-day historical period
- **Key fields**: `timestamp` for the target date, `joinday` for each day in the 30-day window, enabling temporal joins

### Component E: HyperLogLog aggregation
- **Purpose**: Efficiently count distinct users across 30-day windows using probabilistic data structures
- **Logic**: Daily user data is converted to HyperLogLog (HLL) sketches using `hll_count.init` with 15-bit precision. For each 30-day window, HLL sketches are merged using `hll_count.merge_partial` to combine user sets across the rolling period. The final distinct user count is extracted using `hll_count.extract`, providing an approximate but highly accurate count of unique users
- **Key fields**: `hll` sketches for efficient distinct counting, merged across the 30-day window

### Component F: Multi-dimensional breakdown
- **Purpose**: Calculate MAU across different analytical dimensions
- **Logic**: The system generates separate MAU calculations for four dimensions: project-level (aggregated across all dimensions), chain-level (by blockchain), user-type level (by user classification), and product-level (by product category). Each breakdown aggregates the appropriate dimensional attributes while nullifying others to create clean dimensional views
- **Key fields**: `dimensions` field indicating breakdown type, relevant dimensional attributes (`chain_id`, `user_type`, `product_id`), `user_mau` count

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using UNION ALL operations to create a comprehensive dataset with MAU calculated across all analytical dimensions
- **Time aggregation**: The metric uses daily timestamps but calculates rolling 30-day windows, providing daily MAU values that reflect the previous 30 days of activity
- **Final calculation**: The `finalize_metric_user_mau` macro applies final formatting, metadata population, and handles missing data with a fill-zeros strategy to ensure complete time series coverage

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

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

HederaHBAR

Active users (monthly)

Active users (monthly)

Competitive landscape