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 addresses (weekly) Methodology

## 1. Overview

Weekly active addresses measures the number of unique addresses that have been active on the Starknet blockchain within a rolling 7-day window. An address is considered active if it either sent a transaction or received a transaction during the period. This metric provides insights into user engagement and network adoption by tracking distinct participants rather than transaction volume.

The calculation uses HyperLogLog probabilistic counting to efficiently handle deduplication across large datasets and time windows, providing approximate but highly accurate unique address counts.

## 2. Data sources

- **Starknet transaction data**: Raw blockchain transaction records containing sender addresses, recipient addresses, transaction types, timestamps, and fee information
- **Starknet receipt events**: Transaction receipt data including event logs that capture recipient addresses from the first event in each transaction
- **Transaction metadata**: Block timestamps, transaction hashes, and transaction classification data

## 3. Step-by-step calculation

### Component A: Transaction extraction
- **Purpose**: Extract all Starknet transactions with relevant address and timing information
- **Logic**: Pull transaction records from Starknet blockchain data including `block_timestamp`, `transaction_hash`, `sender_address`, and `transaction_type`. Extract recipient addresses from the first event in the `receipt_events` array when available. Convert transaction fees to ETH by dividing `receipt_actual_fee` by 1e18. Set chain identifier as 'starknet' and classify as layer 2 blockchain segment.
- **Key fields**: `block_timestamp` for temporal analysis, `sender_address` for transaction initiators, `to_address` derived from receipt events for recipients, `transaction_type` for user classification

### Component B: Daily active user identification  
- **Purpose**: Identify unique active addresses for each day
- **Logic**: For each day (using `timestamp_trunc` to day level), collect all distinct addresses that were active by combining both sender addresses and recipient addresses using `coalesce(sender_address, to_address)`. Include transaction type and chain metadata for dimensional analysis. Filter to ensure complete address coverage from both transaction senders and recipients.
- **Key fields**: `timestamp` truncated to day granularity, `user_dau` containing unique active addresses, `user_type` from transaction classification, `chain` identifier

### Component C: HyperLogLog daily aggregation
- **Purpose**: Convert daily active addresses into probabilistic data structures for efficient window calculations
- **Logic**: Group daily active addresses by timestamp, timestamp grain, chain, user type, and product ID. Initialize HyperLogLog sketches using `hll_count.init()` with precision parameter 15 for each group. This creates memory-efficient approximate representations of unique address sets that can be efficiently merged across time periods.
- **Key fields**: `timestamp` for temporal grouping, `hll` containing HyperLogLog sketch data, dimensional fields for grouping

### Component D: Seven-day rolling window construction
- **Purpose**: Build complete 7-day windows for each date to calculate weekly active addresses
- **Logic**: Create a datespine covering all dates from the minimum transaction date to yesterday. For each date, generate a 7-day window by creating timestamps for that date plus the previous 6 days using `generate_timestamp_array`. Join this window structure with the daily HyperLogLog data to ensure complete coverage even when some days have no transactions. This prevents gaps in the rolling window calculation.
- **Key fields**: `timestamp` for the end date of each window, `joinday` timestamps covering the 7-day period, `hll` sketches for each day in the window

### Component E: Weekly active address calculation
- **Purpose**: Calculate unique active addresses across each 7-day window
- **Logic**: For each 7-day window, merge all HyperLogLog sketches using `hll_count.merge_partial()` to combine the unique address sets across the time period. Extract the final count using `hll_count.extract()` to get the approximate number of unique addresses active during the window. Perform this calculation at multiple dimensional levels: project tag level (aggregating across all dimensions), chain level, user type level, and product level. Combine all dimensional breakdowns using UNION ALL.
- **Key fields**: `user_wau` containing the count of unique weekly active addresses, `dimensions` indicating the aggregation level, dimensional identifiers for chain, user type, and product

### Final aggregation
- **Combining components**: Select weekly active user data from the user WAU aggregation and filter to include only 'chain' and 'project_dbt_tag' dimensional breakdowns. Rename the `user_wau` field to `active_addresses_weekly` to reflect the specific metric being calculated.
- **Currency conversion**: Not applicable for this address-based metric
- **Time aggregation**: Uses 7-day rolling windows where each date represents the count of unique addresses active in that day plus the previous 6 days
- **Final calculation**: The final metric value is the HyperLogLog-approximated count of unique addresses that were active (sent or received transactions) within each 7-day rolling window, reported daily with weekly lookback periods

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

Unique active addresses over a rolling 7-day window.

StarknetSTRK

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape

Chain breakdown