twitter

etherscan

website

Blockchains (L2)

Unichain

# Unichain Active addresses (weekly) Methodology

## 1. Overview

Weekly active addresses for Unichain measures the number of unique addresses that initiated at least one transaction on the Unichain network during any rolling 7-day period. This metric answers the business question "How many distinct users are actively transacting on Unichain each week?" and uses a rolling window approach with probabilistic counting to efficiently calculate approximate distinct user counts across weekly periods.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Unichain transaction records**: Complete transaction data from the Unichain blockchain, including transaction metadata, sender addresses, timestamps, and transaction hashes
- **HyperLogLog probabilistic counting algorithm**: A space-efficient probabilistic data structure used for approximating distinct counts of large datasets
- **Token Terminal's data quality filters**: Chain availability and data completeness validation systems that ensure reliable metric calculation

## 3. Step-by-step calculation

### Component A: User identification and extraction
- **Purpose**: Extract and classify user addresses from Unichain transaction data
- **Logic**: Transaction sender addresses are identified from the `from_address` field in Unichain transaction records. Each address is classified with metadata including chain identifier ('unichain'), market sector ('blockchains_l2'), business segment ('blockchain'), and user type ('Transaction sender'). Block timestamps are converted to standard timestamp format for temporal processing.
- **Key fields**: `from_address` becomes `user_address`, `block_timestamp` for time-based analysis, `transaction_hash` for transaction identification

### Component B: Daily active user calculation
- **Purpose**: Calculate distinct active users for each calendar day
- **Logic**: For each calendar day, transaction data is processed to identify unique user addresses that initiated transactions. Timestamps are truncated to day boundaries to ensure proper daily aggregation. Each unique user address per day is initialized into a HyperLogLog sketch with precision 15 for efficient distinct counting. The process includes incremental loading with lookback periods for data freshness.
- **Key fields**: `timestamp` truncated to day, `user_address` for distinct counting, `user_dau` containing the user identifier

### Component C: Rolling weekly window creation
- **Purpose**: Generate 7-day rolling windows for weekly active user calculation
- **Logic**: A datespine is created covering all calendar days from the earliest transaction date to the current date. For each day in the datespine, a 7-day rolling window is constructed by joining that day with the previous 6 days. This creates overlapping weekly periods where each day serves as the end date for a weekly calculation. The window ensures no missing timestamps are skipped in the weekly aggregation.
- **Key fields**: `timestamp` as the end date of each weekly period, `joinday` representing each day within the 7-day window

### Component D: HyperLogLog aggregation across weekly windows
- **Purpose**: Merge daily HyperLogLog sketches to calculate weekly distinct user counts
- **Logic**: For each 7-day rolling window, the HyperLogLog sketches from all 7 days are merged using probabilistic union operations. The merged sketch is then extracted to produce an approximate count of distinct users who were active during any day within that 7-day period. This approach efficiently handles overlapping users across multiple days while maintaining space efficiency for large user sets.
- **Key fields**: `hll` representing merged HyperLogLog sketches, `user_wau` containing the weekly active user count

### Component E: Multi-dimensional breakdown
- **Purpose**: Segment weekly active users across different analytical dimensions
- **Logic**: The weekly active user data is broken down into four analytical dimensions through separate aggregation paths: chain-level (preserving `chain_id`), project-level (tagged as 'project_dbt_tag'), user-type-level (preserving `user_type`), and product-level (preserving `product_id`). Each breakdown maintains its relevant dimension fields while nullifying others. All breakdowns are combined using UNION ALL operations to create a comprehensive multi-dimensional dataset.
- **Key fields**: `dimensions` indicating the breakdown level, `chain_id`, `user_type`, `product_id` as dimension identifiers

### Final aggregation
- **Combining components**: The weekly active user calculations are filtered to include only chain-level and project-level dimensions, excluding user-type and product-level breakdowns for the active addresses metric
- **Currency conversion**: No currency conversion is required as this metric counts addresses rather than monetary values
- **Time aggregation**: Weekly periods use 7-day rolling windows where each day serves as the endpoint for a weekly calculation, ensuring continuous weekly coverage without gaps
- **Final calculation**: The `user_wau` field is renamed to `active_addresses_weekly` to reflect the metric's focus on unique addresses rather than users, with chain availability filters applied to ensure data quality and completeness

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

Unique active addresses over a rolling 7-day window.

UnichainUNI

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape

Chain breakdown