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 Average revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) measures the daily revenue generated per active user on the Starknet Layer 2 network. This metric is calculated by dividing total daily revenue by the number of daily active users. The metric helps assess user monetization and network economic efficiency. Revenue is derived from transaction fees paid by users, while active users are identified as unique addresses that send or receive transactions each day.

## 2. Data sources

The ARPU calculation relies on the following data sources:
- **Starknet transaction records**: Complete transaction data including transaction hashes, block timestamps, sender addresses, recipient addresses, transaction fees, and fee denomination units
- **End-of-day token price feeds**: Daily USD prices for WETH (Wrapped Ethereum) and STRK (Starknet's native token) used for fee conversion
- **Token metadata**: Contract addresses and decimal specifications for WETH (`0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2`) and STRK (`0xca14007eff0db1f8135f4c25b34de49ab0d42766`) tokens

## 3. Step-by-step calculation

### Component A: Transaction data extraction
- **Purpose**: Extract and standardize all Starknet transaction data for fee and user analysis
- **Logic**: All transactions are extracted from Starknet blockchain records with their block timestamps, transaction hashes, sender addresses, and fee information. Transaction fees are recorded with their original fee units (WEI for WETH or FRI for STRK). The `actual_fee_amount` is calculated by dividing the raw `receipt_actual_fee` by 10^18 to normalize decimal places. Recipient addresses are extracted from the first event in the `receipt_events` array when available.
- **Key fields**: `block_timestamp` for daily grouping, `sender_address` for user identification, `actual_fee_amount` for fee calculation, `actual_fee_unit` for token identification, and derived `to_address` for recipient identification

### Component B: Daily fee aggregation
- **Purpose**: Aggregate transaction fees by day and convert to USD value
- **Logic**: Transaction fees are grouped by day and token type. The `actual_fee_unit` field is mapped to specific token addresses: WEI units correspond to WETH token and FRI units correspond to STRK token. Daily fee totals are calculated by summing `actual_fee_amount` for each token on each day. These token-denominated fee amounts are then converted to USD using end-of-day token price feeds through the conversion process.
- **Key fields**: Daily `timestamp`, `token_address` (WETH or STRK), and `fees` (aggregated fee amounts)

### Component C: Daily active user calculation  
- **Purpose**: Count unique active users per day using efficient aggregation methods
- **Logic**: Unique daily active users are identified by extracting all distinct addresses that appear as either transaction senders (`sender_address`) or recipients (`to_address`) on each day. The calculation uses HyperLogLog (HLL) sketches for efficient counting across multiple dimensions including project level, chain level, user type, and product level. Users are deduplicated using the `coalesce(sender_address, to_address)` logic to ensure each address is counted only once per day.
- **Key fields**: Daily `timestamp`, `user_dau` (unique user addresses), and dimension breakdowns (`chain`, `user_type`, `product_id`)

### Component D: Revenue calculation
- **Purpose**: Convert aggregated fees to final revenue metric in USD
- **Logic**: The daily aggregated fees from Component B are converted to USD using end-of-day price feeds for each token. WETH and STRK fee amounts are multiplied by their respective USD prices on each date. The conversion process handles decimal correction and currency standardization. All converted fee amounts are summed to create total daily revenue. Missing days are filled with zero values to maintain consistent time series data.
- **Key fields**: `timestamp`, `revenue` (total USD value), and chain identification

### Final aggregation
- **Combining components**: Revenue data (Component D) and daily active user counts (Component C) are joined by date to create matched daily pairs of revenue and user count values
- **Currency conversion**: All fee amounts are converted to USD using end-of-day token prices, ensuring consistent currency denomination across different fee tokens (WETH and STRK)
- **Time aggregation**: Data is aggregated to daily boundaries using timestamp truncation, with all transactions within a calendar day contributing to that day's metrics
- **Final calculation**: ARPU is calculated by dividing daily revenue by daily active users using the standard formula: ARPU = Daily Revenue ÷ Daily Active Users. Days with zero active users result in null ARPU values, while days with zero revenue result in zero ARPU values.

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

StarknetSTRK

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape