website

github

twitter

Blockchains (L1)

XDC Network

# XDC Network Active addresses (monthly) Methodology

## 1. Overview

Monthly active addresses measures the number of unique addresses that initiated at least one transaction on the XDC blockchain within a rolling 30-day window. This metric uses a sliding window approach where each day represents the count of distinct addresses that were active in the current day plus the previous 29 days. The calculation employs HyperLogLog probabilistic data structures to efficiently approximate distinct address counts across large datasets, making it suitable for blockchain-scale data processing.

## 2. Data sources

The calculation relies on the following raw data sources:

- **XDC blockchain transaction records**: Complete transaction history from the XDC blockchain containing transaction hashes, sender addresses, recipient addresses, and block metadata
- **Block timestamps**: Timestamp information from XDC blocks to enable daily time-series aggregation
- **Transaction sender addresses**: The `from_address` field from each transaction, representing the address that initiated the transaction

## 3. Step-by-step calculation

### Component A: User fact table creation
- **Purpose**: Extract and standardize transaction sender information from raw XDC blockchain data
- **Logic**: The system processes raw XDC transaction records and extracts transaction senders (the `from_address` field from each transaction). Each record includes the block timestamp, transaction hash, and sender address. The data is enriched with metadata classifying XDC as a Layer 1 blockchain in the blockchains market sector. Transaction senders are labeled as "Transaction sender" user types since they represent addresses actively initiating transactions.
- **Key fields**: `block_timestamp` (transaction timing), `from_address` (transaction sender), `transaction_hash` (unique transaction identifier), and standardized metadata fields for chain classification

### Component B: Daily active users calculation  
- **Purpose**: Calculate the number of distinct active addresses for each day
- **Logic**: The system groups transaction sender data by day using timestamp truncation to the day level. For each day, it counts the distinct number of unique addresses that initiated at least one transaction. The calculation uses an exact distinct count at the daily level before converting to probabilistic sketches for monthly aggregation. Incremental processing includes a lookback window to ensure data completeness during updates.
- **Key fields**: `timestamp` (day-level), `user_address` (distinct transaction senders), `chain` (XDC identifier), and dimensional metadata for further breakdown analysis

### Component C: HyperLogLog sketch creation
- **Purpose**: Create probabilistic data structures to enable efficient distinct counting across sliding windows
- **Logic**: For each day's distinct active addresses, the system creates HyperLogLog sketches using BigQuery's `hll_count.init` function with precision parameter 15. These sketches provide approximate distinct counts that can be efficiently merged across time periods. The sketches preserve the ability to combine data from multiple days while maintaining reasonable accuracy for large-scale distinct counting operations.
- **Key fields**: `hll` (HyperLogLog sketch data), `timestamp` (daily granularity), and associated dimensional metadata

### Component D: Sliding window construction
- **Purpose**: Build 30-day rolling windows for each day to calculate monthly active addresses
- **Logic**: The system creates a complete datespine covering all days from the earliest available data to the current date. For each day in the datespine, it constructs a 30-day window by joining with the current day plus the previous 29 days of data. This sliding window approach ensures that each day's monthly active address count represents the distinct addresses active within that 30-day period. The window construction handles missing days and ensures continuous coverage.
- **Key fields**: `timestamp` (target day), `joinday` (days within the 30-day window), and corresponding HLL sketch data for each day in the window

### Component E: Monthly aggregation with HLL merging
- **Purpose**: Combine HLL sketches across each 30-day window to calculate approximate monthly distinct addresses
- **Logic**: For each 30-day sliding window, the system merges the HLL sketches from all days within that window using BigQuery's `hll_count.merge_partial` function. The merged sketch is then extracted to produce an approximate count of distinct addresses active within that 30-day period. This approach efficiently handles the complexity of counting distinct addresses across overlapping time periods while maintaining computational efficiency for large datasets.
- **Key fields**: `user_mau` (monthly active users count), `timestamp` (day representing the end of the 30-day window), and dimensional breakdown fields

### Component F: Dimensional breakdowns
- **Purpose**: Create monthly active address counts across different analytical dimensions
- **Logic**: The system generates multiple views of the monthly active address data by grouping across different dimensions including project level (all XDC activity), chain level (XDC-specific metrics), user type level (transaction senders), and product level (blockchain activity). Each dimensional breakdown uses the same sliding window HLL merging logic but aggregates data at different levels to support various analytical use cases.
- **Key fields**: `dimensions` (breakdown category), `chain_id`, `product_id`, `user_type`, and the corresponding `user_mau` count for each dimension

### Final aggregation
- **Combining components**: The various dimensional breakdowns are combined using union operations to create a comprehensive dataset containing monthly active address counts across all analytical dimensions. Each row represents a specific day and dimensional combination with the corresponding 30-day active address count.
- **Schema standardization**: The finalization macro applies consistent schema structure, handles missing data by filling gaps with zero values, and ensures proper data typing and formatting across all dimensional breakdowns.
- **Metric labeling**: In the final step, the monthly active users metric is relabeled as "monthly active addresses" since transaction senders represent the active addresses on the blockchain. This semantic transformation reflects that in blockchain analytics, active users and active addresses are equivalent concepts when measuring transaction-initiating addresses.
- **Time boundaries**: The sliding window calculation uses day-level granularity with each day representing the endpoint of a 30-day rolling window. The system maintains monthly partitioning for efficient data processing while providing daily resolution in the final output.
- **Final calculation**: Each day's monthly active address count represents the approximate number of distinct addresses that initiated at least one transaction within the 30-day period ending on that day, calculated using merged HyperLogLog sketches for computational efficiency.

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

Unique addresses active over a rolling 30-day window.

XDC NetworkXDC

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape