website

twitter

github

Blockchains (L2)

Invarch

# Invarch Active addresses (monthly) Methodology

## 1. Overview

The InvArch active addresses monthly metric measures the number of unique wallet addresses that have been active on the InvArch blockchain within a 30-day rolling window, calculated on a daily basis. This metric provides insight into user engagement and network adoption by tracking both native Substrate transactions and EVM-compatible activity on InvArch's multi-layer blockchain infrastructure.

## 2. Data sources

- **InvArch extrinsics data**: Native Substrate blockchain transaction records containing transaction senders and execution details for InvArch's primary layer
- **InvArch EVM events data**: Parsed EVM execution events specifically from the `evm` pallet's `Executed` method, capturing EVM-compatible transaction activity on InvArch's EVM compatibility layer
- **Blockchain transaction metadata**: Block timestamps, transaction identifiers, and execution context from both native and EVM layers

## 3. Step-by-step calculation

### Component A: User identification and extraction
- **Purpose**: Extract and standardize user addresses from both native Substrate and EVM transaction layers
- **Logic**: The system processes two distinct data streams from InvArch. For native Substrate transactions, it extracts the transaction sender address (`id` field) from extrinsics data, classifying each as a "Transaction sender" user type on the "invarch" chain. For EVM transactions, it filters events to only include `evm` pallet `Executed` method calls, extracting user addresses from the first element of the `event_data` array, classifying these on the "invarchevm" chain. Both streams are limited to transactions occurring before July 18, 2025, and unified into a single user fact table with standardized fields including `block_timestamp`, `chain`, `market_sector_id` (blockchains_l2), `business_segment_id` (blockchain), and `user_address`
- **Key fields**: `block_timestamp`, `user_address`, `chain` (invarch/invarchevm), `user_type`, `market_sector_id`, `business_segment_id`

### Component B: Daily active user aggregation  
- **Purpose**: Calculate daily distinct active users across both InvArch chains
- **Logic**: The system groups the unified user data by day using timestamp truncation to day-level granularity. For each day, it counts distinct user addresses across all chains and user types, creating daily active user records. Each record contains the truncated timestamp, timestamp grain indicator ("day"), chain information, user type, and the distinct user address. This creates the foundation dataset of daily unique users that will be used for the rolling monthly calculation
- **Key fields**: `timestamp` (truncated to day), `timestamp_grain`, `user_dau`, `chain`, `user_type`, `product_id`

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily user data into memory-efficient approximate counting structures for scalable unique user calculation
- **Logic**: The daily active user data is transformed into HyperLogLog sketches using a precision parameter of 15 bits. Each day's distinct user addresses are processed through the HyperLogLog initialization function, creating compact probabilistic data structures that can efficiently estimate cardinality. The sketches are grouped by timestamp, chain, user type, and product to maintain dimensional breakdowns while enabling efficient approximate counting of unique users across large datasets
- **Key fields**: `timestamp`, `chain_id`, `user_type`, `product_id`, `hll` (HyperLogLog sketch)

### Component D: Rolling 30-day window creation
- **Purpose**: Generate overlapping 30-day periods for monthly active user calculation using a datespine approach
- **Logic**: The system creates a comprehensive datespine covering all days from the earliest available data to the current date minus one day. For each day in this spine, it generates a 30-day lookback window by creating timestamps for the current day plus the previous 29 days. This results in joinable pairs where each target day is associated with all days in its 30-day window. The datespine approach ensures consistent window coverage even when daily data has gaps, providing the foundation for accurate rolling monthly calculations
- **Key fields**: `timestamp` (target day), `joinday` (days within the 30-day window)

### Component E: Monthly active user calculation with dimensional breakdowns
- **Purpose**: Calculate 30-day rolling unique users across multiple dimensional breakdowns using HyperLogLog merging
- **Logic**: The system joins the rolling window structure with the daily HyperLogLog sketches, creating a comprehensive dataset where each day has access to HyperLogLog data from its entire 30-day window. The HyperLogLog sketches within each 30-day period are then merged and extracted to calculate approximate unique user counts. This process is repeated across four dimensional breakdowns: project-level (aggregating all chains and user types), chain-level (breaking down by invarch/invarchevm), user type level (breaking down by transaction sender types), and product level (breaking down by product categories). Each dimensional breakdown uses HyperLogLog merging to efficiently calculate unique users while maintaining the approximate counting accuracy
- **Key fields**: `timestamp`, `dimensions`, `chain_id`, `product_id`, `user_type`, `user_mau`

### Final aggregation
- **Combining components**: The multiple dimensional breakdowns are combined using union operations, creating a unified dataset with monthly active users segmented by project, chain, user type, and product dimensions
- **Currency conversion**: No currency conversion is required as this metric counts addresses rather than monetary values
- **Time aggregation**: The metric uses 30-day rolling windows calculated daily, providing daily updates of monthly active user counts without traditional monthly boundary constraints
- **Final calculation**: The `user_mau` field is renamed to `active_addresses_monthly` to reflect the final metric name. The `finalize_metric_active_addresses_monthly` macro applies standardized schema formatting and implements a zero-filling strategy for missing time periods, ensuring consistent daily output even when no user activity occurs on specific days

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

Unique addresses active over a rolling 30-day window.

Invarch

Archived

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown