Scroll batches users' transactions and submits them to Ethereum, paying a share of the transaction fees to Ethereum validators (expense).

Scroll is an L2 smart contract platform for decentralized applications on Ethereum. Scroll was founded by Sandy Peng, Haichen Shen, and Ye Zhang and launched in 2023.

SCR tokenholders own and govern the protocol. Scroll's investors include Polychain, Qiming Venture Partners, etc.

github

twitter

discord

website

Blockchains (L2)

Scroll

# Scroll Active addresses (weekly) Methodology

## 1. Overview

Weekly active addresses measures the number of unique addresses that have sent at least one transaction on the Scroll blockchain during a rolling 7-day period. This metric serves as a key indicator of blockchain network activity and user engagement. The calculation uses a rolling window approach where each day's count includes unique addresses that were active on that day or any of the previous 6 days. The metric employs HyperLogLog probabilistic counting for efficient computation of unique address counts across large datasets.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Scroll blockchain transactions**: Complete transaction records from the Scroll L2 blockchain, including transaction metadata and execution details
- **Transaction sender addresses**: The `from_address` field from each transaction, identifying the address that initiated and signed the transaction
- **Block timestamps**: Precise timestamps for each block containing the transactions, used to determine daily boundaries and rolling windows
- **Chain metadata**: Scroll network identification and classification as an L2 blockchain in the "blockchains_l2" market sector

## 3. Step-by-step calculation

### Component A: User activity extraction
- **Purpose**: Identify daily user activity from Scroll blockchain transactions
- **Logic**: Extract all transaction sender addresses from Scroll transaction records. Each transaction's `from_address` represents an active user for that block's timestamp. Transaction metadata includes `transaction_hash`, `block_timestamp`, and sender address. The system classifies all transaction senders as "Transaction sender" user type within the "blockchain" business segment.
- **Key fields**: `from_address` (transaction sender), `block_timestamp` (activity timestamp), `transaction_hash` (unique transaction identifier)

### Component B: Daily active user calculation  
- **Purpose**: Calculate daily distinct active users (DAU) from transaction activity
- **Logic**: Group transaction data by day using timestamp truncation to daily granularity. For each day, count distinct sender addresses to identify unique daily active users. Each unique `user_address` on a given day becomes a `user_dau` record. The system maintains incremental processing with lookback periods to ensure data freshness and handle late-arriving transactions.
- **Key fields**: `timestamp` (daily boundary), `user_address` (unique daily active address), `chain` (Scroll identifier)

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily user sets into probabilistic data structures for efficient weekly aggregation
- **Logic**: Transform daily active user records into HyperLogLog (HLL) sketches with precision parameter 15. Each day's unique user addresses are initialized into an HLL sketch that enables efficient approximate counting when merging multiple days. This approach handles large user sets while maintaining acceptable accuracy for unique count calculations.
- **Key fields**: `timestamp` (daily boundary), `hll` (HyperLogLog sketch), `chain_id` (network identifier)

### Component D: Rolling window generation
- **Purpose**: Create 7-day rolling windows for weekly active user calculation
- **Logic**: Generate a complete datespine covering all days from the earliest available data to yesterday. For each date in the spine, create a 7-day window spanning from 6 days prior through the current date. This produces a `jointables` structure where each target date maps to 7 specific days that should contribute to its weekly count. The datespine ensures no days are skipped and handles missing data consistently.
- **Key fields**: `timestamp` (target date), `joinday` (contributing dates within the 7-day window)

### Component E: Weekly aggregation with HLL merging
- **Purpose**: Calculate weekly active users by merging HLL sketches across 7-day windows
- **Logic**: Join the rolling window structure with daily HLL sketches to collect all relevant daily user sets for each week. For each target date, gather HLL sketches from the corresponding 7-day window. Merge these HLL sketches using `hll_count.merge_partial()` to combine user sets while maintaining uniqueness. Extract the final unique count using `hll_count.extract()` to get the weekly active user total.
- **Key fields**: `timestamp` (week ending date), `user_wau` (weekly active user count)

### Component F: Dimensional breakdowns
- **Purpose**: Provide weekly active user metrics across different analytical dimensions
- **Logic**: Calculate weekly active users separately for different breakdown levels: chain-level aggregation for network-wide metrics, project_dbt_tag-level for project-wide analysis, user_type-level for user classification analysis, and product_id-level for product-specific metrics. Each breakdown maintains the same HLL merging logic but groups by different dimensional attributes.
- **Key fields**: `dimensions` (breakdown type), `chain_id`, `user_type`, `product_id` (dimensional attributes)

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single result set with consistent schema. Filter to include only 'chain' and 'project_dbt_tag' dimensions for the active addresses metric.
- **Terminology mapping**: Rename `user_wau` field to `active_addresses_weekly` to reflect blockchain-specific terminology where addresses represent active network participants.
- **Time aggregation**: Each daily timestamp represents the end date of a 7-day rolling window. Weekly counts include unique addresses active on that date or any of the previous 6 days.
- **Final calculation**: The final metric value represents the count of unique addresses that sent at least one transaction during the 7-day period ending on each date, calculated using HyperLogLog approximate counting with high precision.

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

Unique active addresses over a rolling 7-day window.

ScrollSCR

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape

Chain breakdown