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

Astar is a collective driving web3 adoption by connecting people through blockchain technology, business innovation, decentralized applications, and seamless digital experiences in the Polkadot ecosystem. Astar was founded by Sota Watanabe and launched in 2021.

ASTR tokenholders own and govern the protocol. Part of the transaction fees is burned (revenue). Astar’s investors include Binance, Polychain Capital, Crypto.com, etc.

website

twitter

github

discord

Blockchains (L2)

Astar

# Astar Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) measures the number of unique addresses that executed at least one transaction on the Astar blockchain within any 7-day rolling window. This metric captures user engagement across both Astar's native substrate layer and its Ethereum-compatible EVM layer. The calculation uses HyperLogLog probabilistic data structures to efficiently count distinct users over rolling time windows, providing approximate but highly scalable distinct user counts across multiple dimensional breakdowns.

## 2. Data sources

- **Astar substrate extrinsics**: Native Astar blockchain transaction records containing user addresses, block timestamps, and transaction metadata for substrate-based interactions
- **Astar EVM events**: Ethereum-compatible transaction events from Astar's EVM layer, specifically ethereum Executed events that capture EVM transaction execution with user addresses extracted from event data
- **Blockchain metadata**: Chain identifiers, market sector classifications, and business segment mappings for dimensional analysis

## 3. Step-by-step calculation

### Component A: User activity extraction
- **Purpose**: Identify all unique user addresses that executed transactions on either Astar layer
- **Logic**: Extract user activity from both native substrate extrinsics and EVM-compatible ethereum events. For substrate extrinsics, use the `id` field directly as the user address. For EVM events, parse the first element of `event_data` array as the user address from ethereum Executed events. Classify all users as 'Transaction sender' type and assign chain identifiers ('astar' for substrate, 'astarevm' for EVM layer).
- **Key fields**: `block_timestamp` for temporal analysis, `user_address` for distinct counting, `chain` for dimensional breakdown

### Component B: Daily active users calculation  
- **Purpose**: Aggregate user activity to daily granularity and count distinct users per day
- **Logic**: Truncate block timestamps to daily boundaries and count distinct user addresses within each day. Apply incremental processing with lookback periods to handle late-arriving data. Assign 'Astar Substrate' as the standardized product identifier and maintain user type and chain dimensions for downstream aggregation.
- **Key fields**: `timestamp` truncated to day, `user_dau` containing user addresses for distinct counting, dimensional fields for grouping

### Component C: HyperLogLog initialization
- **Purpose**: Convert daily user counts to probabilistic data structures for efficient set operations
- **Logic**: Transform daily distinct user addresses into HyperLogLog sketches with precision parameter 15. Group by timestamp, chain, user type, and product dimensions to create separate HLL structures for each dimensional combination. This enables efficient merging across time windows without storing individual user addresses.
- **Key fields**: `hll` containing HyperLogLog sketch, dimensional grouping fields

### Component D: Rolling window generation
- **Purpose**: Create 7-day rolling windows for each date to calculate weekly active users
- **Logic**: Generate a date spine covering the full time range to ensure no missing dates. For each date in the spine, create associations with the previous 6 days plus the current date to form 7-day windows. Use array generation functions to create these date associations and join with the daily HLL data to build complete rolling windows.
- **Key fields**: `timestamp` for the target date, `joinday` for dates within the 7-day window

### Component E: Weekly aggregation by dimensions
- **Purpose**: Calculate WAU across different dimensional breakdowns
- **Logic**: Create separate aggregations for project-level (overall), chain-level, user-type-level, and product-level analysis. For each dimensional breakdown, merge HLL sketches across the 7-day rolling windows and extract the approximate distinct count. Null out irrelevant dimensional fields for each breakdown type to create clean dimensional views.
- **Key fields**: `user_wau` containing the final distinct user count, `dimensions` indicating the breakdown type, relevant dimensional identifier fields

### Final aggregation
- **Combining components**: Union all dimensional breakdown views (project, chain, user type, product) to create a comprehensive dataset with multiple analytical perspectives
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Rolling 7-day windows calculated for each daily timestamp, providing continuous WAU values rather than discrete weekly periods
- **Final calculation**: Extract approximate distinct user counts from merged HyperLogLog sketches across 7-day rolling windows, apply schema standardization through the finalization macro, and fill any missing dates with zero values to maintain time series continuity

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

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

AstarASTR

Active users (weekly)

Active users (weekly)

Competitive landscape

Chain breakdown