Starknet S-TWO: The First Rollup Settling on Both Bitcoin and Ethereum

Most rollups settle on a single chain. Ethereum rollups post validity proofs to Ethereum. Bitcoin rollups like Citrea anchor their state to Bitcoin. Starknet is attempting something different: a rollup that settles on both Bitcoin and Ethereum simultaneously, using a next-generation STARK prover called Stwo (pronounced "S-two"). If successful, Starknet would become the first Layer 2 to derive security guarantees from two independent base layers.

This article examines the technical architecture behind Starknet's dual-settlement ambition: how Stwo generates proofs, what posting those proofs to Bitcoin actually requires, and what dual settlement guarantees compared to single-chain designs.

What Is Stwo and How Does It Work

Stwo is StarkWare's production STARK prover, built on the Circle STARK construction. It replaced the earlier Stone prover on Starknet mainnet in November 2025 and now generates proofs for every Starknet block. Version 2.0.0 shipped in January 2026 as a fully open-source Rust crate available through crates.io.

Circle STARKs and the M31 field

Traditional STARKs operate over large prime fields (typically 256-bit), which are expensive to compute. Circle STARKs use the Mersenne prime M31 (2³¹ − 1), a 31-bit prime that maps directly onto 32-bit CPU registers. The prover builds an algebraic extension tower from M31 through CM31 (complex extension) to QM31 (quartic extension), which provides the security margin needed for Fiat-Shamir challenges.

The practical consequence is speed. M31 arithmetic vectorizes cleanly into 32-bit SIMD lanes across AVX2, AVX-512, NEON, and WebAssembly SIMD instruction sets. StarkWare has reported that Stwo's peak memory usage drops to 2.1 GiB, making STARK proof generation feasible on consumer hardware and even mobile devices.

Architecture layers

Stwo separates its core proving logic from application-specific circuits. The core crate is AIR-agnostic: it handles the circle FFT, a FRI variant adapted to the circle domain, Merkle commitment schemes, and the Fiat-Shamir channel. A separate stwo-cairo crate implements the Cairo CPU architecture on top of this core. Starknet v0.14.1 also migrated compiled class hashes from Poseidon to BLAKE2s, which is roughly 8x more efficient to prove under Stwo's architecture.

Why M31 matters for Bitcoin: Smaller field elements mean smaller proofs and faster verification. When the goal is to verify a proof inside Bitcoin's constrained scripting environment, every byte and every computation step counts.

Why Settle on Two Chains

A ZK rollup derives its security from the chain that verifies its proofs. If Starknet only settles on Ethereum, its security depends entirely on Ethereum's validator set, finality guarantees, and liveness. Adding Bitcoin as a second settlement layer creates redundancy: even if one chain experiences a deep reorganization or extended downtime, the other chain still holds a verified record of the rollup's state.

Dual settlement also addresses a practical concern. Starknet hosts both ETH-denominated and BTC-denominated assets. Users who bridge BTC into Starknet naturally want their withdrawal guarantees anchored to Bitcoin itself, not relayed through Ethereum. A validity proof verified on Bitcoin means that BTC withdrawals can be validated against Bitcoin's own security model rather than depending on a separate chain's finality.

What dual settlement does not guarantee

Dual settlement is not the same as dual execution. Starknet runs a single sequencer that produces blocks and a single prover that generates STARK proofs. Those proofs are then posted to two verification targets. If the sequencer censors transactions or the prover produces invalid proofs, having two settlement layers does not prevent that failure: it only means the invalid proof would be rejected on both chains simultaneously.

The real benefit is narrower: settlement-layer resilience. If Ethereum's proof verification contract is paused or Ethereum itself is congested, Bitcoin-side verification still holds. If Bitcoin's block space is too expensive for proof posting, Ethereum-side verification remains live. Neither chain alone is a single point of failure for state finality.

The Challenge of Posting Proofs to Bitcoin

Ethereum was designed for arbitrary computation. Bitcoin Script was not. Verifying a STARK proof on Ethereum requires deploying a verifier smart contract: a well-understood pattern that Starknet has used in production since 2020. Verifying the same proof on Bitcoin is a fundamentally harder problem.

Script constraints

Bitcoin's scripting language imposes strict limits that make direct proof verification difficult:

• A 1,000-element stack limit constrains the amount of intermediate state a script can hold
• No native looping constructs: iteration must be unrolled into sequential opcodes
• OP_RETURN outputs are limited to 80 bytes, enough for a commitment hash but not a full proof
• Witness data is capped at roughly 4 MB per block, shared across all transactions
• No native hash concatenation without OP_CAT, which is not active on mainnet

The OP_CAT path

In July 2024, StarkWare and L2 Iterative verified the first zero-knowledge proof on Bitcoin's Signet test network. The proof verified the 32nd number in the Fibonacci squared sequence: a small computation, but a milestone that demonstrated STARK verification inside Bitcoin Script. The experiment relied on OP_CAT (BIP-347), which enables hash concatenation and makes Merkle verification possible within Script.

The problem: OP_CAT is a soft fork proposal. It is available on Signet but not activated on Bitcoin mainnet, and community consensus on its activation remains uncertain. Building a settlement layer that depends on a soft fork is a risky architectural bet.

The no-fork alternative: ColliderVM

In April 2025, StarkWare co-founder Eli Ben-Sasson and researchers from the Weizmann Institute published ColliderVM, a protocol for stateful computation on Bitcoin that requires no protocol changes. ColliderVM uses hash-collision commitments to carry state across multiple transactions, enabling STARK verification without OP_CAT or any other disabled opcode.

The authors claim ColliderVM is at least 10,000x more efficient than its predecessor, ColliderScript. Unlike BitVM2's optimistic approach, ColliderVM aims for validity-based verification: proofs are checked directly on Bitcoin rather than relying on a fraud-proof challenge window. However, the protocol remains in the research stage. Ben-Sasson has described on-chain STARK verification via ColliderVM as "nearly practical" but not yet production-ready.

The fork dilemma: Every Bitcoin Layer 2 that needs on-chain proof verification faces the same choice: depend on a soft fork that may never activate, or find a way to work within today's Script constraints. ColliderVM and BitVM represent two different strategies for the no-fork path, with different trust assumptions and efficiency tradeoffs.

How Starknet's Bitcoin Settlement Would Work

Starknet's architecture for Bitcoin settlement combines Stwo proof generation with on-chain verification and a trust-minimized bridge.

Proof posting

The Stwo prover generates a single STARK proof attesting to the validity of a batch of Starknet transactions. This proof is then posted to two targets: Ethereum's verifier contract (already live) and a Bitcoin-side verifier. The Bitcoin verifier would use either ColliderVM or an OP_CAT-based covenant, depending on which approach reaches production first. In both cases, verification is split across multiple Bitcoin transactions to work within the stack and witness limits.

The Glock bridge

For BTC to move between Bitcoin mainnet and Starknet, a bridge is needed. Starknet is developing the Glock bridge in collaboration with Alpen Labs. Unlike traditional multisig bridges, Glock is designed as a trust-minimized lock that opens only when predefined conditions are cryptographically verified on Bitcoin.

In the proposed design, BTC is locked on Bitcoin L1 and can only be released if a corresponding burn is proven on Starknet's execution layer. This mirrors how Ethereum rollup bridges work: a validity proof attests to the state transition, and the bridge contract releases funds only after verification succeeds. The Starknet Foundation has funded the development and audit of Glock as a public good, with delivery targeted for 2026.

Single-Chain vs Dual-Chain Settlement

To understand what dual settlement adds, it helps to compare the three models currently in production or development.

What Citrea does differently

Citrea launched on Bitcoin mainnet in January 2026 as a ZK rollup that settles exclusively on Bitcoin. It uses a BitVM-style optimistic verification process: batch commitments are posted on-chain, and a fraud window allows challengers to dispute invalid proofs. The Clementine bridge secures user funds with a 1-of-N honest participant assumption.

Starknet's dual-settlement approach would differ by targeting direct validity verification on Bitcoin rather than optimistic verification. If ColliderVM or an OP_CAT-based verifier reaches production, Starknet's Bitcoin settlement would operate without a challenge window: proofs would be checked and either accepted or rejected immediately, matching the security model already live on Ethereum.

Comparing Proof Systems for Bitcoin Verification

Multiple projects are pursuing STARK or SNARK verification on Bitcoin, each with different approaches to the Script constraint problem.

Security Model Analysis

Dual settlement introduces a composite security model that inherits properties from both chains, but it also introduces new assumptions.

What is actually stronger

Settlement-layer resilience is the primary gain. A validity proof posted to both Bitcoin and Ethereum means that an attacker would need to compromise verification on both chains to forge a state transition. The two chains have fundamentally different consensus mechanisms (Proof of Work vs Proof of Stake), different validator/miner sets, and different economic security models. Attacking both simultaneously is strictly harder than attacking either alone.

What remains unchanged

Sequencer liveness and censorship resistance are not improved by dual settlement. Starknet currently uses a single sequencer operated by StarkWare. If the sequencer goes offline, no new blocks are produced, regardless of how many chains verify the proofs. The Starknet roadmap targets decentralized validation with staker-verified blocks for late 2026, but this is a separate effort from dual settlement.

New risks

Dual settlement adds architectural complexity. Two verification targets means two potential failure surfaces for proof posting, two bridge contracts to secure, and the possibility of state divergence if one chain accepts a proof that the other rejects (due to a verifier bug, for example). The system must define clear rules for conflict resolution: which chain's state is canonical when they disagree.

Implications for Cross-Chain Composability

A rollup that settles on both Bitcoin and Ethereum could serve as a natural bridge between the two ecosystems. Users could deposit BTC on the Bitcoin side and ETH or ERC-20 tokens on the Ethereum side, with both asset types living in the same execution environment.

This has implications for atomic swaps between BTC and ETH-based assets. Instead of relying on hash-time-locked contracts across two different chains, users could swap assets within a single rollup where both sides of the trade are verified by validity proofs. The trust assumption shifts from the weaker of the two chains to the stronger of the two verification targets.

However, cross-chain composability also depends on bridge security. Starknet's Ethereum bridge is a well-audited verifier contract. The Bitcoin-side Glock bridge is still in development. Until both bridges are live and audited, the composability promise remains theoretical.

How Spark's Approach Differs

Starknet's dual-settlement design and Spark's statechain architecture represent fundamentally different philosophies for scaling Bitcoin.

Rollups like Starknet batch thousands of transactions into a single validity proof. This proof is then posted to one or more base layers for verification. The approach is computation-heavy: generating STARK proofs requires significant compute resources, and verification, while cheaper, still demands smart contract logic or Script gymnastics on the settlement layer.

Spark takes a different path. Instead of batching and proving, Spark transfers complete UTXOs via cooperative signing. When ownership changes, the Spark Entity tweaks its key share and destroys the old one. No proof is generated, no batch is posted, and no verifier contract is involved. The security model relies on a 1-of-n honest operator assumption with FROST threshold signatures distributing trust across multiple independent operators.

Each model serves different use cases. Rollups excel at programmable execution environments where applications need EVM-compatible smart contracts or complex DeFi logic. Statechains optimize for fast, low-cost value transfer with minimal infrastructure overhead, making them well-suited for payments, wallets, and stablecoin transfers on Bitcoin.

Current Status and Roadmap

As of October 2026, Starknet's dual-settlement work is in active development but not yet live. Here is what has shipped and what remains:

• Stwo prover is live on Starknet mainnet, generating proofs for all blocks since November 2025
• Ethereum settlement is production-grade, with proofs verified by an on-chain verifier contract
• The Signet STARK verification demo (July 2024) proved feasibility but relied on OP_CAT, which is not active on mainnet
• ColliderVM offers a no-fork path but remains in the research stage
• The Glock bridge with Alpen Labs is funded and targeted for 2026 delivery, but no mainnet launch has been confirmed
• Starknet's roadmap targets decentralized block validation with stakers by late 2026
• In October 2026, the Starknet community began exploring a potential transition to an independent Layer 1, which could affect the dual-settlement architecture

Development vs production: Starknet's Ethereum settlement has years of production hardening. Bitcoin settlement is a stated goal with active research behind it, but the gap between a Signet demo and mainnet deployment is significant. The Bitcoin Script constraints, bridge security requirements, and soft-fork uncertainty all represent open engineering challenges.

What to Watch

Several developments will determine whether dual-chain settlement moves from concept to production:

• Whether OP_CAT (BIP-347) gains consensus for activation on Bitcoin mainnet, which would enable the simpler verification path
• Whether ColliderVM moves from research to a production-grade implementation that can verify Stwo proofs on Bitcoin without a fork
• How the Glock bridge performs under audit and whether its trust-minimized design holds up against real economic incentives
• Whether Starknet's potential L1 transition changes the dual-settlement thesis, or whether the L1 itself would inherit both settlement targets
• How Citrea's Bitcoin-only settlement model competes: if single-chain settlement proves sufficient for most use cases, the added complexity of dual settlement may not justify its costs

For developers exploring Bitcoin Layer 2 infrastructure today, Spark's SDK offers a production-ready path for instant Bitcoin and stablecoin transfers. The Bitcoin L2 comparison covers the full landscape of scaling approaches, from statechains to rollups to sidechains.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.