Citrea: Bitcoin's First ZK Rollup and What It Changes for L2 Scaling

For years, zero-knowledge rollups were an Ethereum concept. Rollup teams like zkSync and Scroll built proving systems that compress thousands of transactions into a single cryptographic proof, verified by an L1 smart contract. Bitcoin had no equivalent: its scripting language cannot verify a zero-knowledge proof directly. Citrea changes that. Launched on mainnet on January 27, 2026, Citrea is the first production ZK rollup that settles on Bitcoin, using BitVM to verify proofs without modifying Bitcoin's consensus rules.

This article breaks down how Citrea works: the architecture that makes ZK proving possible on a non-programmable base layer, the trust assumptions behind its bridge, and how it compares to both Ethereum rollups and other Bitcoin Layer 2 approaches.

Why ZK Rollups on Bitcoin Are Hard

On Ethereum, a ZK rollup works because the base layer is programmable. A Solidity smart contract can accept a proof, run the verification algorithm (typically a pairing check for Groth16 or a polynomial commitment check for PLONK), and confirm that a batch of off-chain transactions was executed correctly. If the proof verifies, the rollup state is finalized on L1.

Bitcoin has none of this. Bitcoin Script is intentionally non-Turing-complete. It supports hash checks, signature verification, and timelocks, but it cannot execute the elliptic curve pairings or field arithmetic required to verify a ZK proof natively. This is not a bug: it is a deliberate design choice that keeps Bitcoin's attack surface small and its consensus rules simple.

The challenge, then, is bridging the gap between what a ZK rollup needs (proof verification on L1) and what Bitcoin offers (a constrained scripting language). Citrea's answer is to use Bitcoin for what it does well: data availability and settlement finality, while offloading proof verification to an optimistic mechanism built on BitVM.

Citrea Architecture Overview

Citrea is a Type 2 zkEVM rollup built on RISC Zero's zkVM. It executes EVM-compatible smart contracts off-chain, batches the results, generates a validity proof, and publishes both the proof and state differences to Bitcoin. The system comprises four core components.

Sequencer

The sequencer monitors the mempool approximately every two seconds, selects high-priority transactions, executes them against the current state, and produces soft confirmations. These soft confirmations are broadcast to full nodes and represent provisional finality: fast enough for applications, but not yet anchored to Bitcoin.

Periodically, the sequencer publishes a commitment to Bitcoin: a Merkle root of recent soft-confirmation hashes. This on-chain commitment establishes transaction ordering before the batch proof is generated, preventing the sequencer from reordering transactions after the fact.

Batch Prover

The batch prover takes thousands of Citrea blocks, replays their execution inside the RISC Zero zkVM, and generates a Groth16 proof attesting that the state transition is correct. The proof package includes the proof itself, state differences (deltas of changed account data), the initial and final state roots, and the sequencer commitment hash.

Rather than inscribing full transaction data, Citrea publishes only state diffs: the net changes to account balances and storage. This is a deliberate optimization. Batch proofs are kept under 400 kilobytes to avoid producing non-standard Bitcoin transactions, and the cost of inscribing data is amortized across all transactions in the batch.

Light Client Prover

A separate proving circuit creates recursive proofs of the entire rollup state by processing Bitcoin block headers and previous light client proofs. This enables external verifiers to validate the full Citrea chain with a single proof rather than replaying every batch from genesis.

Full Nodes

Full nodes are permissionless. Anyone can run one. They sync Citrea blocks, monitor Bitcoin for sequencer commitments and batch proofs, replay transactions to verify state roots, and expose JSON-RPC APIs for users and applications. Because all data is available on Bitcoin, full nodes can reconstruct the canonical rollup state directly from Bitcoin blocks.

Permissionless verification: Unlike federated sidechains where users must trust a signing committee, any Citrea full node can independently verify every state transition by reading data from Bitcoin. There are no data availability committees to trust.

The Proof Lifecycle

A Citrea transaction moves through six stages from submission to cryptographic finality.

1. A user submits a transaction to a full node, which forwards it to the sequencer mempool.
2. The sequencer batches the highest-priority transactions and executes them against the current state (approximately every two seconds).
3. The sequencer broadcasts a signed soft confirmation to full nodes. At this point, the transaction has provisional finality.
4. The sequencer publishes a commitment (Merkle root of soft-confirmation hashes) to Bitcoin. This anchors the transaction ordering on L1.
5. The batch prover generates a Groth16 proof inside the RISC Zero zkVM, validating the entire batch of state transitions. The proof and state diffs are inscribed on Bitcoin.
6. Full nodes fetch the proof from Bitcoin and verify it. The transactions now have cryptographic finality: the state transition is provably correct and anchored to Bitcoin's proof-of-work chain.

BitVM: Optimistic Verification of ZK Proofs

The core innovation enabling Citrea is BitVM, a computing paradigm introduced by Robin Linus in 2023 that allows Turing-complete computation on Bitcoin without consensus changes. BitVM does not add smart contract support to Bitcoin. Instead, it uses a challenge-response protocol: a party asserts that a computation was performed correctly, and if anyone disagrees, they can initiate a dispute that is resolved on-chain using Bitcoin Script.

Citrea uses BitVM2 (an improved version that eliminates many complexities of the original design) to build its bridge, called Clementine. The verification is optimistic: the ZK proof is assumed correct unless someone challenges it. If a challenge occurs, the dispute is resolved directly on Bitcoin using Script-level verification steps.

This is fundamentally different from Ethereum rollups, where the L1 smart contract runs the proof verification algorithm directly for every batch. On Bitcoin, direct verification is impossible, so Citrea substitutes an optimistic protocol that achieves the same security guarantee under a 1-of-N honesty assumption: as long as one participant is willing to challenge a fraudulent proof, the system remains secure.

A ZK rollup with optimistic verification: Citrea generates ZK proofs for correctness, but verifies them on Bitcoin using an optimistic (challenge-response) mechanism. This is a practical compromise for building on a non-programmable base layer, not a weakness: the ZK proof still provides data compression and succinct state validation that a pure fraud proof system cannot match.

Clementine Bridge: How Bitcoin Enters and Exits

The Clementine bridge is the trust-minimized two-way peg connecting Bitcoin L1 to Citrea. It handles peg-in (BTC to cBTC on Citrea) and peg-out (cBTC back to BTC) operations.

Peg-In (Depositing BTC)

Users send BTC to a Taproot address with two spending paths: a primary path requiring all Signer signatures (with the user's EVM address embedded in the witness data), and a refund path using OP_CSV that allows the user to reclaim funds after 200 Bitcoin blocks if the deposit is not processed. Signers execute a pre-signed transaction moving the deposit into a vault UTXO, and after six block confirmations, Citrea's Bridge contract validates the transaction via a Bitcoin Light Client and mints equivalent cBTC.

Peg-Out (Withdrawing BTC)

Users burn cBTC on Citrea and submit a payout template to operators. In the happy case, if all Signers are online, they directly authorize the BTC transfer. If Signers are unavailable for over 12 hours, an operator fronts the BTC payment using SIGHASH_SINGLE|ANYONECANPAY and then claims reimbursement via a KickOff transaction during a 1.5-day challenge window.

Challenge and Dispute Resolution

If a fraudulent claim is detected, a Challenger posts a Challenge transaction on Bitcoin. A Watchtower publishes the canonical Bitcoin header-chain proof showing the current finalized chain. The operator must then provide a zkSNARK Light Client Proof demonstrating sufficient proof-of-work and inclusion of the actual payout transaction. Honest operators win reimbursement; malicious operators lose their bond and are removed from the operator and signer sets.

Trust Assumptions: Who Do You Trust?

Citrea's trust model has multiple layers, each with a distinct honesty requirement.

• Signers control the multisig guarding bridge funds. One honest Signer ensures funds can only follow pre-approved spend paths.
• Watchtowers monitor Bitcoin for fraudulent claims. One honest Watchtower can block a claim anchored to the wrong Bitcoin chain.
• Challengers can prove invalid computations and seize operator collateral. One rational Challenger protects the system.
• The Challenger role is permissionless: any user can fulfill it.

These roles form a nesting hierarchy: Operators are a subset of Signers, who are a subset of Watchtowers, who are a subset of Challengers, who are a subset of all users. The further out you go, the weaker the trust assumption becomes.

The sequencer has limited power. It can order transactions and may cause liveness failures (delays), but it cannot violate correctness, steal funds, or freeze them. The ZK proof enforces execution validity regardless of sequencer behavior: any batch that skips a valid forced transaction or computes an incorrect state root will fail proof verification.

What Happens If the Prover Goes Offline?

If the prover stops generating proofs, new state transitions cannot achieve cryptographic finality. Soft confirmations continue from the sequencer, but no new batches are anchored to Bitcoin. Users can still exit via the bridge using their last finalized state, or use atomic swaps to move funds to Bitcoin or Lightning directly.

What Happens If the Sequencer Censors Transactions?

Citrea implements a force-inclusion mechanism: users can post a minimal L1 commitment directly on Bitcoin, and Citrea nodes are required to treat these as must-include inputs. The ZK proof enforces this: any batch that skips or reorders a valid forced transaction observed before the cutoff cannot generate a valid proof and will be rejected during verification on Bitcoin. If block producers fail or refuse service beyond that window, users can unilaterally progress or exit.

Citrea vs. Ethereum ZK Rollups

Comparing Citrea to Ethereum ZK rollups like zkSync Era and Scroll highlights how the base layer shapes the design of everything above it.

The most significant difference is proof verification. On Ethereum, the rollup submits a proof and the L1 smart contract runs the verifier algorithm in a single transaction. The result is deterministic and immediate. On Bitcoin, Citrea must use an optimistic wrapper: the proof is assumed correct, and only challenged if someone detects fraud. This adds a challenge window to withdrawals (1.5 days) that Ethereum rollups do not require.

The tradeoff is the base layer itself. Bitcoin's proof-of-work consensus, high hashrate, and 17 years of unbroken operation offer a settlement guarantee that is difficult to replicate. For users who want their rollup anchored to Bitcoin rather than Ethereum, Citrea is the first option that provides ZK-level correctness guarantees.

Citrea vs. Other Bitcoin Layer 2 Approaches

Citrea occupies one corner of a rapidly growing Bitcoin L2 landscape. Each approach makes different tradeoffs between programmability, trust minimization, and complexity.

Citrea and Spark represent two particularly interesting poles in this design space. Citrea targets full EVM programmability: lending, trading, stablecoins, and arbitrary smart contracts, all anchored to Bitcoin. Spark targets instant payments and token transfers with a simpler architecture built on statechains and FROST threshold signatures. Both inherit Bitcoin's security without requiring modifications to the base protocol, but they serve different use cases: Citrea for DeFi and programmability, Spark for fast, low-cost transfers.

Current Limitations and Open Questions

Proof Generation Costs

Generating Groth16 proofs inside a zkVM is computationally expensive. Citrea uses RISC Zero's Boundless proving network to distribute this workload, but proof generation still takes minutes to hours depending on batch size and complexity. This means cryptographic finality lags behind soft confirmation by a significant margin. The cost of proving is amortized across all transactions in a batch, so higher throughput improves economics, but this remains an active area of optimization.

Bitcoin Data Costs

Inscribing state diffs and proofs on Bitcoin costs real sats. Each batch proof is constrained to under 400 KB, and the total inscription cost scales with the amount of state change. During periods of high Bitcoin fee markets, rollup operating costs increase. Citrea mitigates this by publishing only state diffs rather than full transaction data, but the dependency on Bitcoin blockspace is a structural cost that Ethereum rollups (which can use cheaper blob data via EIP-4844) may avoid.

Bridge Withdrawal Delays

The 1.5-day challenge window for operator-assisted withdrawals is a real UX constraint. Users wanting to exit quickly can use atomic swaps to Bitcoin or Lightning, but this requires counterparty liquidity. The direct bridge path is slower than what Ethereum rollup users expect (30 to 90 minutes for zkSync and Scroll).

Sequencer Centralization

At launch, Citrea runs a single sequencer. While the sequencer cannot steal funds or produce invalid state transitions (the ZK proof prevents this), it can censor transactions or go offline. The force-inclusion mechanism provides a safety valve, but decentralizing the sequencer remains an open engineering challenge shared by nearly all rollups, on both Bitcoin and Ethereum.

Optimistic Verification Gap

Citrea generates ZK proofs but verifies them optimistically via BitVM. This is a pragmatic choice given Bitcoin's scripting limitations, but it means the bridge does not achieve the same trustless verification that Ethereum rollups enjoy. The team has described the optimistic layer as a placeholder until ZK proving becomes viable on Bitcoin: future opcodes like OP_CAT could enable direct on-chain proof verification, removing the optimistic step entirely.

The Ecosystem at Launch

Citrea launched with 40+ decentralized applications and a focus on two core product categories: BTC-collateralized lending and BTC structured products. The platform introduced ctUSD, a fiat-backed stablecoin issued via M0 infrastructure and MoonPay, fully backed by short-term U.S. Treasuries and cash reserves.

The CTR governance token was announced with a fixed supply of 10 billion tokens, 12% circulating at launch, and 60% allocated to the community and ecosystem. Users can stake CTR to receive xCTR, a non-transferable governance asset used for liquidity direction and ecosystem coordination.

Citrea is backed by a $14M Series A led by Founders Fund with participation from Galaxy, Delphi Digital, Maven 11, and individual investors including Erik Voorhees and Balaji Srinivasan. The protocol was incubated by Chainway Labs, co-founded by Orkun Mahir Kılıç.

What Citrea Means for Bitcoin Scaling

Citrea proves that ZK rollups are not an Ethereum-only primitive. By combining validity proofs with BitVM's optimistic verification, Citrea brings full EVM programmability to Bitcoin without requiring a soft fork, a federated signer set, or a separate consensus mechanism. The approach is not perfect: withdrawal delays, centralized sequencing, and proof generation costs are real constraints. But the architecture is sound, and it opens a design space that did not exist before.

For developers building on Bitcoin, the landscape now includes multiple complementary options. Spark provides instant, self-custodial transfers and native token support with minimal infrastructure requirements: ideal for wallets, payments, and stablecoins. Citrea provides a full smart contract environment for DeFi protocols, lending markets, and programmable assets. Lightning remains the most battle-tested option for payment routing. These layers are not competing: they address different parts of the stack, and interoperability between them (via atomic swaps, Lightning bridges, or direct cross-layer transfers) will likely define the next phase of Bitcoin development.

For a deeper comparison of Bitcoin L2 architectures, see our Bitcoin Layer 2 comparison and zero-knowledge proofs on Bitcoin articles. Developers interested in building on Bitcoin's Layer 2 ecosystem can explore the Spark SDK documentation for payment and token infrastructure, or the Citrea developer docs for smart contract deployment.

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.