Immutable zkEVM batches users' transactions and submits them to Ethereum, paying a share of the transaction fees to Ethereum validators (expense).

Immutable zkEVM is an L2 smart contract platform for decentralized applications on Ethereum. Immutable zkEVM was founded by the Immutable team and launched in 2023.

Immutable team owns and governs the protocol. Immutable's investors include Coinbase Ventures, Temasek, Tencent Holdings, etc.

website

twitter

github

telegram

discord

medium

governance

etherscan

Blockchains (L2)

Immutable zkEVM

# Immutable zkEVM Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for ImmutableX zkEVM measures the distinct count of unique wallet addresses that performed any activity on the network within a rolling 30-day period. This metric captures both general transaction activity and specific ImmutableX Passport wallet interactions, providing a comprehensive view of user engagement across the ecosystem. The calculation uses HyperLogLog probabilistic data structures for efficient distinct counting across large datasets and rolling time windows.

## 2. Data sources

The calculation relies on two primary blockchain data sources from ImmutableX zkEVM:

- **Transaction records**: All transaction data from the ImmutableX zkEVM network, containing transaction metadata including sender addresses, timestamps, and transaction hashes
- **Passport wallet events**: Parsed `Wallet_NonceChange_event` logs from ImmutableX Passport smart contracts, capturing nonce change activities that indicate wallet usage and interactions
- **Chain metadata**: Network identification and classification data including market sector and business segment categorizations

## 3. Step-by-step calculation

### Component A: User activity extraction
- **Purpose**: Identifies and categorizes all unique user addresses with daily activity
- **Logic**: Extracts user addresses from two distinct activity types. Transaction senders are identified from blockchain transaction records and categorized as "Transaction sender" user type. Passport wallet users are identified from `Wallet_NonceChange_event` logs and categorized as "Passport wallet user" type. Both data sources are combined into a unified fact table with consistent schema including `block_timestamp`, `user_address`, `user_type`, and network metadata
- **Key fields**: `user_address` (wallet addresses), `user_type` (activity categorization), `block_timestamp` (activity timing), `chain` (network identifier), `product_id` (protocol identifier)

### Component B: Daily active users aggregation  
- **Purpose**: Calculates distinct daily active users and prepares data for rolling window analysis
- **Logic**: Groups user activity by day using timestamp truncation to day granularity. Performs distinct counting on `user_address` field to eliminate duplicate addresses within each day. Creates dimensional groupings by chain, user type, and product for downstream breakdown analysis. Converts daily distinct user counts into HyperLogLog sketches for efficient probabilistic counting in subsequent rolling window operations
- **Key fields**: `timestamp` (day-truncated dates), `user_dau` (distinct user addresses), `chain` (network), `user_type` (activity category), `product_id` (protocol identifier)

### Component C: Rolling window construction
- **Purpose**: Creates 30-day rolling windows for MAU calculation using datespine methodology
- **Logic**: Generates a complete datespine covering all days from the earliest user activity to the current date. For each day in the datespine, creates associations with the previous 29 days to form 30-day windows. Joins the datespine with daily HLL sketches to ensure complete coverage and handles missing days. This approach prevents gaps in the rolling window calculation that could occur with sparse data
- **Key fields**: `timestamp` (current day), `joinday` (days within rolling window), `hll` (HyperLogLog sketches for user counts)

### Component D: HLL sketch aggregation
- **Purpose**: Merges HyperLogLog sketches across 30-day windows to calculate distinct monthly active users
- **Logic**: For each day and its associated 30-day window, merges all HLL sketches using `hll_count.merge_partial()` function to combine probabilistic distinct counts. Extracts the final distinct user count using `hll_count.extract()` to convert the merged sketch back to an estimated integer value. This approach efficiently handles distinct counting across overlapping time periods while maintaining accuracy for large user bases
- **Key fields**: `user_mau` (extracted distinct user count), `timestamp` (current day), dimensional grouping fields

### Component E: Dimensional breakdowns
- **Purpose**: Creates multiple analytical perspectives of MAU data for different business needs
- **Logic**: Generates four separate dimensional views from the base MAU calculation. Project-level breakdown provides overall network MAU without dimensional splits. Chain-level breakdown groups by network identifier for multi-chain analysis. User type breakdown separates transaction senders from passport wallet users. Product-level breakdown analyzes MAU by specific protocol or product categories. Each breakdown maintains consistent schema while nullifying non-relevant dimensional fields
- **Key fields**: `dimensions` (breakdown type), `chain_id`, `user_type`, `product_id` (dimensional identifiers), `user_mau` (metric value)

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using UNION ALL operations to create a comprehensive dataset with multiple analytical perspectives in a single table
- **Schema standardization**: The `finalize_metric_user_mau` macro applies consistent schema formatting, handles missing values, and ensures data quality standards across all dimensional breakdowns
- **Gap filling**: Missing days are filled with zero values using the 'fill_zeros' strategy to maintain continuous time series data for downstream analysis and visualization
- **Final calculation**: The final MAU value represents the distinct count of unique wallet addresses that performed any activity (transactions or passport wallet interactions) within each rolling 30-day period, segmented by various dimensional breakdowns for comprehensive ecosystem analysis

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

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

Immutable zkEVMIMX

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown