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

## 1. Overview

Daily active addresses on Hedera measures the number of unique account addresses that initiated at least one HBAR (native token) transfer transaction on a given day. This metric treats daily active users as active addresses, focusing specifically on accounts that send transactions rather than passive recipients. The calculation uses HyperLogLog algorithms for efficient distinct counting across multiple dimensional breakdowns including chain-level, project-level, user type, and product-level aggregations.

## 2. Data sources

The calculation relies on the following raw data sources:

- **Hedera HBAR transfer events**: Native HBAR token transfer events from the Hedera blockchain containing transaction details, account addresses, transfer amounts, and block timestamps
- **Hedera transaction logs**: Blockchain transaction records including transaction hashes, block numbers, node information, and transaction types  
- **Hedera blockchain data**: Core blockchain event data providing the foundation for identifying user activity and transaction patterns

## 3. Step-by-step calculation

### Component A: HBAR transfer extraction
- **Purpose**: Extracts all native HBAR transfer events from the Hedera blockchain
- **Logic**: Pulls raw transfer data including block timestamps, transaction hashes, account addresses, and transfer amounts. Applies incremental processing logic to handle new data efficiently while maintaining historical completeness. Captures transaction metadata like block numbers, node information, and transaction types for comprehensive activity tracking.
- **Key fields**: `block_timestamp` for time-based aggregation, `transaction_hash` for unique transaction identification, `account_address` for user identification, `transfer_amount` for determining transaction direction

### Component B: Active user identification  
- **Purpose**: Identifies active users by focusing on accounts that initiate transactions
- **Logic**: Filters HBAR transfers to include only accounts with negative `transfer_amount` values, as negative amounts indicate outgoing transfers where the account is the transaction sender. Groups transactions by day using date truncation. Separates historical data processing (before 2025-01-01) from recent incremental data for performance optimization. Deduplicates transactions by maintaining unique combinations of timestamp, transaction hash, and user address.
- **Key fields**: `user_address` as the identified active participant, `timestamp` truncated to daily boundaries, `transaction_hash` for deduplication

### Component C: Daily active user aggregation
- **Purpose**: Aggregates unique user addresses into daily active user counts with multi-dimensional breakdowns
- **Logic**: Combines historical and recent user data into a unified dataset. Applies HyperLogLog initialization to enable approximate distinct counting for scalability. Creates separate aggregations for different dimensional breakdowns: project-level (project_dbt_tag), chain-level, user-type-level, and product-level. Uses HyperLogLog merge operations to combine user counts across dimensions while maintaining uniqueness. Handles null values appropriately for dimensions that don't apply to specific breakdowns.
- **Key fields**: `user_dau` containing the distinct user addresses, `dimensions` indicating the aggregation level, `chain_id`, `product_id`, and `user_type` for dimensional analysis

### Final aggregation
- **Combining components**: The daily active user counts are directly mapped to active addresses, treating each unique daily active user as an active address
- **Currency conversion**: Not applicable as this metric counts addresses rather than monetary values
- **Time aggregation**: Data is aggregated at daily boundaries using date truncation to day level, with incremental processing maintaining up-to-date results
- **Final calculation**: The final active addresses count equals the number of unique account addresses that initiated at least one HBAR transfer on each day, calculated using HyperLogLog extract functions to get the final distinct count from the probabilistic data structure. Missing days are filled with zero values to ensure complete time series data.

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

Unique active addresses over a fixed 24-hour window.

HederaHBAR

Active addresses (daily)

Active addresses (daily)

Competitive landscape