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 Transactions per second Methodology

## 1. Overview

The Starknet transactions per second (TPS) metric measures the average number of transactions processed per second on the Starknet Layer 2 network on a daily basis. This metric provides insight into the network's transaction throughput and activity levels. The calculation takes the total number of unique transactions per day and divides by 86,400 (the number of seconds in a day) to produce an average TPS value.

## 2. Data sources

- **Starknet transaction records**: Raw blockchain transaction data including transaction hashes, block timestamps, sender and receiver addresses, transaction types, gas fees, and receipt events
- **Account labeling data**: External labeling service that provides human-readable titles and categorizations for known Starknet addresses and contracts

## 3. Step-by-step calculation

### Component A: Transaction data preparation
- **Purpose**: Extract and standardize raw Starknet transaction data for analysis
- **Logic**: Raw Starknet transaction records are processed to extract key transaction details. The `block_timestamp` field provides timing information, while `transaction_hash` serves as the unique identifier. Sender addresses are captured from the `sender_address` field, and recipient addresses are extracted from the first event in the `receipt_events` array when available. Transaction fees are converted from wei to ETH by dividing the `receipt_actual_fee` by 1e18. All transactions are tagged with chain identifier 'starknet' and categorized under the 'blockchains_l2' market sector and 'blockchain' business segment.
- **Key fields**: `block_timestamp`, `transaction_hash`, `sender_address`, `to_address` (derived from receipt events), `actual_fee_amount` (converted to ETH)

### Component B: Daily transaction aggregation
- **Purpose**: Count unique transactions per day and destination address
- **Logic**: Transactions are aggregated by truncating timestamps to day boundaries using `timestamp_trunc`. For each day and destination address combination, the system counts distinct transaction hashes to ensure each transaction is counted only once, preventing double-counting from any potential data duplication. The aggregation groups by timestamp, destination address, and standard metadata fields like chain identifier and business segment.
- **Key fields**: `timestamp` (truncated to day), `to_address`, `transaction_count` (distinct hash count)

### Component C: Address labeling enrichment
- **Purpose**: Categorize transactions by destination type using account labels
- **Logic**: The daily transaction counts are enriched with account labeling data through a left join on the destination address. This mapping provides human-readable titles for known contracts, protocols, and account types. When no label exists for an address, it defaults to 'Unlabeled'. This categorization enables analysis of transaction patterns by destination type (e.g., DeFi protocols, NFT marketplaces, etc.).
- **Key fields**: `label` and `contract_name` (derived from account titles or 'Unlabeled'), `transaction_count`

### Final aggregation
- **Combining components**: The labeled transaction data is processed through a finalization macro that validates the schema, ensures data quality, and applies gap-filling logic using a 'fill_zeros' strategy for any missing days
- **Currency conversion**: Not applicable for this metric as it measures transaction volume, not monetary values
- **Time aggregation**: Data is aggregated at daily granularity with timestamps truncated to day boundaries
- **Final calculation**: The transactions per second value is calculated by dividing the daily transaction count by 86,400 (the number of seconds in a day) using a safe division function to handle edge cases. Chain availability filtering is applied as a final step to ensure data quality and completeness.

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

Average confirmed user transactions added per second.

StarknetSTRK

Transactions per second

Transactions per second

Competitive landscape

Chain breakdown