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

Interlay is a decentralized Bitcoin bridge powered by Polkadot Relay chain.

INTR holders own and govern the protocol. Interlay’s investors include IOSG Ventures, Hypersphere Ventures, D1 Ventures, etc.

website

github

twitter

discord

etherscan

Blockchains (L2)

Interlay

# Interlay Active users (monthly) Methodology

> **Archived 2026-07-23.** Token Terminal stopped tracking Interlay after the project announced it is winding down operations. The methodology below describes how this metric was calculated while the chain was tracked; historical values remain accurate and accessible.

## 1. Overview

The Interlay Monthly Active Users (MAU) metric measures the number of unique users who have interacted with the Interlay blockchain network within any 30-day rolling window. This metric answers the business question "How many distinct users has Interlay retained over the past month?" and uses a rolling window approach rather than calendar month boundaries to provide a more continuous view of user engagement. The calculation leverages HyperLogLog probabilistic data structures to efficiently compute approximate distinct user counts across overlapping time windows, and provides breakdowns across multiple dimensions including project-level, chain-level, user type, and product categories.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Interlay blockchain extrinsics**: Raw blockchain transaction records from the Interlay network containing all user interactions, transaction metadata, block timestamps, and user addresses
- **Blockchain transaction data**: Complete transaction history including transaction IDs, execution details, and associated user identities
- **System metadata**: Table modification timestamps used for incremental processing optimization and data freshness validation

## 3. Step-by-step calculation

### Component A: Raw user activity extraction
- **Purpose**: Extract and standardize user activity data from raw Interlay blockchain records
- **Logic**: The system processes raw Interlay extrinsics data to identify user interactions with the blockchain. Each extrinsic record represents a transaction or operation initiated by a user. The process extracts the `block_timestamp` for temporal analysis, `extrinsic_id` for transaction identification, and the `id` field as the `user_address`. All users are classified uniformly as "Transaction sender" type since the extrinsics represent user-initiated activities. The data is tagged with protocol metadata including chain identifier as "interlay", market sector as "blockchains_l1", and business segment as "blockchain". The `product_id` remains null as Interlay operates as a unified protocol without product subdivisions.
- **Key fields**: `block_timestamp` for temporal grouping, `user_address` for distinct user identification, `chain` for protocol classification, `user_type` for user categorization

### Component B: Daily active user aggregation
- **Purpose**: Transform raw transaction-level data into daily distinct active user counts
- **Logic**: The raw user activity data is aggregated to daily granularity by truncating `block_timestamp` to day boundaries using timestamp truncation. For each day, the system identifies all unique user addresses that performed any blockchain activity, creating a distinct count of daily active users. The aggregation maintains all dimensional attributes (chain, user type, market sector, business segment, product ID) to enable downstream breakdowns. The process applies incremental processing logic that only recalculates recent periods based on data modification timestamps, using a configurable lookback period for data quality assurance. Chain availability filtering ensures only periods when the blockchain was operational are included.
- **Key fields**: `timestamp` as daily boundary, `user_dau` containing unique user addresses, dimensional fields for breakdown analysis

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily user lists into probabilistic data structures for efficient distinct counting
- **Logic**: The daily active user data is transformed into HyperLogLog (HLL) sketches using BigQuery's `hll_count.init` function with precision parameter 15. This creates approximate distinct count data structures that can be efficiently merged across time periods without losing accuracy for large user sets. Each daily record becomes an HLL sketch containing the probabilistic representation of that day's unique users, grouped by timestamp, chain, user type, and product dimensions.
- **Key fields**: `hll` containing the probabilistic user count sketch, maintained dimensional groupings for aggregation flexibility

### Component D: Date spine and rolling window creation
- **Purpose**: Generate complete time series and create 30-day rolling windows for MAU calculation
- **Logic**: A comprehensive date spine is generated covering the full range from the earliest user activity date to the most recent complete day, ensuring no missing days in the time series. For incremental processing, the spine starts from a calculated lookback period based on table modification timestamps. The system then creates rolling 30-day windows using a cross-join operation between the date spine and historical dates. For each day in the spine, it generates an array of the preceding 29 days plus the current day, creating overlapping 30-day windows. This windowing approach ensures every day has its own complete 30-day lookback period for MAU calculation.
- **Key fields**: `timestamp` for current date, `joinday` for historical dates within each window

### Component E: Window-based HLL aggregation
- **Purpose**: Merge HLL sketches across 30-day windows to calculate monthly active users
- **Logic**: The rolling window structure is joined with the daily HLL data to aggregate user sketches across each 30-day period. For each target date, the system collects HLL sketches from that date's 30-day window and merges them using `hll_count.merge_partial`. This merging operation combines the probabilistic distinct counts while maintaining accuracy, effectively calculating the number of unique users who were active at least once during any 30-day period. The process maintains all dimensional attributes to enable subsequent breakdown analysis.
- **Key fields**: `hll` merged across time windows, dimensional attributes preserved for breakdown calculations

### Component F: Dimensional breakdown generation
- **Purpose**: Create multiple aggregation levels from the window-aggregated data
- **Logic**: The window-aggregated data is processed to generate four distinct dimensional breakdowns. The project-level breakdown merges all HLL sketches regardless of other dimensions, providing overall protocol MAU. The chain-level breakdown groups by chain identifier (though Interlay is single-chain, this maintains consistency with multi-chain protocols). The user-type breakdown groups by user classification, and the product-level breakdown groups by product identifier. Each breakdown uses `hll_count.extract` to convert the merged HLL sketches back to integer user counts, and sets non-relevant dimension fields to null to indicate the aggregation level.
- **Key fields**: `user_mau` as final integer count, `dimensions` indicating breakdown type, relevant dimensional fields populated while others are nulled

### Final aggregation
- **Combining components**: The four dimensional breakdowns are combined using UNION ALL operations to create a single result set containing MAU values at different aggregation levels. Each record is tagged with its dimension type and relevant dimensional values.
- **Currency conversion**: Not applicable for user count metrics - no currency conversion required
- **Time aggregation**: Uses rolling 30-day windows rather than calendar boundaries, with each day representing the MAU for the trailing 30-day period ending on that date
- **Final calculation**: The final MAU value for each dimension and date represents the approximate count of unique users who performed at least one transaction within the 30-day rolling window ending on that date, calculated by merging HyperLogLog sketches and extracting the probabilistic distinct count

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

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

InterlayINTR

Archived

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown