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

## 1. Overview

Daily active addresses represents the number of unique addresses that performed any on-chain activity on ImmutablezEVM within a 24-hour period. This metric captures both traditional blockchain transaction activity and Immutable's Passport wallet system usage. For blockchain networks like ImmutablezEVM, active addresses are equivalent to daily active users, providing insight into network adoption and user engagement across Immutable's gaming-focused Layer 2 ecosystem.

## 2. Data sources

The calculation draws from two primary raw data sources:
- **ImmutablezEVM transaction records**: Complete blockchain transaction data including sender addresses (`from_address`) and block timestamps, capturing all users who submit transactions on the network
- **Immutable Passport wallet events**: Specifically `Wallet_NonceChange_event` records from Immutable's identity and wallet infrastructure, tracking users who interact with Passport wallet functionality through the `address` field

## 3. Step-by-step calculation

### Component A: User identification and classification
- **Purpose**: Identify all unique user addresses across both blockchain transactions and Passport wallet interactions
- **Logic**: Extract user addresses from two distinct sources. From blockchain transaction records, identify transaction senders using the `from_address` field and classify them as "Transaction sender" user types. From Passport wallet nonce change events, extract wallet addresses using the `address` field and classify them as "Passport wallet user" types. Both user types are tagged with consistent metadata including chain identifier (immutablezkevm), market sector (blockchains_l2), business segment (blockchain), and product identifier (immutablezkevm). The two data sources are combined using a union operation to create a comprehensive view of all user activity
- **Key fields**: `block_timestamp` for timing, `from_address` and `address` for user identification, `user_type` for classification, `transaction_hash` for transaction linking

### Component B: Daily user aggregation  
- **Purpose**: Aggregate user activity to daily boundaries and create distinct user counts per day
- **Logic**: Truncate all block timestamps to day-level granularity to establish daily boundaries. For each day, select distinct user addresses to ensure each user is counted only once per day regardless of their activity volume. Create HyperLogLog sketches for each unique combination of day, chain, user type, and product to enable accurate distinct counting even with large datasets. This step transforms the raw transaction and event data into daily user records with one entry per unique user per day
- **Key fields**: `timestamp` (truncated to day), `user_address` for distinct counting, `chain`, `user_type`, `product_id` for dimensional breakdowns

### Component C: Multi-dimensional aggregation
- **Purpose**: Calculate daily active user counts across different analytical dimensions
- **Logic**: Using the HyperLogLog sketches, merge and extract distinct user counts across four different dimensional breakdowns. Create project-level aggregation (project_dbt_tag dimension) that combines all users regardless of type or source. Generate chain-level breakdown showing users by blockchain. Produce user-type-level breakdown separating transaction senders from Passport wallet users. Create product-level breakdown by product identifier. Each dimensional aggregation uses HyperLogLog merge operations to combine sketches and extract final distinct counts, ensuring mathematical accuracy in distinct user counting
- **Key fields**: `dimensions` to specify breakdown type, `chain_id` for chain-level analysis, `user_type` for user classification analysis, `product_id` for product-level analysis, `user_dau` containing the distinct count

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using union operations to create a comprehensive dataset with multiple analytical perspectives of the same underlying user activity
- **Currency conversion**: Not applicable - this metric counts unique addresses rather than financial values
- **Time aggregation**: Daily boundaries are established by truncating block timestamps to day granularity. The calculation ensures each unique address is counted only once per day
- **Final calculation**: Select the project-level and chain-level dimensional breakdowns and rename the `user_dau` field to `active_addresses_daily` to align with blockchain terminology. Apply chain availability filtering to ensure data quality and fill missing days with zero values to maintain consistent time series reporting

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

Unique active addresses over a fixed 24-hour window.

Immutable zkEVMIMX

Active addresses (daily)

Active addresses (daily)

Competitive landscape

Chain breakdown