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 Transaction count Methodology

## 1. Overview

This metric calculates the daily transaction count for the Starknet L2 blockchain. It measures the total number of unique transactions processed on Starknet each day, providing insight into network activity and adoption. The metric aggregates all transaction types and can be segmented by destination contract to understand which protocols or applications are driving network usage.

## 2. Data sources

- **Starknet blockchain transaction records**: Core transaction data including block timestamps, transaction hashes, transaction types, sender addresses, and gas fees
- **Starknet transaction receipt events**: Event logs generated during transaction execution, containing destination contract addresses and transaction outcomes
- **Third-party contract labeling database**: External database providing human-readable names and titles for Starknet contracts and accounts

## 3. Step-by-step calculation

### Component A: Transaction data extraction
- **Purpose**: Extract and process raw Starknet transaction data for counting
- **Logic**: Retrieve all Starknet transactions with their block timestamps, unique transaction hashes, and receipt events. Parse the `receipt_events` array to extract destination addresses - specifically taking the `from_address` field from the first event in the array as the `to_address` (destination contract). Convert gas fees from wei to ETH units by dividing by 1e18. Apply incremental processing logic to only process recent transactions when updating the metric.
- **Key fields**: `block_timestamp` for temporal aggregation, `transaction_hash` for unique counting, `receipt_events` array for destination parsing, `sender_address` for transaction origin

### Component B: Daily transaction aggregation  
- **Purpose**: Count distinct transactions per day and destination address
- **Logic**: Group transactions by daily timestamp boundaries using timestamp truncation to day granularity. For each day and destination address combination, count the number of distinct transaction hashes to avoid double-counting. Include standard blockchain categorization fields marking transactions as from the 'starknet' chain in the 'blockchains_l2' market sector under the 'blockchain' business segment.
- **Key fields**: `timestamp` truncated to daily boundaries, `transaction_count` as distinct hash count, `to_address` for destination grouping

### Component C: Contract label enrichment
- **Purpose**: Add human-readable names to destination addresses
- **Logic**: Left join the aggregated transaction data with the contract labeling dimension table using the destination address as the join key. For addresses that have labels in the external database, use the provided `account_title` as both the `label` and `contract_name`. For addresses without labels, assign 'Unlabeled' as the default value. This enrichment helps categorize transactions by the type of contract or application they interact with.
- **Key fields**: `label` and `contract_name` derived from account titles, destination addresses for matching

### Final aggregation
- **Combining components**: The enriched transaction data flows through the `finalize_metric_transaction_count` macro which applies standardized schema validation, ensures proper data type formatting, and implements gap-filling logic
- **Currency conversion**: Not applicable for transaction count metrics
- **Time aggregation**: Daily boundaries are established by truncating block timestamps to day granularity, ensuring consistent 24-hour periods
- **Final calculation**: The metric represents the sum of distinct transaction hashes processed on Starknet for each day, with the ability to segment by destination contract labels. Missing days are filled with zero values to maintain continuous time series data.

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

Confirmed transactions added to the blockchain.

StarknetSTRK

Transaction count

Transaction count

Competitive landscape

Chain breakdown