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

## 1. Overview

Monthly Active Users (MAU) measures the number of unique addresses that conducted transactions on the Starknet network within a rolling 30-day period. This metric provides insight into user engagement and adoption of the Starknet Layer 2 ecosystem. The calculation uses HyperLogLog probabilistic data structures to efficiently handle the overlapping user sets across the 30-day rolling windows, ensuring accurate distinct user counts while managing computational complexity.

## 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, timestamps, and metadata
- **Transaction execution data**: Sender addresses, transaction types, and execution status information
- **Transaction receipts**: Receipt events, actual fees paid, and fee units 
- **Address information**: Both sender addresses from transaction initiation and recipient addresses from transaction events

## 3. Step-by-step calculation

### Component A: Transaction data extraction
- **Purpose**: Extract and standardize raw Starknet transaction data for user identification
- **Logic**: Raw Starknet blockchain transactions are processed to identify key transaction attributes. The system extracts sender addresses from transaction initiation data and recipient addresses from the first event in transaction receipts when available. Transaction fees are converted from Wei to ETH units by dividing by 1e18. All transactions are labeled with Starknet chain identifier and classified under the Layer 2 blockchains market sector. Transaction types are preserved to enable segmentation by user activity type.
- **Key fields**: Block timestamp (`block_timestamp`), transaction hash (`transaction_hash`), sender address (`sender_address`), transaction type (`transaction_type`), actual fee amount (`actual_fee_amount`), receipt events (`receipt_events`)

### Component B: Daily active user calculation  
- **Purpose**: Calculate daily unique users from transaction activity
- **Logic**: Transaction data is aggregated by day using timestamp truncation to the day boundary. For each day, unique user addresses are identified by taking the union of sender addresses and recipient addresses (when available from transaction events). Users are defined as any address that either initiated a transaction or received activity as evidenced in transaction events. The data is grouped by day, chain, transaction type (user type), and product identifiers to enable dimensional analysis. Each unique address-day-type combination represents one daily active user record.
- **Key fields**: Daily timestamp (`timestamp`), chain identifier (`chain`), user type (`user_type`), unique user address (`user_dau`), product identifier (`product_id`)

### Component C: HyperLogLog structure creation
- **Purpose**: Convert daily user data into probabilistic data structures for efficient MAU calculation
- **Logic**: Daily active user data is transformed into HyperLogLog (HLL) data structures with a precision parameter of 15. Each day's unique user set is initialized as an HLL structure, preserving the ability to perform set union operations across multiple days while maintaining memory efficiency. The HLL structures are grouped by timestamp, chain, user type, and product dimensions to maintain proper segmentation throughout the aggregation process.
- **Key fields**: HLL structure (`hll`), timestamp (`timestamp`), chain identifier (`chain_id`), user type (`user_type`), product identifier (`product_id`)

### Component D: Rolling window generation
- **Purpose**: Create 30-day rolling windows for each date in the analysis period
- **Logic**: A complete datespine is generated covering all dates from the earliest transaction date to the current date minus one day. For each date in this spine, a 30-day lookback window is created by generating an array of the 30 preceding days (including the current date). This creates a cartesian join between target dates and their respective 30-day windows, ensuring every possible MAU calculation period is captured even when no transactions occurred on specific days.
- **Key fields**: Target timestamp (`timestamp`), window day (`joinday`)

### Component E: Window data assembly
- **Purpose**: Connect rolling windows with daily HLL user data
- **Logic**: The 30-day rolling windows are joined with the daily HLL user structures to assemble all user data needed for each MAU calculation. Each target date is matched with its corresponding 30-day window, and each day in that window is joined with the daily HLL data from Component C. This creates a dataset where each target date has associated with it all the daily user HLL structures from its 30-day lookback period.
- **Key fields**: Target timestamp (`timestamp`), daily HLL structures (`hll`), dimensional attributes (`chain_id`, `user_type`, `product_id`)

### Final aggregation
- **Combining components**: For each target date and dimensional combination, all HLL structures from the 30-day window are merged using HLL partial merge operations, then the final distinct count is extracted to produce the MAU value
- **Currency conversion**: No currency conversion is required as this metric counts users, not monetary values
- **Time aggregation**: MAU is calculated as a rolling 30-day window for each date, with the metric representing unique users active within the 30 days ending on that date
- **Final calculation**: The MAU value is computed by merging all HLL structures within each 30-day window using `hll_count.merge_partial()`, then extracting the estimated distinct count using `hll_count.extract()`. Results are segmented across multiple dimensions including project level (all dimensions combined), chain level, user type level (by transaction type), and product level, with missing dimensional values filled as nulls and missing date values filled with zeros.

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

Unique revenue-generating users over a rolling 30-day window.

StarknetSTRK

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown