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

## 1. Overview

Monthly active addresses measures the number of unique addresses that have performed transactions on the Astar network within a rolling 30-day period. For blockchain networks like Astar, active users are equivalent to active addresses since each transaction is initiated by a unique address. This metric answers the business question: "How many distinct addresses are actively using the Astar network each month?" The calculation uses a rolling 30-day window approach with HyperLogLog approximation to efficiently count distinct addresses across large datasets.

## 2. Data sources

The calculation relies on the following raw data sources:

- **Astar substrate extrinsics**: Native Astar blockchain transactions containing transaction sender addresses and block timestamps
- **Astar EVM events**: Ethereum Virtual Machine compatible transactions executed through Astar's ethereum pallet, with user addresses extracted from event data
- **Block timestamps**: Timing data from the Astar network to establish daily boundaries and enable time-series analysis

The methodology captures both native Astar substrate-based transactions and EVM-compatible transactions, providing complete coverage of network activity across Astar's dual-chain architecture.

## 3. Step-by-step calculation

### Component A: User identification and daily aggregation
- **Purpose**: Extract unique user addresses from Astar blockchain data and aggregate them into daily active users
- **Logic**: The system processes two types of Astar transactions. For substrate extrinsics, it extracts the transaction sender from the `id` field along with block timestamps. For EVM transactions, it filters events where the `event_pallet` is 'ethereum' and `event_method` is 'Executed', then extracts user addresses from the first element of the `event_data` JSON array. Both data streams are combined and timestamps are truncated to daily boundaries. The result identifies distinct user addresses per day, with each record tagged as 'Transaction sender' user type and assigned to the 'Astar Substrate' product
- **Key fields**: `block_timestamp` for temporal boundaries, `user_address` for unique identification, `chain` designation (astar/astarevm), and `user_type` classification

### Component B: HyperLogLog sketch creation
- **Purpose**: Create efficient approximate distinct count representations for each day's active users
- **Logic**: Daily active user data is processed to create HyperLogLog sketches using BigQuery's `hll_count.init` function with precision 15. This creates compact probabilistic data structures that can be merged across time periods while maintaining approximate distinct counting accuracy. Each day produces an HLL sketch grouped by timestamp, chain, user type, and product dimensions
- **Key fields**: `timestamp` for daily boundaries, `hll` sketches for efficient distinct counting, dimension fields for breakdowns

### Component C: Rolling window construction
- **Purpose**: Build 30-day rolling windows for each date to calculate monthly active user counts
- **Logic**: A complete date spine is generated from the earliest available data to the current date minus one day. For each date in the spine, a join table creates associations with that date and all dates in the previous 29 days (creating 30-day windows). This approach ensures every day has a complete 30-day lookback period, even if some days had no activity. The windowing mechanism uses timestamp arithmetic to create the rolling boundaries
- **Key fields**: `timestamp` for the reference date, `joinday` for dates within each 30-day window

### Component D: Monthly active user calculation
- **Purpose**: Merge HyperLogLog sketches across 30-day windows to calculate approximate monthly active user counts
- **Logic**: The system joins the rolling window structure with daily HLL sketches, then groups by the reference timestamp while merging all HLL sketches within each 30-day period using `hll_count.merge_partial`. The merged sketches are then converted to approximate distinct counts using `hll_count.extract`. This process creates multiple dimensional breakdowns including project-level aggregation, chain-level breakdowns, user type analysis, and product-level metrics. Each breakdown nullifies non-applicable dimension fields while preserving the relevant grouping dimension
- **Key fields**: `user_mau` containing approximate distinct monthly active user counts, `dimensions` indicating the breakdown level, dimension-specific fields like `chain_id` and `user_type`

### Final aggregation
- **Combining components**: The monthly active user calculation produces multiple dimensional views that are combined using union operations to create a comprehensive dataset with different analytical perspectives
- **Currency conversion**: No currency conversion is required as this metric counts addresses rather than monetary values
- **Time aggregation**: The rolling 30-day window approach means each date represents monthly active users for that date plus the previous 29 days, providing smooth time-series progression without traditional calendar month boundaries
- **Final calculation**: Monthly active users are directly mapped to monthly active addresses with a 1:1 relationship, since each active user corresponds to exactly one unique address on the blockchain. The final metric filters results to include only chain-level and project-level dimensional breakdowns, applying standardization macros to ensure consistent schema and filling any missing time periods with zero values.

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

Unique addresses active over a rolling 30-day window.

AstarASTR

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown