How Does Starknet Work?

STARK-based validity rollup using recursive proofs for Ethereum L1 verification

Uses STARK proofs (no trusted setup) for validity verification. STARKs are larger but offer quantum resistance and transparent setup.

Custom Cairo VM execution environment purpose-built for STARK proof efficiency

Cairo is a non-EVM language designed for maximum STARK efficiency. Requires specialized developer tooling and auditor expertise, limiting security review availability.

Single StarkWare-operated sequencer with planned decentralization roadmap

Centralized sequencer has experienced multiple outages. No permissionless fallback mechanism currently deployed.

Recursive proof aggregation allowing multiple blocks to be verified in a single L1 transaction

SHARP (SHARed Prover) aggregates proofs across multiple applications. Reduces per-transaction verification cost but creates shared prover dependency.

STRK token used for governance, staking, and gas fees with 50% supply unlocked

Multi-purpose token with significant unlock schedule remaining. Staking mechanism introduces new economic dynamics.

Canonical bridge with STARK-proven message passing between L1 and Starknet

Bridge security inherits from STARK proof validity. Withdrawal delays depend on proof generation and L1 finalization.

Native account abstraction where all accounts are smart contracts with customizable validation

All Starknet accounts are smart contracts by default, enabling flexible signature schemes and gas abstractions. Novel approach but increases contract-level attack surface.

State diffs posted to Ethereum L1 with optional Volition mode for off-chain DA

Volition allows per-transaction DA choice. Off-chain DA mode reduces costs but weakens data availability guarantees.

10B total STRK supply with approximately 50% unlocked, ongoing monthly unlocks

Continuous unlock schedule creates persistent sell pressure. Large remaining locked supply from early investors and team.

Sequencer outages halt both transaction processing and proof generation simultaneously. January 2026 incident caused 18 minutes of block reversions, demonstrating that sequencer failure cascades to proof layer.

Non-EVM execution environment limits the pool of qualified auditors and security researchers. Cairo-specific bugs may go undetected longer than Solidity vulnerabilities due to smaller review community.

Shared prover depends on external Ethereum RPC providers. RPC failures during the January 2026 outage exposed this dependency, potentially affecting all applications sharing the prover.

All accounts being smart contracts increases the attack surface for account-level exploits. Custom validation logic in Cairo adds complexity that could lead to novel authorization bypass vectors.

Transactions using off-chain DA in Volition mode have weaker availability guarantees. If off-chain DA provider fails, state needed for withdrawal proofs may become temporarily unavailable.