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

## 1. Overview

The Astar Monthly Active Users (MAU) metric measures the number of unique addresses that have initiated transactions on the Astar blockchain within any 30-day rolling period. This metric captures user engagement across both native Astar transactions (extrinsics) and EVM-compatible transactions, providing a comprehensive view of blockchain activity. The calculation uses HyperLogLog data structures for efficient distinct user counting and generates multiple dimensional breakdowns to analyze user activity patterns.

## 2. Data sources

- **Native Astar extrinsics**: Transaction records from the Astar blockchain containing sender addresses and block timestamps for native Substrate-based transactions
- **Astar EVM events**: Parsed ethereum Executed events from the Astar blockchain that capture EVM-compatible transaction activity with user addresses extracted from event data
- **Chain availability data**: Configuration data that defines valid operational periods for the Astar blockchain to ensure data quality

## 3. Step-by-step calculation

### Component A: User extraction and standardization
- **Purpose**: Extract and standardize user addresses from both native and EVM transaction sources
- **Logic**: The system processes two distinct data streams from the Astar blockchain. For native transactions, it extracts the `id` field as the user address from extrinsics data along with `block_timestamp`. For EVM transactions, it parses the `event_data` array from ethereum `Executed` events to extract user addresses. Both streams are standardized with chain identifiers ('astar' for native, 'astarevm' for EVM), market sector classification as 'blockchains_l2', business segment as 'blockchain', and user type as 'Transaction sender'
- **Key fields**: `block_timestamp`, `user_address`, `chain`, `user_type`

### Component B: Daily active user aggregation  
- **Purpose**: Calculate daily distinct active users (DAU) from the standardized user data
- **Logic**: The system truncates all block timestamps to day granularity using timestamp truncation, then deduplicates user addresses within each day to count distinct active users. Each record includes the truncated timestamp, timestamp grain as 'day', chain identifier, user type, and a hardcoded product identifier 'Astar Substrate'. Chain availability filters are applied to exclude data from invalid operational periods
- **Key fields**: `timestamp` (day-truncated), `timestamp_grain`, `chain`, `user_type`, `product_id`, `user_dau`

### Component C: HyperLogLog preparation and windowing
- **Purpose**: Convert DAU data to HyperLogLog structures and create 30-day rolling windows for MAU calculation
- **Logic**: Daily user data is converted to HyperLogLog sketches with 15-bit precision for efficient distinct counting across time windows. A datespine is generated covering the full date range of available data, then joined with a 30-day lookback window for each date. For each date, the system identifies all dates within the previous 29 days (plus the current date) to create rolling 30-day windows. The HLL structures from matching daily records are collected for subsequent merging
- **Key fields**: `timestamp`, `hll` (HyperLogLog sketch), `chain_id`, `user_type`, `product_id`

### Component D: Dimensional breakdown calculation
- **Purpose**: Calculate MAU across multiple dimensional breakdowns using HLL merging
- **Logic**: The system creates four distinct dimensional views by merging HLL sketches within each 30-day window. Project-level breakdown merges all HLL data regardless of chain, user type, or product dimensions. Chain-level breakdown groups by chain identifier while nullifying other dimensions. User-type-level breakdown groups by user type classification. Product-level breakdown groups by product identifier. Each breakdown uses HLL merge operations to combine distinct user counts across the 30-day window, then extracts the final count estimate
- **Key fields**: `dimensions`, `chain_id`, `product_id`, `user_type`, `user_mau`

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using union operations to create a unified dataset with multiple perspective views of the same underlying MAU calculation
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses 30-day rolling windows where each date represents the MAU for the 30-day period ending on that date, calculated using HyperLogLog merge operations for probabilistic distinct counting
- **Final calculation**: The final MAU value for each date and dimension combination represents the estimated distinct count of user addresses that were active within the 30-day period ending on that date, with the estimate extracted from merged HyperLogLog sketches and standardized through the finalization macro

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

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

AstarASTR

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown