Aleph Zero EVM is powered by Arbitrum's AnyTrust protocol which uses a data availability committee (DAC) to store raw transaction data.

Aleph Zero EVM is an Ethereum layer 2 powered by Arbitrum Orbit tech stack. This dashboard does not include Aleph Zero WASM data.

AZERO tokenholders own and govern the protocol.

github

twitter

discord

website

Blockchains (L2)

Aleph Zero EVM

# Aleph Zero EVM Active addresses (weekly) Methodology

## 1. Overview

Weekly active addresses measures the number of unique addresses that initiated at least one transaction on the AlephZero EVM blockchain within any 7-day period. This metric provides insight into user engagement and blockchain adoption by counting distinct transaction senders over rolling weekly windows. The calculation uses HyperLogLog algorithms for efficient distinct counting across large datasets.

## 2. Data sources

- **AlephZero EVM transaction records**: Complete transaction history from the AlephZero EVM blockchain including transaction hashes, block timestamps, sender addresses, recipient addresses, and gas usage data
- **Transaction metadata**: Block-level timing information and transaction execution details necessary for temporal aggregation and user activity tracking

## 3. Step-by-step calculation

### Component A: Transaction data extraction
- **Purpose**: Extract and standardize raw transaction data from AlephZero EVM blockchain
- **Logic**: Select distinct transactions from AlephZero EVM blockchain records, capturing essential fields including block timestamps, transaction hashes, sender addresses (`from_address`), recipient addresses (`to_address`), and gas-related information. Add chain identifier as 'Aleph Zero EVM' and classify as layer-2 blockchain data with appropriate market sector and business segment classifications.
- **Key fields**: `block_timestamp` for temporal analysis, `from_address` as the active user identifier, `transaction_hash` for uniqueness, gas pricing and usage amounts

### Component B: Daily active user identification  
- **Purpose**: Identify unique daily active users from transaction activity
- **Logic**: Process transaction data to create daily active user records by truncating block timestamps to day-level granularity. Treat each unique transaction sender (`from_address`) as a daily active user, categorized as "Transaction sender" user type. Apply date filtering to ensure data quality and temporal boundaries.
- **Key fields**: `timestamp` truncated to day level, `user_dau` containing the sender address, `user_type` classification, chain and product identifiers

### Component C: HyperLogLog daily aggregation
- **Purpose**: Create efficient data structures for distinct user counting across time windows
- **Logic**: Generate HyperLogLog sketches for each day by grouping daily active users by timestamp, chain, user type, and product dimensions. Initialize HyperLogLog with precision parameter 15 to balance memory usage and accuracy for distinct counting operations.
- **Key fields**: `hll` sketch containing compressed user data, temporal and dimensional grouping keys

### Component D: Rolling weekly window construction
- **Purpose**: Build 7-day rolling windows for weekly active user calculation
- **Logic**: Create a datespine covering the full time range of available data, then generate 7-day rolling windows by joining each date with the 6 preceding days. This approach ensures consistent weekly windows even when daily data has gaps, and enables proper incremental processing with configurable lookback periods.
- **Key fields**: `timestamp` for the window end date, `joinday` for dates within each 7-day window

### Component E: Weekly distinct user calculation
- **Purpose**: Calculate weekly active users using HyperLogLog merging across 7-day windows
- **Logic**: Join the rolling window structure with daily HyperLogLog data, then merge HyperLogLog sketches within each 7-day period to count distinct users. Group results by multiple dimensions including project-level aggregation (`project_dbt_tag`), chain-level aggregation, user type breakdown, and product-level segmentation. Extract final distinct counts from merged HyperLogLog sketches.
- **Key fields**: `user_wau` containing the weekly distinct user count, `dimensions` indicating the aggregation level, dimensional identifiers for grouping

### Final aggregation
- **Combining components**: Select weekly active user data specifically for 'chain' and 'project_dbt_tag' dimensions, which provide the core metrics for blockchain-level and project-level weekly active address tracking
- **Time aggregation**: Use 7-day rolling windows where each day represents the count of unique addresses active in that day and the 6 preceding days, providing continuous weekly metrics without gaps
- **Final calculation**: The weekly active addresses count equals the distinct count of sender addresses that initiated transactions within any 7-day period, calculated using HyperLogLog merge operations for computational efficiency and accuracy across large address sets

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

Unique active addresses over a rolling 7-day window.

Aleph Zero EVMAZERO

Archived

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape

Chain breakdown