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 Contract deployers Methodology

## 1. Overview

The Starknet contract deployers metric measures the daily count of unique addresses that deployed smart contracts on the Starknet blockchain. This metric tracks developer activity and smart contract deployment patterns by counting distinct deployer addresses per day. If the same address deploys multiple contracts on the same day, it is counted only once, providing a true measure of unique daily deployer activity.

## 2. Data sources

- **Starknet contract creation data**: Records of all smart contract deployments on the Starknet blockchain, including deployment timestamps, contract addresses, and deployer addresses
- **Starknet transaction traces**: Underlying transaction data that captures contract creation events and deployment metadata
- **Contract deployment metadata**: Additional context about contract creations including creator addresses and bytecode information

## 3. Step-by-step calculation

### Component A: Contract creation data extraction
- **Purpose**: Identifies all contract deployments on Starknet with their associated deployer information
- **Logic**: Extracts contract creation records from Starknet blockchain data, capturing the `creation_timestamp` as the deployment time, `contract_address` as the deployed contract identifier, and `deployer_address` as the address that initiated the deployment. Additional metadata like `creation_trace_address`, `contract_bytecode`, and `creator_address` are preserved for context. Duplicate records are removed using distinct selection to ensure each contract creation is counted only once.
- **Key fields**: `creation_timestamp` (deployment time), `deployer_address` (address performing deployment), `contract_address` (deployed contract identifier)

### Component B: Daily aggregation by deployer
- **Purpose**: Groups contract deployments by calendar day and counts unique deployers
- **Logic**: Groups all contract deployment records by calendar day using timestamp truncation of the `block_timestamp` field. For each day, counts the number of distinct `deployer_address` values to determine how many unique addresses deployed contracts. This ensures that if a single address deploys multiple contracts on the same day, it is counted only once in the daily total. Standard blockchain metadata is added including chain identifier as 'starknet', market sector as 'blockchains_l2', and business segment as 'blockchain'.
- **Key fields**: `timestamp` (daily boundary), `contract_deployers` (count of distinct deployers), `chain_id`, `market_sector_id`, `business_segment_id`

### Final aggregation
- **Combining components**: The daily deployer counts are processed through the finalize metric macro which standardizes the output format and applies business rules
- **Time aggregation**: Data is aggregated to daily boundaries using timestamp truncation, creating one record per calendar day
- **Gap filling**: A zero-fill strategy is applied to ensure days with no contract deployments are represented with a count of zero rather than missing records
- **Final calculation**: The final metric value is the count of distinct deployer addresses per day, filtered by chain availability constraints to ensure data quality and completeness

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

Unique addresses that deployed at least one smart contract.

StarknetSTRK

Contract deployers

Contract deployers

Competitive landscape

Chain breakdown