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 fees per user (AFPU) Methodology

## 1. Overview

Average Fees Per User (AFPU) measures the average transaction fees paid per daily active user on the Starknet Layer 2 network. This metric is calculated by dividing the total daily fees collected by the network by the number of daily active users, providing insight into the average cost burden per user and network monetization efficiency. The calculation uses a macro-driven approach that combines fee aggregation with user counting to produce a standardized revenue-per-user metric.

## 2. Data sources

- **Starknet transaction data**: Raw blockchain transaction records from the Starknet Layer 2 network containing transaction hashes, sender addresses, recipient addresses, fee amounts, and fee denominations
- **End-of-day token price feeds**: Daily closing price data for ETH and STRK tokens used to convert native token fees to USD values
- **Token metadata**: Contract addresses and decimal specifications for WETH (`0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2`) and STRK (`0xca14007eff0db1f8135f4c25b34de49ab0d42766`) tokens
- **Chain availability configuration**: Data quality filters that ensure consistent reporting periods across different blockchain networks

## 3. Step-by-step calculation

### Component A: Transaction data processing
- **Purpose**: Extract and standardize raw Starknet transaction data with fee information
- **Logic**: Parse Starknet blockchain transactions to extract key fields including `block_timestamp`, `transaction_hash`, `sender_address`, `actual_fee_amount`, and `actual_fee_unit`. Convert fee amounts from native token units by dividing by 1e18 to account for 18-decimal precision. Map fee units to their corresponding token addresses where WEI maps to WETH address and FRI maps to STRK address. Extract recipient addresses from the first event in the transaction receipt when available.
- **Key fields**: `sender_address` as the transaction initiator, `actual_fee_amount` as the fee paid, `actual_fee_unit` indicating the fee token type, `block_timestamp` for daily grouping

### Component B: Daily fee aggregation  
- **Purpose**: Calculate total fees collected per day by token type
- **Logic**: Group processed transactions by day using timestamp truncation and by token address based on the fee unit mapping. Sum the `actual_fee_amount` values for each day-token combination. Handle both ETH fees (from WEI unit) and STRK fees (from FRI unit) separately to maintain proper token attribution.
- **Key fields**: `timestamp` truncated to day boundary, `token_address` derived from fee unit, `fees` as the aggregated daily amount per token

### Component C: Fee USD conversion
- **Purpose**: Convert daily token fees to USD values using market prices
- **Logic**: Join daily fee totals with end-of-day price feeds for the corresponding tokens (WETH and STRK). Multiply the native token amounts by their respective USD prices to get dollar-denominated fee values. Aggregate across all tokens to get total daily fees in USD. Apply decimal corrections if needed based on token specifications.
- **Key fields**: `fees` converted to USD, `timestamp` for price matching, `token_address` for price lookup

### Component D: Daily active user counting
- **Purpose**: Count unique users active each day across all transaction types
- **Logic**: Identify unique addresses participating in transactions by combining both sender and recipient addresses. Create daily user lists by truncating transaction timestamps to day boundaries. Use HyperLogLog sketches to efficiently count distinct users while handling large address sets. Include users from both transaction sending and receiving activities to capture all network participants.
- **Key fields**: `user_dau` addresses from both `sender_address` and recipient addresses, `timestamp` truncated to day, `user_type` from transaction classification

### Component E: User aggregation across dimensions
- **Purpose**: Aggregate user counts across different analytical dimensions while maintaining uniqueness
- **Logic**: Use HyperLogLog merge operations to combine user counts across multiple dimensions including project level, chain level, user type, and product level. Maintain the probabilistic counting accuracy while enabling efficient aggregation of large user sets. Create separate breakdowns for each dimension to support different analytical views.
- **Key fields**: `user_dau` count extracted from merged HyperLogLog sketches, `dimensions` indicating the aggregation level, various ID fields for dimensional breakdown

### Final aggregation
- **Combining components**: The AFPU calculation uses the `calculate_arpu` macro which divides the total daily fees (from the fees metric) by the daily active user count (from the user_dau metric). Both components are joined on date to ensure proper temporal alignment.
- **Currency conversion**: All fees are converted to USD using end-of-day price feeds before the division calculation to provide a standardized monetary value
- **Time aggregation**: Daily boundaries are established using timestamp truncation, ensuring consistent 24-hour periods for both fee collection and user counting
- **Final calculation**: AFPU = Total Daily Fees (USD) ÷ Daily Active Users, where the result represents the average USD value of fees paid per active user on each day. Missing days are filled with zero values to maintain continuous time series data.

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

StarknetSTRK

Average fees per user (AFPU)

Average fees per user (AFPU)

Competitive landscape