Starknet is commonly described as a ZK rollup, but that short label hides most of the interesting engineering. A user signs a transaction through an account contract, a sequencer receives it in a mempool, Cairo code executes in a purpose-built VM, the Starknet OS turns the state transition into a provable computation, SHARP aggregates STARK proofs, and Ethereum verifies a compact proof before accepting the new proven state. STRK already pays fees and participates in staking, while decentralization of block production is still being rolled out in stages.
Starknet is a validity rollup: Ethereum verifies a proof instead of re-executing every L2 transaction
Starknet is an Ethereum Layer 2 based on validity proofs. Thousands of L2 operations can execute away from Ethereum's execution layer while a compact cryptographic proof demonstrates that the resulting state transition followed protocol rules.
Ethereum does not need to replay every Cairo transaction. An L1 verifier checks evidence that the computation was performed correctly, after which Starknet core contracts can accept the new proven state.
Validity proofs and optimistic disputes are different models
An optimistic rollup assumes a proposed state is valid and leaves a challenge window for fraud proofs. Starknet uses a different boundary: the L1 state transition is backed by a validity proof. Canonical Ethereum settlement therefore depends on the proof pipeline rather than waiting to see whether somebody disputes the result.
STARK does not automatically mean private transactions
A STARK is a cryptographic proof system. It can prove computation integrity without repeating the work on Ethereum. That alone does not hide ordinary Starknet balances and transfers. Privacy and validity are separate properties and require separate design choices.
Where the scaling gain comes from
General-purpose execution moves away from Ethereum while L1 receives an aggregated proof and the data required to reconstruct state instead of performing each user's computation itself.
Cairo is a language and execution model designed around provability
Starknet differs from EVM rollups not only in proof technology. Smart contracts are written in Cairo, whose compilation and execution pipeline was built around computation that can later be proven efficiently.
For Cairo 1, the typical path is high-level source → Sierra → CASM → Cairo VM execution. The resulting trace becomes input for proof generation.
Sierra is a safe intermediate representation
Sierra stands for Safe Intermediate Representation. It sits between high-level Cairo and lower-level Cairo Assembly and is designed so submitted programs remain provable while the protocol can reason about execution and failure.
CASM is the executable layer
The sequencer compiles a Sierra class into CASM. CASM contains Cairo VM instructions, and its execution changes Starknet contracts, storage and state through defined syscalls.
Failed execution must be reproducible too
A proof-oriented VM cannot define only successful happy paths. Validation, execution, revert behavior and fee charging must be deterministic, otherwise different sequencers could interpret the same input differently.
The sequencer: mempool, ordering and the early L2 result
A user transaction first reaches a full node and then a sequencer. Starting with Starknet v0.14.0, sequencers use a mempool and arrival order no longer has to equal ordering inside a block.
The sequencer performs preliminary validation, chooses transactions, applies them sequentially to state and constructs a block. A transaction that passes validation but fails during execution can still be included with REVERTED execution status.
CANDIDATE and PRE_CONFIRMED are not L1 settlement
Modern Starknet statuses distinguish multiple stages. RECEIVED means a sequencer has received the transaction. CANDIDATE means it has been recorded by the sequencer as a candidate. PRE_CONFIRMED means the sequencer executed it. ACCEPTED_ON_L2 means the transaction entered a block finalized under the current L2 consensus protocol. ACCEPTED_ON_L1 means the Starknet state registered on Ethereum advanced to at least the block containing that transaction.
The mempool supports fee escalation
A pending transaction can be replaced using the same nonce when tip and maximum L2 gas price are increased according to protocol rules. This familiar blockchain UX is now part of the Starknet mempool rather than the older FIFO ordering model.
A green UI after PRE_CONFIRMED and an Ethereum-accepted state represent different confidence levels. Early confirmation is useful for UX; bridges and accounting care about the stronger boundary.
SNOS turns a Starknet block into a computation that can be proven
SNOS, the Starknet Operating System, is one of the architecture's core components. It is not an ordinary node operating system. SNOS is a Cairo program that receives an initial state and transactions, applies protocol rules and outputs the resulting state.
This formalization matters because a proof system can prove a statement of the form “this Cairo program with these inputs produced these outputs.” The claim “this Starknet block is valid” must therefore be represented as that kind of computation.
SNOS constrains a malicious sequencer
A sequencer could attempt to process a transaction outside the rules—for example, skipping a required account-validation step. The resulting block would no longer match the SNOS computation and should not produce a valid proof accepted by the Ethereum verifier.
The proof enforces protocol semantics, not operator intent
This is a major strength of a validity system: correctness comes from provable execution rather than the sequencer's reputation. Availability and censorship remain separate questions; a proof cannot force an operator to include a user's transaction promptly.
SNOS is part of the trusted software surface
If the proof program's specification or implementation contains a bug, cryptography faithfully proves the statement it was given. Auditing and public scrutiny of SNOS therefore matter as much as prover mathematics.
SHARP and S-two turn many blocks into an aggregated STARK proof
SHARP is StarkWare's shared proof aggregator. It accepts Cairo computations, validates jobs, schedules them, invokes provers and builds a recursive proof tree. For Starknet, this makes it possible to cover multiple blocks and eventually send an aggregated proof to Ethereum.
Recursion reduces L1 verification cost
Instead of paying Ethereum verification cost for every small computation, SHARP can prove proofs using Cairo verifier programs and aggregate the outputs repeatedly. The root of the tree then covers many original executions.
S-two is replacing Stone gradually
Starting with Starknet v0.14.0, SHARP uses S-two for most proofs while retaining Stone for recursive tree roots so existing Ethereum verifier contracts do not need to change all at once. This is a practical production migration rather than a theoretical clean-slate switch.
A STARK proof is not a transaction-compression format
The proof compresses **verification work**, not all information about the new state. Independent state reconstruction still requires a separate data-availability mechanism.
Data availability and Ethereum settlement: a proof is not enough without the state diff
Starknet publishes compressed state diffs to Ethereum—the differences between the previous and new L2 state. An observer that follows those diffs can reconstruct current Starknet state.
Since v0.13.1, state diffs can use EIP-4844 blobs, while the sequencer can switch to calldata under extreme relative pricing conditions. Later protocol versions introduced stateless and stateful compression.
Blobs and proofs solve different problems
A proof answers: **was the new state computed correctly?** A state diff answers: **which data are needed to reconstruct that state?** A small STARK proof does not somehow contain the entire balance and storage ledger.
ACCEPTED_ON_L1 marks a stronger Ethereum settlement boundary
After proof generation and verification, the L1 core contract accepts the corresponding Starknet state transition. This is stronger than the sequencer's early execution confirmation.
Starknet fees necessarily include an L1 component
Even inexpensive Cairo execution still creates state-diff and messaging costs on Ethereum. Transaction pricing therefore includes L2 computation and data plus L1 data or message components.
| Layer | What it verifies or pays for | Why it exists |
|---|---|---|
| Sequencer | Validation, ordering, execution | Fast L2 UX |
| SNOS | State-transition rules | Formalize provable computation |
| SHARP/S-two | STARK proof | Compress verification work |
| Ethereum verifier | Proof correctness | L1 settlement trust anchor |
| State diff/blob | Data availability | Reconstruct L2 state |
STRK: fees, governance and staking evolved with the protocol
STRK is Starknet's native token. A major current-state detail is that since v0.14.0, released on September 1, 2025, Starknet transaction fees are paid **only in STRK**. Earlier versions supported both ETH and STRK.
The sequencer receives fees in STRK and can convert part of them to ETH to cover L1 gas and data expenses, because Ethereum costs are denominated in ETH.
Fees span three resource buckets
The current model accounts for L2 gas, L1 data gas and L1 gas. L2 gas covers Starknet computation and data, L1 data gas covers publishing state diffs, and L1 gas covers operations such as L2-to-L1 messages.
Starknet currently does not burn transaction fees
Current documentation states that charged fees are received by the sequencer rather than burned. Ethereum's EIP-1559 burn intuition should therefore not be copied mechanically to STRK.
Governance is another STRK function
STRK is used in protocol governance, including approval processes for significant upgrades. That does not imply every runtime parameter is decided through a token vote, but governance is an explicit utility of the token.
Supply is not fixed forever at ten billion
The initial and planned distribution begins with ten billion STRK, while the staking system can mint new STRK rewards. Treating 10B as an immutable forever-cap is therefore incorrect; inflation parameters belong to protocol and governance rules.
Staking phase 2: validators attest blocks but do not yet produce them
The most important 2026 caveat is that Starknet staking is live while decentralization of core network responsibilities is still incomplete. Official documentation says the staking protocol is currently in **phase two of four**, and the network remains centralized with respect to core block-production responsibilities.
Validators already run full nodes and attest assigned blocks. Block proposing belongs to the next responsibility phase, with broader sequencing and proving duties moving to validators later in the roadmap.
The current validator minimum is 20,000 STRK
Current Mainnet parameters require at least 20K STRK for direct validator participation. Delegators can delegate STRK without handling operational duties. The withdrawal security lockup is currently seven days.
Phase two tests operational reliability
A validator is assigned a block and submits an attestation containing its block hash within the protocol window. This provides public evidence that the validator is actively following the chain through a full node.
BTC staking does not make Starknet use Bitcoin consensus
Since 2025, selected tokenized BTC wrappers can contribute to Starknet staking power under a separate weighting formula. This is economic participation in Starknet, not the import of Bitcoin Proof of Work into L2 consensus.
STRK staking is already a real protocol, but saying “STRK validators fully produce Starknet blocks” is premature in 2026. Current phase-two duties must be separated from phase-three and phase-four roadmap goals.
StarkGate, messaging and explorers reveal the L1↔L2 lifecycle
StarkGate is StarkWare's official bridge suite for ETH and ERC-20 assets between Ethereum and Starknet. A deposit begins on L1: funds enter a bridge contract, an event creates an L2 message, the sequencer observes the request, and an L2 handler later mints the corresponding representation.
A deposit becomes stronger as the proof lifecycle advances
After the L2 handler executes, the deposit can reach ACCEPTED_ON_L2. The block is then proven, a state update is submitted to Ethereum, and the stronger L1 settlement boundary follows.
Withdrawals run in the opposite direction
An L2 contract initiates a message to L1. After proof and settlement, the Ethereum-side bridge can consume the message and unlock funds under bridge rules. Withdrawal latency should therefore not be compared only with Starknet block time.
What to inspect in an explorer
For an ordinary transaction, separate execution status from finality status. For a bridge operation, add the L1 messaging and bridge transaction:
- Starknet transaction hash and execution status.
- PRE_CONFIRMED, ACCEPTED_ON_L2 or ACCEPTED_ON_L1.
- State-update and proof progression.
- L1 deposit or withdrawal event and message status.
- Exact token and bridge contract identity.
Five-day deposit cancellation is an emergency path, not normal latency
StarkGate lets a user request cancellation if an L1 deposit does not arrive on L2. Reclaim becomes available after roughly five days from the cancellation request. This is a self-custody safety mechanism, not the expected deposit time.
The main conclusion
Starknet is interesting because scaling begins with provable computation rather than simply making an EVM block faster. Cairo code moves through Sierra and CASM, the sequencer constructs L2 blocks, SNOS expresses protocol semantics as a Cairo computation, SHARP and S-two build recursive STARK proofs, Ethereum verifies the proof, and compressed state diffs provide the data needed to reconstruct state.
STRK has become an operational network token: since v0.14.0 it pays transaction fees and it participates in governance and staking. Staking, however, should be described by its current phase rather than its final roadmap—phase-two validators attest blocks while fully decentralized block production is still ahead.
The useful way to analyze Starknet is therefore not simply to ask “how many TPS can this ZK rollup process?” Follow the chain instead: **which code executed, what state the sequencer produced, what SNOS verified, which proof SHARP aggregated, which data reached Ethereum, and which responsibilities current validators actually hold today.**
FAQ
Is Starknet a ZK rollup or a validity rollup?
Both labels are common, but validity rollup more directly describes the key property: Ethereum accepts L2 state based on a validity proof. STARK technology does not automatically make normal transaction data private.
What is Cairo in Starknet?
It is the language and computation ecosystem for provable programs. Cairo 1 code compiles to Sierra and then CASM, executes in the Cairo VM and Starknet OS, and becomes part of the proof computation.
Who currently produces Starknet blocks?
Core sequencing is still in a transitional centralized state. The staking protocol is in phase two: validators attest blocks, while block proposing belongs to a later rollout phase.
How is SNOS different from SHARP?
SNOS defines and executes the provable Starknet state-transition rules. SHARP is proof-aggregation infrastructure that generates and recursively combines STARK proofs before Ethereum verification.
Which token currently pays Starknet gas fees?
Since Starknet v0.14.0, transaction fees are paid only in STRK. A sequencer can convert part of the collected fees to ETH for L1 expenses.
What does ACCEPTED_ON_L1 mean?
It means the Starknet state registered on Ethereum has advanced to a height that includes the transaction. It represents a stronger settlement boundary than early sequencer confirmation.
This material is educational and informational. It is not financial advice or a trading signal.