website

github

twitter

Blockchains (L1)

XDC Network

# XDC Network Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for XDC measures the number of unique addresses that have initiated at least one transaction on the XDC blockchain within a rolling 30-day period. This metric uses a HyperLogLog-based approximation algorithm to efficiently calculate unique user counts across multiple dimensions while maintaining accuracy for large datasets. The calculation employs a rolling window approach where each day's MAU value represents the count of unique transaction senders over the current day and the previous 29 days.

## 2. Data sources

- **XDC blockchain transaction records**: Raw transaction data from the XDC network containing transaction metadata, timestamps, and participant addresses
- **Transaction sender addresses**: The `from_address` field identifying the initiating address for each transaction
- **Block timestamps**: Precise timing data for when transactions were included in blocks on the XDC blockchain

## 3. Step-by-step calculation

### Component A: User fact extraction
- **Purpose**: Extract and standardize user activity data from raw XDC blockchain transactions
- **Logic**: This component processes XDC blockchain transaction records to identify unique user interactions. It extracts the transaction sender address (`from_address`) as the user identifier, along with the block timestamp for temporal analysis. Each record is standardized with metadata including chain identifier ('xdc'), market sector ('blockchains_l1'), business segment ('blockchain'), product ID ('xdc'), and user type ('Transaction sender'). The transaction hash is preserved for potential deduplication and audit purposes.
- **Key fields**: `block_timestamp` for timing, `from_address` as the user identifier, `transaction_hash` for transaction reference, and standardized metadata fields for dimensional analysis

### Component B: Daily active user calculation
- **Purpose**: Aggregate transaction senders into daily unique active user counts
- **Logic**: This component processes the user facts to calculate Daily Active Users (DAU). It truncates the block timestamp to daily granularity and performs deduplication of user addresses within each day. Each unique address that initiated at least one transaction on a given day is counted as an active user for that day. The result includes the date, time granularity ('day'), chain information, user type, and the unique user address. This creates the foundation dataset for the rolling MAU calculation.
- **Key fields**: `timestamp` (truncated to day), `user_address` as the unique user identifier, `chain` for network identification, and `user_type` for categorization

### Component C: HyperLogLog sketch preparation
- **Purpose**: Convert daily user lists into HyperLogLog sketches for efficient approximate counting
- **Logic**: This component transforms the daily active user data into HyperLogLog (HLL) sketches to enable memory-efficient approximate unique counting. For each day and dimension combination (chain, user type, product), it initializes an HLL sketch with precision parameter 15. The HLL algorithm allows for approximate counting of unique elements with controllable accuracy, essential for handling large user datasets efficiently. The sketches are grouped by timestamp, chain, user type, and product ID to maintain dimensional breakdown capability.
- **Key fields**: `timestamp` for the date, `hll` containing the HyperLogLog sketch, and dimensional fields (`chain_id`, `user_type`, `product_id`) for breakdowns

### Component D: Rolling window datespine creation
- **Purpose**: Generate a continuous date range and create 30-day rolling window periods
- **Logic**: This component creates a datespine covering the full date range from the earliest available data to the previous day. For each date in this spine, it generates a 30-day window by creating an array of the 30 days ending on that date (current day plus previous 29 days). This ensures continuous time series coverage without gaps, even for days with no transaction activity. The result is a table where each row represents a date and its corresponding 30-day lookback period, enabling consistent MAU calculation across all dates.
- **Key fields**: `timestamp` for the target date and `joinday` representing each day within the 30-day window period

### Component E: Window-based HLL aggregation
- **Purpose**: Combine HLL sketches across 30-day rolling windows for MAU calculation
- **Logic**: This component joins the rolling window structure with the daily HLL sketches to create 30-day aggregation periods. For each target date, it collects the HLL sketches from all days within that date's 30-day window. The component preserves dimensional information (chain, user type, product ID) throughout the join process. This creates the foundation for merging HLL sketches across the rolling window period, enabling approximate unique user counting over the 30-day timeframe.
- **Key fields**: `timestamp` for the target date, `hll` sketches from each day in the window, and dimensional breakdown fields

### Final aggregation
- **Combining components**: The final MAU calculation merges HLL sketches within each 30-day window using the `hll_count.merge_partial()` function, then extracts the approximate unique count using `hll_count.extract()`. This provides the estimated number of unique users across the rolling 30-day period.
- **Dimensional breakdowns**: The metric is calculated across four dimensional views: project-level (overall aggregate), chain-level (by blockchain), user-type level (by user category), and product-level (by product ID). Each breakdown uses UNION ALL to combine results while maintaining distinct dimensional perspectives.
- **Time aggregation**: Daily boundary logic uses timestamp truncation to day granularity, with rolling 30-day windows calculated using interval arithmetic (current day minus 29 days to current day inclusive).
- **Final calculation**: For each date and dimensional combination, the MAU value represents the approximate count of unique transaction sender addresses that were active within the 30-day period ending on that date, calculated using merged HyperLogLog sketches for memory and computation efficiency.

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

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

XDC NetworkXDC

Active users (monthly)

Active users (monthly)

Competitive landscape