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

## 1. Overview

Weekly active addresses measures the number of unique addresses that sent at least one HBAR transaction during a rolling 7-day window on the Hedera network. This metric answers how many distinct users are actively transacting on Hedera each week. The calculation identifies active users by tracking outgoing HBAR transfers (where the transfer amount is negative, indicating the address is sending funds) and uses HyperLogLog data structures for efficient cardinality estimation across the 7-day rolling window.

## 2. Data sources

The calculation uses the following raw data sources:
- **Hedera HBAR transfers**: Native HBAR token transfer events from the Hedera blockchain containing transfer amounts, sender/receiver account addresses, transaction hashes, block timestamps, transaction IDs, and node information
- **Hedera transaction metadata**: Block numbers, transaction types, and other transaction-level details from Hedera blockchain records

## 3. Step-by-step calculation

### Component A: HBAR transfer extraction
- **Purpose**: Extracts all native HBAR transfers from the Hedera blockchain
- **Logic**: Retrieves transfer events with key fields including `block_timestamp`, `block_number`, `transaction_hash`, `transaction_id`, `account` (address), and `amount` (transfer amount). The data includes both incoming and outgoing transfers for all accounts
- **Key fields**: `account_address` identifies the account involved in the transfer, `transfer_amount` indicates the amount and direction of the transfer (positive for incoming, negative for outgoing)

### Component B: Active user identification  
- **Purpose**: Identifies active users by filtering for accounts that sent transactions
- **Logic**: Filters HBAR transfers to include only outgoing transfers where `transfer_amount` is negative, indicating the account is sending funds and therefore actively transacting. Groups data by day using `date_trunc` on `block_timestamp`. Historical data (pre-2025) and recent data (2025+) are processed separately for performance optimization
- **Key fields**: `user_address` represents the sending account, `timestamp` represents the day of activity, `transaction_hash` provides unique transaction identification

### Component C: Daily active user calculation
- **Purpose**: Calculates daily active users (DAU) by counting distinct user addresses per day
- **Logic**: Takes the identified active users and counts distinct `user_address` values for each day. Creates daily records with metadata including chain information, user type, and product ID. Uses distinct counting to ensure each address is counted only once per day regardless of transaction volume
- **Key fields**: `user_dau` contains the unique user address, `timestamp` represents the day, `timestamp_grain` is set to 'day'

### Component D: HyperLogLog sketch creation
- **Purpose**: Converts daily user counts into HyperLogLog data structures for efficient cardinality estimation
- **Logic**: Groups daily active users by timestamp, chain, user type, and product ID. Creates HyperLogLog sketches using `hll_count.init` with precision 15 to enable efficient approximate counting of distinct users. This allows for memory-efficient storage and fast computation of weekly active user counts
- **Key fields**: `hll` contains the HyperLogLog sketch representing the set of users for each day

### Component E: Rolling window construction
- **Purpose**: Creates a 7-day rolling window for each date to calculate weekly active users
- **Logic**: Uses a datespine to generate a complete time series from the earliest data date to current date. For each date, creates join keys for the current day and the 6 preceding days using `generate_timestamp_array` with 6-day lookback. Joins the datespine with daily HLL sketches to create a window of HLL sketches for each 7-day period
- **Key fields**: `timestamp` represents the end date of the 7-day window, `joinday` represents each day within the window, `hll` contains the daily sketches for merging

### Component F: Weekly active user aggregation
- **Purpose**: Merges HLL sketches across the 7-day window to calculate weekly active users
- **Logic**: Groups the windowed data by timestamp and other dimensions. Uses `hll_count.merge_partial` to combine all HLL sketches within each 7-day window, then `hll_count.extract` to get the final distinct count. This produces the number of unique users who were active at least once during the 7-day period
- **Key fields**: `user_wau` contains the weekly active user count for each 7-day window

### Component G: Dimensional breakdowns
- **Purpose**: Calculates weekly active users across different dimensional breakdowns
- **Logic**: Creates separate aggregations for different analysis dimensions: project-level (combining all data), chain-level, user type-level, and product ID-level. Each breakdown groups the HLL sketches appropriately and calculates weekly active users for that specific dimension. Uses `safe_cast(null as string)` for dimensions not applicable to each breakdown
- **Key fields**: `dimensions` indicates the breakdown type ('project_dbt_tag', 'chain', 'user_type', 'product_id'), dimension-specific ID fields, `user_wau` contains the count for each breakdown

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using union operations to create a single table with weekly active user counts across all dimensions
- **Metric finalization**: The `finalize_metric_user_wau` macro applies standard schema formatting, data validation, and fills missing days with zero values to ensure complete time series
- **Address conversion**: The final step renames `user_wau` to `active_addresses_weekly` since for blockchain networks, active users are equivalent to active addresses - each unique address represents a distinct user
- **Final calculation**: The result is the count of unique addresses that sent at least one HBAR transaction during each rolling 7-day period, calculated using HyperLogLog approximation for efficiency and accuracy

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

Unique active addresses over a rolling 7-day window.

HederaHBAR

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape