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

Subsocial is a social platform powered by Polkadot Relay chain.

website

twitter

github

discord

etherscan

Blockchains (L2)

Subsocial

# Subsocial Active addresses (monthly) Methodology

## 1. Overview

Monthly active addresses measures the number of unique addresses that have submitted transactions on the Subsocial network within a rolling 30-day period, calculated daily. This metric tracks user engagement on Subsocial's dual-layer architecture, counting both native Substrate transactions and EVM-compatible transactions. The calculation uses HyperLogLog probabilistic counting for efficient computation of distinct addresses across large datasets.

## 2. Data sources

The calculation uses the following raw blockchain data sources:
- **Subsocial extrinsics**: Native Substrate-based transaction records containing sender IDs for all transactions on the Subsocial parachain
- **Subsocial EVM events**: Event logs from the EVM pallet tracking `Executed` events with user addresses from EVM-compatible transactions
- **Subsocial blockchain metadata**: Block timestamps and transaction context for both native and EVM layers

## 3. Step-by-step calculation

### Component A: User activity extraction
- **Purpose**: Identify all unique user addresses from both native Subsocial and EVM transaction layers
- **Logic**: Extract user addresses from two distinct data streams. For native Subsocial transactions, the `id` field from extrinsics contains the transaction sender address. For EVM compatibility layer transactions, parse the first element of `event_data` array from `evm.Executed` events to extract the user address. Union these two address streams, treating them as separate chains (`subsocial` and `subsocialevm`) with standardized metadata including market sector as `blockchains_l2`, business segment as `blockchain`, and user type as `Transaction sender`. Filter data to exclude future dates beyond August 13, 2025.
- **Key fields**: `block_timestamp` for timing, `id` for native addresses, `event_data[0]` for EVM addresses, `user_address` for standardized output

### Component B: Daily active user aggregation  
- **Purpose**: Create daily snapshots of unique active users across both Subsocial chains
- **Logic**: Group user addresses by day using timestamp truncation to daily granularity. For each day, collect all distinct `user_address` values along with their associated chain, user type, and product metadata. This creates daily active user (DAU) records that serve as the foundation for monthly calculations. Apply chain availability filtering and enforce the same temporal boundary of August 13, 2025.
- **Key fields**: `timestamp` truncated to day, `user_dau` containing the unique address, `chain` distinguishing native vs EVM layers

### Component C: HyperLogLog initialization and windowing
- **Purpose**: Prepare efficient data structures for counting distinct users across rolling 30-day periods
- **Logic**: Initialize HyperLogLog sketches for each day's unique user set, allowing probabilistic counting of distinct addresses with high accuracy and low memory usage. Create a comprehensive datespine covering all days from the earliest user activity to present. For each day in the datespine, generate a 30-day lookback window by creating timestamps for the current day and previous 29 days. Join this windowed datespine to the daily HLL sketches, effectively creating overlapping 30-day periods for each day.
- **Key fields**: `hll` sketches containing user sets, `timestamp` for current day, `joinday` for window boundaries

### Component D: Monthly active user calculation by dimension
- **Purpose**: Calculate 30-day rolling unique user counts across different analytical dimensions
- **Logic**: For each 30-day window, merge all HLL sketches within that period and extract the distinct count, representing users active in the rolling 30-day period. Create four separate dimensional breakdowns: project-level aggregation (combining all chains and user types), chain-level aggregation (separating `subsocial` and `subsocialevm`), user-type-level aggregation (currently only `Transaction sender`), and product-level aggregation (currently null for Subsocial). Each breakdown uses HLL merge operations to combine daily sketches and extract final distinct counts as `user_mau`.
- **Key fields**: `dimensions` indicating breakdown type, `chain_id` for chain-specific metrics, `user_mau` containing the 30-day distinct user count

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single dataset containing project-level, chain-level, user-type-level, and product-level monthly active user metrics
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Uses rolling 30-day windows calculated daily, with each day representing the count of unique users active in the trailing 30-day period
- **Final calculation**: Rename the `user_mau` field to `active_addresses_monthly` since users are identified by their blockchain addresses. Apply the `finalize_metric_active_addresses_monthly` macro to standardize schema, apply proper data types, and fill missing time periods with zero values. Filter results to include only `chain` and `project_dbt_tag` dimensional breakdowns for the final output, representing both chain-specific and project-wide monthly active address counts.

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

Unique addresses active over a rolling 30-day window.

SubsocialSUB

Archived

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown