Network participants process transactions and receive fees from users (supply-side fees).

Polkadot is a security & interoperability platform for blockchains and applications. Polkadot was founded by Gavin Wood and launched in 2020.

DOT holders own and govern the protocol. They currently take a cut of the total transaction fees paid by users (revenue). Polkadot’s investors include Polychain, IOSG Ventures, Hashkey, etc.

github

twitter

discord

etherscan

website

Blockchains (L1)

Polkadot

# Polkadot Active users (weekly) Methodology

## 1. Overview

Weekly active users (WAU) measures the number of unique addresses that initiated at least one transaction (extrinsic) across the Polkadot ecosystem within any rolling 7-day period. This metric provides insight into user engagement and adoption across Polkadot's multi-chain architecture, including the relay chain and its various parachains. The calculation uses HyperLogLog data structures to efficiently count distinct users across time windows and multiple chain dimensions.

## 2. Data sources

- **Polkadot blockchain extrinsics**: Raw transaction data from six Polkadot ecosystem chains including the relay chain, Asset Hub, Collectives parachain, Bridge Hub, People parachain, and Coretime parachain
- **Transaction metadata**: Block timestamps, transaction hashes (`extrinsic_hash`), and transaction initiator addresses (`id`) from each chain's extrinsics
- **Chain identification data**: Built-in chain identifiers and product classifications for each parachain and the relay chain

## 3. Step-by-step calculation

### Component A: Daily user extraction across chains
- **Purpose**: Identify unique transaction initiators per day across all Polkadot ecosystem chains
- **Logic**: Extract transaction data from six separate Polkadot chains (relay chain, Asset Hub, Collectives, Bridge Hub, People, and Coretime). For each chain, identify unique user addresses that initiated transactions on each day by truncating `block_timestamp` to daily boundaries and applying distinct operations on `user_address`. Combine data from all chains using union operations while preserving chain identity, user type, and product classifications.
- **Key fields**: `block_timestamp` truncated to day, `user_address` from the `id` field, `chain` identifier, `product_id`, and `user_type` (always 'Transaction sender')

### Component B: HyperLogLog initialization for efficient counting
- **Purpose**: Convert daily user sets into HyperLogLog data structures for memory-efficient distinct counting across time windows  
- **Logic**: Transform the daily distinct user addresses into HyperLogLog sketches using `hll_count.init()` with precision parameter 15. This probabilistic data structure enables efficient merging and counting of distinct values across multiple days without storing individual addresses.
- **Key fields**: `timestamp` at day level, `chain_id`, `user_type`, `product_id`, and `hll` sketch containing user information

### Component C: Continuous datespine generation
- **Purpose**: Create unbroken daily timestamp series to ensure complete time coverage without gaps
- **Logic**: Generate continuous daily timestamps from the earliest available data date through current date minus one day using timestamp array generation. This ensures the rolling window calculation doesn't skip days where data might be missing from individual chains.
- **Key fields**: `timestamp` for each calendar day in the range

### Component D: Rolling 7-day window construction  
- **Purpose**: Build sliding 7-day windows for each date to capture weekly active user periods
- **Logic**: For each day in the datespine, generate a 7-day lookback period including the current day plus the previous 6 days using timestamp array functions. Create join relationships between each target date and its corresponding 7-day window dates to enable window-based aggregations.
- **Key fields**: `timestamp` (target date) and `joinday` (each day within the 7-day window)

### Component E: Window data assembly and HLL merging
- **Purpose**: Combine rolling window structure with daily user HLL data and merge across time periods
- **Logic**: Join the 7-day rolling windows with the daily HLL user data using the window join dates. For each target date, collect HLL sketches from all days within its 7-day window, then merge these HLL structures using `hll_count.merge_partial()` to create a unified sketch representing all unique users active during that week.
- **Key fields**: `timestamp` (target date), dimensional fields (`chain_id`, `user_type`, `product_id`), and merged `hll` structures

### Component F: Multi-dimensional WAU breakdowns
- **Purpose**: Calculate weekly active users across different aggregation levels and business dimensions
- **Logic**: Extract distinct user counts from merged HLL structures using `hll_count.extract()` across four different dimensional breakdowns: (1) project-level aggregation combining all chains, (2) individual chain-level breakdowns, (3) user type level aggregations, and (4) product-level aggregations. Each breakdown uses appropriate grouping and null-casting to create the desired dimension hierarchy.
- **Key fields**: `timestamp`, `dimensions` (aggregation level), relevant dimension fields (`chain_id`, `user_type`, `product_id`), and extracted `user_wau` counts

### Final aggregation
- **Combining components**: Union all dimensional breakdowns (project, chain, user type, product) into a single result set with standardized schema structure
- **Schema standardization**: Apply the `finalize_metric_user_wau` macro to add required metadata fields, handle data type conversions, implement zero-filling strategy for missing dates, and apply standard formatting for downstream consumption
- **Time boundaries**: Use incremental processing with safety margins and lookback periods to efficiently update only recent time periods while maintaining data consistency
- **Final calculation**: The final `user_wau` value represents the distinct count of user addresses that initiated at least one transaction within any rolling 7-day period, aggregated across the specified dimensional breakdown level

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

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

PolkadotDOT

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown