website

twitter

discord

github

Blockchains (L1)

Sonic

# Sonic Active addresses (monthly) Methodology

## 1. Overview

Sonic active addresses monthly measures the number of unique addresses that sent at least one transaction on the Sonic blockchain within a 30-day rolling window, calculated on a daily basis. This metric provides insight into the monthly user activity and engagement on the Sonic network by tracking distinct transaction senders over time. The calculation uses HyperLogLog probabilistic counting to efficiently handle the computational complexity of tracking unique users across overlapping monthly periods.

## 2. Data sources

The methodology relies on the following raw data sources:

- **Sonic blockchain transaction records**: Complete transaction data from the Sonic blockchain including transaction hashes, block timestamps, and sender addresses
- **Transaction metadata**: Temporal information (block timestamps) used to aggregate activity by daily and monthly periods

## 3. Step-by-step calculation

### Component A: User identification and classification
- **Purpose**: Extract and classify unique user addresses from raw transaction data
- **Logic**: From raw Sonic blockchain transactions, extract the sender address (`from_address`) as the primary user identifier. Each transaction sender is classified as user type "Transaction sender" and the data is categorized under the "blockchains_l1" market sector and "blockchain" business segment. The system captures the transaction timestamp (`block_timestamp`) and transaction hash for traceability.
- **Key fields**: `user_address` (from `from_address`), `block_timestamp`, `transaction_hash`, `user_type`, `chain`

### Component B: Daily active user calculation  
- **Purpose**: Calculate daily distinct active users from transaction activity
- **Logic**: Group all transaction data by day using timestamp truncation to day granularity. For each day, identify all distinct user addresses who sent at least one transaction, creating a daily list of unique active users. This includes the timestamp grain as "day" and preserves dimensional information like chain, user type, and product categorization.
- **Key fields**: `timestamp` (truncated to day), `user_dau` (distinct user addresses), `timestamp_grain`, `chain`, `user_type`

### Component C: Monthly active user aggregation with rolling windows
- **Purpose**: Calculate monthly active users using a 30-day rolling window approach with probabilistic counting
- **Logic**: Create HyperLogLog (HLL) sketches for each day's active users to enable efficient probabilistic counting. Build a date spine covering the full time range and create 30-day rolling windows (29 days prior plus current day) for each date. For each window, merge the HLL sketches from all days in the window to count distinct users across the entire 30-day period. This approach handles overlapping periods efficiently while maintaining accuracy for large user counts.
- **Key fields**: `user_mau` (extracted from merged HLL sketches), `timestamp`, `chain_id`, `user_type`, `product_id`

### Component D: Dimensional breakdown creation
- **Purpose**: Create multiple dimensional views of monthly active users
- **Logic**: Generate separate breakdowns of the MAU data across four dimensions: by chain (Sonic-specific metrics), by project_dbt_tag (overall project-level aggregation), by user_type (Transaction sender breakdown), and by product_id (product-level breakdown, null for blockchain metrics). Each dimension uses the same HLL merging logic but groups and nullifies different dimensional fields to create focused views.
- **Key fields**: `dimensions` (indicating breakdown type), `user_mau`, dimension-specific fields (`chain_id`, `user_type`, `product_id`)

### Final aggregation
- **Combining components**: The final model takes the monthly active user data and filters for only "chain" and "project_dbt_tag" dimensions, as these represent the primary active addresses breakdowns needed for blockchain-level metrics
- **Metric conversion**: Rename the `user_mau` field to `active_addresses_monthly` to align with the target metric naming convention, maintaining the same underlying calculation logic
- **Time aggregation**: Preserve the daily calculation frequency with 30-day rolling windows, where each day represents the count of unique addresses active in the trailing 30-day period
- **Schema standardization**: Apply the finalize_metric macro to ensure consistent schema structure and fill any missing days with zero values to maintain continuous time series data
- **Data availability filtering**: Apply chain availability filters to exclude periods where Sonic blockchain data may be incomplete or unreliable

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

Unique addresses active over a rolling 30-day window.

SonicS

Archived

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape