Starknet is a Validity-Rollup (ZK-Rollup) Layer 2 network that operates on top of Ethereum, enabling dApps to massively scale without compromising on security. It achieves this by bundling transactions into an off-chain computed STARK proof. This proof is then submitted to Ethereum as a single transaction, resulting in significantly higher throughput, faster processing times, and much lower costs, all while retaining the robust security of the Ethereum settlement layer.

Starknet aims to be governed by a decentralized, community-driven process centered around STRK token holders. While StarkWare originally developed the technology, the network is transitioning to a completely decentralized model where the broader community makes decisions regarding protocol upgrades, development, and the future of the network.

Starknet is a Layer 2 that uses STARK technology to validate off-chain transactions, enabling unlimited scale while preserving Ethereum's security and decentralization.

github

twitter

discord

etherscan

website

governance

Blockchains (L2)

Starknet

# Starknet Active addresses (monthly) Methodology

## 1. Overview

Monthly active addresses measures the number of unique addresses that have been active on the Starknet network within a rolling 30-day period. This metric provides insight into user engagement and network adoption by tracking distinct addresses that either send transactions or receive transfers. For blockchain networks like Starknet, active addresses serve as a proxy for active users, since each address typically represents a unique participant in the network.

The calculation uses a rolling 30-day window approach with HyperLogLog sketches for efficient approximate distinct counting, ensuring accurate deduplication of addresses that are active across multiple days within the measurement period.

## 2. Data sources

The calculation relies on the following raw data sources:

- **Starknet transaction data**: Complete transaction records from the Starknet blockchain including transaction hashes, sender addresses, transaction types, timestamps, and gas fees
- **Starknet event logs**: Transaction receipt events containing recipient address information and event data
- **Block timestamp data**: Starknet block-level timestamp information for temporal aggregation

## 3. Step-by-step calculation

### Component A: Daily transaction processing
- **Purpose**: Extracts and processes all Starknet transactions to identify daily active addresses
- **Logic**: Processes raw Starknet transaction data by extracting sender addresses directly from transaction records and recipient addresses from the first event in transaction receipts. Converts transaction timestamps to daily boundaries using timestamp truncation. Assigns transaction types and enriches with metadata including chain identifier, market sector, and business segment classifications. Converts gas fees to ETH denomination by dividing actual fees by 1e18
- **Key fields**: `block_timestamp` for temporal grouping, `sender_address` for transaction initiators, `to_address` derived from receipt events for recipients, `transaction_type` for user categorization

### Component B: Daily active user identification  
- **Purpose**: Identifies unique active addresses for each day from transaction data
- **Logic**: Combines sender and recipient addresses using COALESCE logic to capture all addresses that participated in network activity on each day. Groups data by daily timestamp boundaries and applies distinct counting to eliminate duplicates within each day. Categorizes users by transaction type and maintains dimensional attributes including chain, product, and user type classifications
- **Key fields**: `timestamp` truncated to day level, `user_dau` containing distinct active addresses, `user_type` from transaction classification, `chain` identifier

### Component C: HyperLogLog sketch creation
- **Purpose**: Creates efficient data structures for approximate distinct counting across large datasets
- **Logic**: Initializes HyperLogLog sketches for each day's active address set with precision parameter 15 for optimal accuracy-performance balance. Groups sketches by timestamp, chain, user type, and product dimensions to enable flexible aggregation. HLL sketches enable memory-efficient storage and fast merging operations for rolling window calculations
- **Key fields**: `hll` sketches containing compressed address sets, dimensional grouping fields for aggregation flexibility

### Component D: Rolling window generation
- **Purpose**: Creates 30-day rolling windows for monthly active user calculation
- **Logic**: Generates a complete datespine covering the full analysis period to ensure no missing days in calculations. For each day in the datespine, creates a 30-day lookback window including the current day plus the previous 29 days using timestamp array generation. Joins rolling window dates with daily HLL sketches to create the data structure needed for MAU aggregation
- **Key fields**: `timestamp` for the calculation date, `joinday` for days within each rolling window, joined HLL sketches for aggregation

### Component E: Monthly active user calculation
- **Purpose**: Calculates distinct active addresses across each 30-day rolling window
- **Logic**: Merges HyperLogLog sketches across each 30-day window to combine all unique addresses while avoiding double-counting addresses active on multiple days. Extracts final distinct counts from merged sketches to produce MAU values. Groups results by multiple dimensional breakdowns including chain-level, project-level, user type, and product aggregations to enable flexible analysis
- **Key fields**: `user_mau` containing distinct address counts, dimensional fields for breakdown analysis

### Final aggregation
- **Combining components**: Selects MAU results filtered to chain and project dimensions, then renames the `user_mau` field to `active_addresses_monthly` to reflect blockchain-specific terminology where addresses represent active users
- **Currency conversion**: Not applicable for this address-counting metric
- **Time aggregation**: Uses rolling 30-day windows calculated daily, providing continuous monthly measurements rather than discrete calendar months
- **Final calculation**: The final metric represents the count of unique addresses that have been active (either sending or receiving) on Starknet within any rolling 30-day period, broken down by chain and project dimensions with zero-filling applied for missing periods

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

Unique addresses active over a rolling 30-day window.

StarknetSTRK

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown