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

## 1. Overview

Weekly active addresses measures the number of unique addresses that were active on the ImmutableX zkEVM blockchain within any 7-day rolling window. This metric answers the question "How many distinct users engaged with the ImmutableX zkEVM ecosystem on a weekly basis?" The calculation uses probabilistic counting techniques to efficiently track distinct addresses across rolling weekly windows, capturing both general transaction activity and specific ImmutableX Passport wallet interactions.

## 2. Data sources

The calculation relies on the following raw blockchain data sources:

- **ImmutableX zkEVM transaction records**: Transaction logs containing sender addresses (`from_address`), transaction hashes, and block timestamps for all transactions on the ImmutableX zkEVM blockchain
- **ImmutableX Passport NonceChange events**: Parsed event logs from the ImmutableX v1 protocol tracking `NonceChange` events, which contain wallet addresses and timestamps representing Passport wallet activity
- **Blockchain metadata**: Chain identifiers, block timestamps, and transaction metadata from the ImmutableX zkEVM blockchain

## 3. Step-by-step calculation

### Component A: User activity identification
- **Purpose**: Identify all unique user addresses that show activity on the ImmutableX zkEVM blockchain
- **Logic**: Extract user addresses from two distinct activity types. From ImmutableX zkEVM transaction records, capture the `from_address` field as transaction senders, classified as "Transaction sender" user type. From ImmutableX Passport wallet NonceChange events, capture the `address` field representing wallet interactions, classified as "Passport wallet user" type. Both sources include block timestamps and transaction hashes for activity tracking. All records are tagged with chain identifier "immutablezkevm", market sector "blockchains_l2", business segment "blockchain", and product ID "immutablezkevm"
- **Key fields**: `block_timestamp`, `user_address`, `user_type`, `transaction_hash`, `chain`

### Component B: Daily active user aggregation  
- **Purpose**: Aggregate user activity to daily distinct active user counts
- **Logic**: Group user activity by day using timestamp truncation to day boundaries. For each day, identify all distinct user addresses that were active regardless of user type or number of transactions. Create daily records containing the timestamp, distinct user addresses, and associated metadata including chain, user type, and product identifiers. Apply incremental processing logic to only recalculate recent periods when new data arrives
- **Key fields**: `timestamp` (day-truncated), `user_dau` (distinct user address), `timestamp_grain`, `chain`, `user_type`, `product_id`

### Component C: HyperLogLog initialization
- **Purpose**: Convert daily active users into probabilistic data structures for efficient weekly counting
- **Logic**: Transform daily active user records into HyperLogLog (HLL) data structures using precision parameter 15. Group by timestamp, chain ID, user type, and product ID, then initialize HLL structures containing the distinct user addresses for each day. This probabilistic approach enables efficient merging of user counts across time windows without storing individual addresses
- **Key fields**: `timestamp`, `chain_id`, `user_type`, `product_id`, `hll` (HyperLogLog structure)

### Component D: Rolling window creation
- **Purpose**: Create 7-day rolling windows for weekly active user calculation
- **Logic**: Generate a complete date spine covering all days from the earliest data to yesterday. For each day in the date spine, create associations with that day plus the previous 6 days to form 7-day windows. Join these window definitions with the daily HLL data to create records where each day is associated with all HLL structures from its 7-day window. This approach ensures consistent weekly windows even when some days have no activity
- **Key fields**: `timestamp` (window end date), `joinday` (individual days in window), `hll` (daily HLL structures)

### Component E: Weekly aggregation by dimension
- **Purpose**: Calculate weekly active users across different dimensional breakdowns
- **Logic**: Group the windowed HLL data by timestamp and merge all HLL structures within each 7-day window using HyperLogLog partial merge operations, then extract the distinct count. Create separate aggregations for four dimensions: project level (project_dbt_tag), chain level, user type level, and product level. For each dimension, group by the relevant fields and merge HLL structures, with unused dimension fields set to null. Combine all dimensional breakdowns using union operations to create a comprehensive dataset
- **Key fields**: `timestamp`, `dimensions` (breakdown type), `chain_id`, `product_id`, `user_type`, `user_wau` (weekly active users)

### Final aggregation
- **Combining components**: Select records from the weekly user aggregation where the dimensions field equals either 'chain' or 'project_dbt_tag', excluding user type and product level breakdowns
- **Currency conversion**: No currency conversion required as this is a count-based metric
- **Time aggregation**: Uses daily timestamps representing the end date of each 7-day rolling window, with each record containing the count of distinct users active in the preceding 7 days
- **Final calculation**: Rename the `user_wau` field to `active_addresses_weekly` to align with the metric naming convention. Apply schema formatting using the finalize_metric macro, which adds standard metadata fields and implements a fill-zeros strategy to ensure missing dates have zero values rather than null records. Apply chain availability filtering to ensure only supported time periods are included in the final output

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

Unique active addresses over a rolling 7-day window.

Immutable zkEVMIMX

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape

Chain breakdown