Collators aggregate parachain transactions block candidates and producing state transition proofs for validators based on those blocks.

Heima is a specialized identity and data verification blockchain powered by Polkadot Relay chain.

HEI holders own and govern the protocol. Heima’s investors include LD Capital, Digital Renaissance, Signum Capital, and others.

website

twitter

github

discord

etherscan

Blockchains (L2)

Heima

# Heima Active addresses (monthly) Methodology

## 1. Overview

Monthly active addresses measures the number of unique addresses that performed at least one transaction on the Heima network within a 30-day rolling window. This metric provides insight into user engagement and network adoption by tracking distinct addresses active across Heima's native substrate blockchain and EVM-compatible layer. The calculation uses HyperLogLog probabilistic counting for efficient computation of distinct addresses across large datasets.

## 2. Data sources

The calculation utilizes two primary raw blockchain data sources from Heima:

- **Heima substrate extrinsics**: Native blockchain transaction records containing user addresses in the `id` field and block timestamps, representing direct interactions with Heima's substrate-based functionality
- **Heima EVM execution events**: Ethereum-compatible transaction events from the ethereum pallet, where user addresses are extracted from JSON-formatted event data, representing EVM-compatible transactions on Heima's hybrid architecture

## 3. Step-by-step calculation

### Component A: User fact extraction
- **Purpose**: Extracts and standardizes user address data from both Heima's native and EVM execution layers
- **Logic**: Combines substrate extrinsics (using the `id` field as user address) with EVM ethereum execution events (extracting addresses from the first element of `event_data` JSON array). Both data sources are filtered to ensure valid block timestamps and tagged with appropriate chain identifiers ('heima' for native, 'heimaevm' for EVM layer). All users are classified as 'Transaction sender' type within the 'blockchains_l2' market sector
- **Key fields**: `block_timestamp` for temporal analysis, `user_address` for distinct counting, `chain` for network identification, `user_type` for categorization

### Component B: Daily active user calculation
- **Purpose**: Aggregates unique addresses per day using efficient probabilistic counting
- **Logic**: Groups user addresses by day using timestamp truncation to daily boundaries. Creates distinct daily user counts while preserving dimensional breakdowns by chain, user type, and other attributes. Uses HyperLogLog sketches with 15-bit precision for memory-efficient distinct counting that scales to large address volumes
- **Key fields**: `timestamp` (truncated to day), `user_dau` containing the unique address, HyperLogLog initialization for subsequent aggregation

### Component C: Monthly active user window calculation
- **Purpose**: Implements 30-day rolling windows to calculate monthly active users using HyperLogLog aggregation
- **Logic**: Creates a datespine covering all days from the earliest data to present, then generates 30-day lookback windows for each day. Joins daily HyperLogLog sketches across these windows and merges the probabilistic counts to estimate distinct users over each 30-day period. This approach handles missing days gracefully and provides consistent monthly active user calculations without gaps
- **Key fields**: `timestamp` for window boundaries, merged HyperLogLog sketches for distinct user estimation, dimensional attributes for breakdown analysis

### Component D: Dimensional breakdowns
- **Purpose**: Calculates monthly active users across multiple analytical dimensions
- **Logic**: Aggregates the monthly active user data into four distinct dimensional views: project-level (combining all chains), chain-level (native vs EVM), user-type-level (transaction senders), and product-level (currently null for Heima). Each breakdown merges HyperLogLog sketches appropriately and extracts the final distinct count estimates
- **Key fields**: `dimensions` field indicating breakdown type, `user_mau` containing the estimated distinct user count, relevant dimensional identifiers

### Final aggregation
- **Combining components**: Unions all dimensional breakdowns into a single dataset with consistent schema, filtering to include only chain-level and project-level dimensions for the active addresses metric
- **Currency conversion**: Not applicable for this address-counting metric
- **Time aggregation**: Uses 30-day rolling windows with daily granularity, where each day represents the count of distinct addresses active in the preceding 30 days
- **Final calculation**: Renames the `user_mau` field to `active_addresses_monthly` to reflect that addresses rather than users are being counted, applies zero-filling for missing periods, and includes chain availability filtering to ensure data quality

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

Unique addresses active over a rolling 30-day window.

HeimaHEI

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown