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

## 1. Overview

Monthly Active Users (MAU) for Aleph Zero measures the number of unique addresses that have sent at least one transaction on the Aleph Zero EVM blockchain within a rolling 30-day period. This metric provides insight into user engagement and adoption by tracking distinct transaction senders over monthly time windows. The calculation uses HyperLogLog data structures to efficiently deduplicate users across the rolling window while providing breakdowns across multiple dimensions including project-level, chain-level, user type, and product categories.

## 2. Data sources

The metric is calculated using the following raw data sources:

- **Aleph Zero EVM blockchain transactions**: Complete transaction records from the Aleph Zero EVM chain containing sender addresses, recipient addresses, transaction hashes, block timestamps, gas prices, and gas usage amounts
- **Transaction metadata**: Gas pricing and consumption data used for transaction classification and fee calculation
- **Blockchain timestamp data**: Block-level timestamps used for daily and monthly time period aggregation

## 3. Step-by-step calculation

### Component A: Transaction data extraction
- **Purpose**: Extract and standardize raw transaction data from Aleph Zero EVM blockchain
- **Logic**: Raw transaction records are retrieved from Aleph Zero EVM blockchain data, extracting key fields including block timestamps, transaction hashes, sender addresses (`from_address`), recipient addresses (`to_address`), gas prices, and gas usage amounts. Each transaction is tagged with the chain identifier 'Aleph Zero EVM' and classified under the 'blockchains_l2' market sector and 'blockchain' business segment. Gas fees are calculated by multiplying gas used amounts by gas prices and converting from wei to ether units
- **Key fields**: `block_timestamp` for timing, `from_address` for user identification, `transaction_hash` for uniqueness, `gas_price` and `gas_used_amount` for fee calculation

### Component B: Daily active user identification
- **Purpose**: Convert transaction senders into daily active user counts
- **Logic**: Transaction timestamps are truncated to daily granularity, and sender addresses (`from_address`) are identified as active users for each day. Each unique sender address on a given day represents one daily active user. Users are classified as 'Transaction sender' type, and the data is organized by day with chain, user type, and product dimensions. A date filter ensures data only includes transactions up to a specified cutoff date
- **Key fields**: `timestamp` (truncated to day), `user_dau` (sender addresses), `user_type` set to 'Transaction sender', `chain` for blockchain identification

### Component C: HyperLogLog initialization for deduplication
- **Purpose**: Convert daily active user data into HyperLogLog sketches for efficient monthly aggregation
- **Logic**: Daily active user counts are converted into HyperLogLog data structures using `hll_count.init()` with 15-bit precision. This probabilistic data structure allows for efficient deduplication when merging users across multiple days. The HyperLogLog sketches are grouped by timestamp, chain, user type, and product dimensions to maintain proper segmentation
- **Key fields**: `hll` (HyperLogLog sketch), `timestamp`, `chain_id`, `user_type`, `product_id` for dimensional grouping

### Component D: Rolling 30-day window creation
- **Purpose**: Create complete 30-day rolling windows for MAU calculation
- **Logic**: A datespine is generated covering all days from the earliest transaction date to the current date, ensuring no missing days in the time series. For each date in the datespine, a 30-day window is created by generating timestamps for the current day and the previous 29 days using `generate_timestamp_array()`. This creates a complete set of date pairs where each target date is associated with all dates in its 30-day window. The windowing ensures MAU calculation includes the full 30-day period even when some days have no transaction activity
- **Key fields**: `timestamp` (target date), `joinday` (each day within the 30-day window)

### Component E: Window-based HyperLogLog aggregation
- **Purpose**: Merge daily HyperLogLog sketches within each 30-day window
- **Logic**: The 30-day windows are joined with the daily HyperLogLog data, matching each day in the window (`joinday`) with the corresponding daily HyperLogLog sketch (`timestamp`). This creates a dataset where each target date has associated HyperLogLog sketches for all days within its 30-day window. Incremental processing logic applies additional date filtering to optimize performance for updates
- **Key fields**: `timestamp` (target date), `hll` (daily HyperLogLog sketches), dimensional fields for grouping

### Component F: Dimensional MAU breakdown
- **Purpose**: Calculate MAU across different dimensional views
- **Logic**: Monthly Active Users are calculated separately for four dimensional breakdowns. For each breakdown, HyperLogLog sketches within the 30-day windows are merged using `hll_count.merge_partial()` and then extracted to get the final deduplicated user count using `hll_count.extract()`. The four breakdowns are: project-level (aggregating all dimensions), chain-level (grouping by chain), user-type-level (grouping by user type), and product-level (grouping by product). Each breakdown nullifies non-relevant dimensional fields while preserving the specific dimension being analyzed
- **Key fields**: `user_mau` (deduplicated monthly active users), `dimensions` (breakdown type), relevant dimensional fields for each breakdown

### Final aggregation
- **Combining components**: The four dimensional MAU breakdowns are combined using union operations to create a single comprehensive dataset containing MAU values for all dimensional views
- **Currency conversion**: No currency conversion is required as this metric counts users rather than monetary values
- **Time aggregation**: Daily timestamps are used as the basis for 30-day rolling windows, with each date representing the endpoint of a 30-day MAU calculation period
- **Final calculation**: The combined MAU data is processed through the `finalize_metric_user_mau` macro which applies standardization, fills missing days with zeros, and formats the final output with proper schema and metadata including the 'alephzero' data identifier

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

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

Aleph Zero EVMAZERO

Archived

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown