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 (monthly) Methodology

## 1. Overview

Monthly active addresses measures the number of unique wallet addresses that initiated at least one transaction on the Scroll blockchain within a rolling 30-day period. This metric serves as a proxy for user engagement and network adoption, with each unique address representing a distinct user or entity interacting with the Scroll ecosystem. The calculation uses probabilistic data structures (HyperLogLog) to efficiently handle large-scale address counting across rolling time windows.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Scroll blockchain transactions**: Complete transaction records from the Scroll L2 network including transaction metadata, sender addresses, and execution details
- **Block timestamps**: Precise timing information for when each transaction was included in a block
- **Transaction sender addresses**: The `from_address` field identifying the wallet address that initiated each transaction

## 3. Step-by-step calculation

### Component A: User fact extraction
- **Purpose**: Extract and standardize user activity data from raw Scroll transactions
- **Logic**: Pull all transaction records from Scroll blockchain data, casting the block timestamp to timestamp format and transaction sender address (`from_address`) to string format. Each transaction sender is classified as a "Transaction sender" user type and tagged with Scroll chain metadata including market sector ("blockchains_l2") and business segment ("blockchain")
- **Key fields**: `block_timestamp` for timing, `from_address` for user identification, `transaction_hash` for transaction tracking

### Component B: Daily active user calculation  
- **Purpose**: Aggregate unique addresses to daily granularity
- **Logic**: For each calendar day, identify all distinct sender addresses that initiated transactions. Truncate block timestamps to day boundaries and group by the resulting date. Extract unique addresses per day along with metadata like chain, user type, and product classifications
- **Key fields**: `timestamp` (truncated to day), `user_address` (renamed from `user_dau`), chain and classification metadata

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily address lists into probabilistic data structures for efficient aggregation
- **Logic**: Transform daily distinct address counts into HyperLogLog sketches using precision parameter 15. This creates compact probabilistic representations that can be merged across time periods while maintaining reasonable accuracy for distinct counting. Group sketches by timestamp, chain, user type, and product dimensions
- **Key fields**: `hll` (the HyperLogLog sketch), timestamp and dimensional grouping fields

### Component D: Rolling window construction
- **Purpose**: Create 30-day rolling windows for monthly active address calculation
- **Logic**: Generate a complete datespine covering the full time range of available data. For each date in the spine, create associations with the previous 29 days plus the current day (30 days total). This creates overlapping windows where each day participates in multiple monthly calculations. Handle missing dates by ensuring continuous coverage through the datespine
- **Key fields**: `timestamp` (target date), `joinday` (dates within the 30-day window)

### Component E: Window aggregation
- **Purpose**: Merge HyperLogLog sketches across 30-day windows
- **Logic**: For each target date, combine all HyperLogLog sketches from the associated 30-day window using `hll_count.merge_partial()`. This probabilistic merging preserves the distinct count property across the time window while handling overlapping addresses efficiently. Maintain dimensional breakdowns during aggregation
- **Key fields**: `timestamp` (window end date), `hll` (merged sketch for the window)

### Component F: Dimensional breakdown
- **Purpose**: Calculate monthly active addresses across different analytical dimensions
- **Logic**: Extract final distinct address counts from merged HLL sketches using `hll_count.extract()`. Create separate breakdowns for chain-level analysis ("chain" dimension), project-level analysis ("project_dbt_tag" dimension), user-type analysis, and product-level analysis. Each breakdown aggregates the appropriate dimensional fields while nulling out others
- **Key fields**: `user_mau` (extracted distinct count), `dimensions` (breakdown type), relevant dimensional fields

### Final aggregation
- **Combining components**: Union all dimensional breakdowns into a single result set, with each row representing monthly active addresses for a specific dimension and time period
- **Currency conversion**: Not applicable for this address-counting metric
- **Time aggregation**: Rolling 30-day windows calculated for each calendar day, providing daily snapshots of monthly activity
- **Final calculation**: Filter for chain-level and project-level dimensions only, rename `user_mau` to `active_addresses_monthly` to reflect that addresses serve as user proxies, apply schema standardization and zero-filling for missing periods through the finalization macro

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

Unique addresses active over a rolling 30-day window.

ScrollSCR

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown