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

## 1. Overview

Monthly active addresses measures the number of unique addresses that initiated at least one outgoing HBAR transfer within a rolling 30-day period on the Hedera network. This metric serves as a proxy for blockchain usage and network activity by counting addresses that actively send transactions rather than just receive them. The calculation uses a rolling 30-day window updated daily and employs HyperLogLog probabilistic counting for efficient deduplication across large datasets.

## 2. Data sources

The calculation relies on the following raw data sources:

- **Hedera HBAR transfer events**: Native HBAR transfer records from the Hedera blockchain containing account addresses, transfer amounts, timestamps, and transaction metadata
- **Hedera transaction records**: Blockchain transaction data including transaction hashes, block numbers, timestamps, and network node information
- **Hedera network metadata**: Additional context about transaction types and network nodes processing the transactions

## 3. Step-by-step calculation

### Component A: HBAR transfer extraction
- **Purpose**: Extract all native HBAR transfers from Hedera blockchain events
- **Logic**: Collect transfer events with block timestamps, transaction hashes, account addresses, and transfer amounts. Filter data using incremental processing for recent periods while maintaining historical data separately for performance optimization.
- **Key fields**: `block_timestamp`, `transaction_hash`, `account_address`, `transfer_amount`, `transaction_type`, `node`

### Component B: Active user identification  
- **Purpose**: Identify addresses that actively initiated transactions by filtering for outgoing transfers
- **Logic**: Filter HBAR transfers to include only negative `transfer_amount` values, which represent outgoing transfers from the account perspective. This excludes addresses that only receive transfers and focuses on accounts actively sending transactions. Group results by day and account address to create daily user activity records.
- **Key fields**: `user_address` (derived from account addresses with outgoing transfers), `timestamp` (truncated to daily granularity)

### Component C: Daily active user aggregation
- **Purpose**: Create daily snapshots of unique active users with HyperLogLog initialization
- **Logic**: Combine historical user data (pre-2025) with recent incremental data (2025 onwards) into a unified daily active user dataset. Initialize HyperLogLog sketches for each user address to enable efficient probabilistic counting in subsequent rolling window calculations.
- **Key fields**: `user_dau` (unique user addresses per day), `hll` (HyperLogLog sketch for counting)

### Component D: Monthly rolling window calculation
- **Purpose**: Calculate 30-day rolling monthly active users using windowed HyperLogLog aggregation
- **Logic**: Create a datespine covering all dates from the earliest data to present to ensure no missing days in the rolling calculation. For each day, generate a 30-day window spanning from 29 days prior through the current day. Join the datespine with daily HyperLogLog sketches to create overlapping 30-day windows. Merge HyperLogLog sketches within each 30-day window to count unique users probabilistically while avoiding double-counting users active on multiple days.
- **Key fields**: `user_mau` (extracted from merged HyperLogLog sketches), window timestamps spanning 30-day periods

### Component E: Dimensional breakdown aggregation
- **Purpose**: Calculate monthly active users across multiple dimensional views
- **Logic**: Group the windowed data by different dimensional breakdowns including overall project level (`project_dbt_tag`), chain level, user type, and product ID. For each dimension, merge HyperLogLog sketches and extract final unique user counts. This creates multiple views of the same underlying user activity data.
- **Key fields**: `dimensions` (breakdown category), `chain_id`, `user_type`, `product_id`, aggregated `user_mau` counts

### Final aggregation
- **Combining components**: Select the monthly active user count directly from the MAU calculation and rename it as `active_addresses_monthly`. Filter for relevant dimensional breakdowns (chain and project_dbt_tag levels).
- **Currency conversion**: Not applicable for this count-based metric
- **Time aggregation**: Uses rolling 30-day windows calculated daily, providing a smoothed monthly active address count that updates continuously
- **Final calculation**: The monthly active addresses equals the monthly active users count, treating each active user address as an active address. The metric represents unique addresses that sent at least one HBAR transfer within the most recent 30-day period.

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

Unique addresses active over a rolling 30-day window.

HederaHBAR

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape