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

## 1. Overview

The Astar active addresses daily metric measures the number of unique addresses that performed at least one transaction on the Astar network each day. This metric captures user activity across both the native Astar Substrate blockchain and the AstarEVM (Ethereum Virtual Machine) layer, providing a comprehensive view of daily network utilization. The calculation uses HyperLogLog probabilistic counting to efficiently handle large-scale address deduplication while supporting multiple dimensional breakdowns.

## 2. Data sources

- **Native Astar extrinsics**: Transaction data from the Astar Substrate blockchain containing sender addresses and block timestamps
- **AstarEVM events**: Ethereum-compatible transaction events from the AstarEVM layer, specifically ethereum Executed events that contain user addresses in the event data
- **Chain availability data**: Configuration data that defines active periods for the Astar network to filter out inactive or invalid time ranges

## 3. Step-by-step calculation

### Component A: User address extraction
- **Purpose**: Identifies all unique user addresses that executed transactions on either the native Astar chain or AstarEVM layer
- **Logic**: Extracts user addresses from two distinct data sources. For native Astar transactions, uses the `id` field from extrinsics data as the transaction sender address. For AstarEVM transactions, filters for events where `event_pallet` equals 'ethereum' and `event_method` equals 'Executed', then extracts the user address from the first element of the `event_data` array. Both address types are combined into a unified user dataset with standardized fields including `block_timestamp`, `chain`, and `user_address`
- **Key fields**: `block_timestamp` for temporal analysis, `user_address` for unique identification, `chain` distinguishing between 'astar' and 'astarevm', `user_type` set to 'Transaction sender'

### Component B: Daily user aggregation  
- **Purpose**: Groups user activity by day and creates daily snapshots of unique active addresses
- **Logic**: Truncates block timestamps to day boundaries using timestamp_trunc function. Collects all distinct user addresses for each day, creating daily snapshots that preserve the temporal granularity needed for the active addresses metric. Sets `timestamp_grain` to 'day' and assigns `product_id` as 'Astar Substrate' for all records
- **Key fields**: `timestamp` truncated to day level, `user_dau` containing the unique user address for deduplication, `timestamp_grain` set to 'day'

### Component C: HyperLogLog aggregation
- **Purpose**: Applies probabilistic counting using HyperLogLog sketches to enable efficient distinct counting across multiple dimensional breakdowns
- **Logic**: Creates HyperLogLog sketches for each unique user address with precision parameter 15, enabling approximate distinct counting that scales efficiently. Generates separate aggregations for four different dimensional breakdowns: project-level (project_dbt_tag), chain-level (astar vs astarevm), user-type-level (Transaction sender), and product-level (Astar Substrate). Each breakdown uses HLL merge operations to combine sketches and extract final counts while maintaining the appropriate grouping dimensions
- **Key fields**: `user_dau` containing the final distinct count of addresses, `dimensions` indicating the breakdown type, `chain_id` for chain-specific aggregations

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using union operations to create a comprehensive dataset with multiple perspectives on daily active addresses
- **Currency conversion**: Not applicable for this address-counting metric
- **Time aggregation**: Data is aggregated at daily boundaries with timestamp truncation to day level
- **Final calculation**: The final metric simply renames the `user_dau` field to `active_addresses_daily` while filtering for only 'chain' and 'project_dbt_tag' dimensions. Missing days are filled with zero values using the finalize_metric macro, and chain availability filters ensure only data from active network periods is included in the final results

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

Unique active addresses over a fixed 24-hour window.

AstarASTR

Active addresses (daily)

Active addresses (daily)

Competitive landscape

Chain breakdown