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

## 1. Overview

The Hedera daily active users (DAU) metric measures the number of unique accounts that perform outgoing HBAR transfers on any given day. This metric serves as a proxy for network activity and user engagement, focusing specifically on users who are actively sending transactions rather than just receiving them. The calculation uses HyperLogLog (HLL) data structures for efficient counting and aggregation across multiple dimensions.

## 2. Data sources

- **Hedera HBAR transfer events**: Native HBAR transfer records from the Hedera network containing transaction details, account addresses, transfer amounts, and block timestamps
- **Chain availability metadata**: Data quality filters to ensure accurate reporting periods
- **Token Terminal project configuration**: Project categorization and metadata for the Hedera network

## 3. Step-by-step calculation

### Component A: HBAR transfer processing
- **Purpose**: Extracts and processes raw HBAR transfer events from the Hedera network
- **Logic**: Retrieves all native HBAR transfer records including block timestamps, transaction hashes, account addresses, and transfer amounts. The data is partitioned by day and filtered incrementally for efficient processing
- **Key fields**: `block_timestamp` for timing, `account_address` for user identification, `transfer_amount` for determining transaction direction, `transaction_hash` for transaction tracking

### Component B: User identification and segmentation
- **Purpose**: Identifies active users and segments them into historical and recent datasets for processing efficiency
- **Logic**: Active users are defined as accounts making outgoing HBAR transfers, identified by filtering for negative `transfer_amount` values. The data is split into two segments: historical users (transactions before 2025-01-01) processed as a static table, and recent users (transactions from 2025-01-01 onwards) processed incrementally. Block timestamps are truncated to day level for daily aggregation
- **Key fields**: `user_address` for unique user identification, `timestamp` for daily grouping, `timestamp_grain` set to 'day'

### Component C: Daily user aggregation
- **Purpose**: Creates the base daily active user metric by deduplicating users per day
- **Logic**: Combines historical and recent user data using UNION ALL operations. For incremental builds, only recent data is processed, while full builds include both historical and recent segments. Unique users are identified per day using DISTINCT operations on user addresses, then populated with metadata fields for dimensional analysis
- **Key fields**: `user_dau` containing unique user addresses, `chain`, `user_type`, and `product_id` for dimensional breakdowns

### Component D: HyperLogLog initialization and dimensional aggregation
- **Purpose**: Applies HyperLogLog data structures for scalable user counting and creates multiple dimensional views
- **Logic**: Initializes HLL data structures with precision 15 for efficient approximate counting. Creates four dimensional breakdowns: project-level (overall), chain-level, user_type-level, and product_id-level aggregations. Each breakdown groups the HLL-initialized user counts by the respective dimension while setting other dimensions to null
- **Key fields**: `hll` containing HyperLogLog data structures, `dimensions` indicating the breakdown type, dimension-specific fields like `chain_id`, `product_id`, `user_type`

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using UNION ALL operations to create a comprehensive dataset with multiple aggregation levels
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Daily boundaries are established by truncating timestamps to day level, with monthly partitioning for storage efficiency
- **Final calculation**: HLL merge operations combine user counts using `hll_count.merge_partial()`, then extract final counts using `hll_count.extract()`. The finalize_metric_user_dau macro applies schema standardization, fills missing dates with zeros, and applies chain availability filters to ensure data quality and completeness

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

Unique revenue-generating users over a fixed 24-hour window.

HederaHBAR

Active users (daily)

Active users (daily)

Competitive landscape