website

twitter

Blockchains (L2)

Humanity Protocol

# Humanity Protocol Active addresses (monthly) Methodology

## 1. Overview

Monthly active addresses measures the number of unique addresses that have sent at least one transaction on the Humanity blockchain within a rolling 30-day period. This metric provides insight into user engagement and adoption by tracking distinct wallet addresses that actively participate in the network through transaction activity. The calculation uses a rolling 30-day window approach with HyperLogLog probabilistic data structures for efficient distinct address counting.

## 2. Data sources

- **Humanity blockchain transactions**: Complete transaction records from the Humanity blockchain including sender addresses, timestamps, and transaction hashes
- **Transaction metadata**: Block timestamps for temporal grouping and transaction hashes for deduplication
- **Address data**: Transaction sender addresses (`from_address`) representing active user wallets

## 3. Step-by-step calculation

### Component A: User identification
- **Purpose**: Identify and classify active users from transaction data
- **Logic**: Extract all transaction records from Humanity blockchain data and identify each transaction's sender address as a user. Each `from_address` is classified as a "Transaction sender" user type and associated with the Humanity chain. The system assigns market sector as "blockchains_l2" and business segment as "blockchain" for categorization.
- **Key fields**: `from_address` becomes `user_address`, `block_timestamp` for timing, `transaction_hash` for uniqueness

### Component B: Daily active user calculation  
- **Purpose**: Calculate daily distinct active users from transaction activity
- **Logic**: Group transaction data by day using timestamp truncation to daily granularity. For each day, count distinct user addresses that sent transactions, creating daily snapshots of unique active addresses. Apply incremental processing with lookback periods to ensure data consistency when new transactions arrive.
- **Key fields**: `timestamp` (truncated to day), `user_address` as `user_dau`, `timestamp_grain` set to "day"

### Component C: Monthly rolling window creation
- **Purpose**: Generate 30-day rolling windows for monthly active address calculation
- **Logic**: Create a complete daily datespine covering the full time range of available data to ensure no gaps in the time series. For each day in the datespine, generate a 30-day lookback window by creating joins to the 30 preceding days (including the current day). This approach ensures every day has a complete 30-day window for analysis, even if some days had no transaction activity.
- **Key fields**: `timestamp` for the measurement date, `joinday` for each day within the 30-day window

### Component D: HyperLogLog aggregation
- **Purpose**: Efficiently calculate distinct user counts across 30-day rolling windows
- **Logic**: Apply HyperLogLog probabilistic data structures to enable efficient distinct counting across large datasets. Initialize HLL sketches for daily user data, then merge HLL sketches across each 30-day window to count distinct users. This approach provides approximate but highly accurate distinct counts while maintaining computational efficiency for large-scale data processing.
- **Key fields**: `hll` sketches containing user address data, merged and extracted to produce `user_mau` counts

### Component E: Dimensional breakdowns
- **Purpose**: Provide multiple aggregation levels for analytical flexibility  
- **Logic**: Calculate monthly active users across different dimensional breakdowns including project-level (project_dbt_tag), chain-level, user-type level, and product-level aggregations. Each breakdown uses the same HLL merging logic but groups data by different categorical dimensions. Combine all dimensional breakdowns using union operations to create a comprehensive dataset.
- **Key fields**: `dimensions` field indicating breakdown type, `chain_id`, `user_type`, `product_id` for grouping

### Final aggregation
- **Combining components**: The final model selects monthly active user counts from the dimensional breakdowns, specifically filtering for 'chain' and 'project_dbt_tag' dimensions to focus on the most relevant aggregation levels
- **Metric transformation**: Rename the `user_mau` field to `active_addresses_monthly` to align with standard naming conventions for address-based metrics
- **Time aggregation**: Maintain monthly granularity with rolling 30-day windows updated daily, ensuring each timestamp represents the count of distinct addresses active in the 30 days ending on that date  
- **Final calculation**: The final metric value represents the count of unique addresses that sent at least one transaction within the rolling 30-day period, calculated using HyperLogLog distinct counting methodology and presented at different dimensional levels

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

Unique addresses active over a rolling 30-day window.

Humanity ProtocolH

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape