Citrea - Bitcoin's First ZK Rollup

Citrea is an EVM-compatible ZK rollup on Bitcoin with a BitVM-based, trust-minimized two-way peg called Clementine.

It helps BTC become a programmable asset without relying on honest-majority multisig bridges or federations, and it eliminates the risks of sidechains. Users, devs, and partners can deploy EVM apps that settle on and are reconstructible from Bitcoin alone, bringing every corner of DeFi back to Bitcoin.

A ZK rollup on Bitcoin instead of a sidechain. It uses STARK proofs to enforce validity. It verifies SNARK proofs via BitVM on Bitcoin to enable Bitcoin bridges with a 1-of-N trust assumption. It incubates Bitcoin applications for programmable money.

Citrea is a ZK rollup on Bitcoin. It has a sequencer for block production and a batch prover for proving the blocks. It submits the state diffs of the execution and the STARK proof (wrapped in a SNARK) to Bitcoin. Therefore, anyone watching the Bitcoin blockchain will be able to fetch the latest finalized state without any other trusted intermediary and will be able to verify its correctness.

Citrea also has a trust-minimized Bitcoin bridge, Clementine. Clementine uses a BitVM-based Groth16 SNARK verifier on Bitcoin itself. Due to the nature of Bitcoin, BitVM cannot do fully trustless on-chain ZK verification. However, it can optimistically attest to the correctness of a Groth16 proof. Using this idea, Clementine is a bridge protocol with operators, signers, and watchtowers that check the validity of bridge operations.

In the case of any malicious attempt, Clementine ensures that a single honest entity (1-of-N) can safely initiate the proof-verification steps, slash the malicious entities, and remove them from the bridge construction. This way, instead of relying on an honest-majority multisig, you can rely on one honest signer, and that is enough for the funds to be secure. Questions: How does this approach compare with BitVMX

Bitcoin sidechains have trust issues due to their validators. Bitcoin bridges are not reliable because their custodians are not secure enough, and they are simply honest-majority multisigs. Citrea solves both problems by being a ZK rollup on Bitcoin and having a trust-minimized ZK bridge between itself and Bitcoin.

Chainway Labs, Builders of Railgun & Privacy Pools, ex IMO-IOI medalists, computer scientists & mathematicians.

(Key Innovations - focus on the innovations, and key parts)

19 Nov 2025

1. Context: BitVM2 (The "Physics" of the Bridge)

This is the theoretical layer. It explains "How can Bitcoin verify a ZK proof?"

• The Problem: Bitcoin Script is too simple to verify a SNARK proof directly. It doesn't have the opcodes for complex math (elliptic curve pairing).

• The Solution (NAND Gates):

• Any computer program (including a SNARK verifier) can be broken down into a massive circuit of NAND gates (universal logic gates).

• BitVM2 takes the SNARK verifier function and compiles it into billions of these NAND gates.

• The Tree: Instead of putting all billions of gates on-chain (which would cost millions of dollars), they are organized into a Taproot Tree.

• The "Pinpoint" Mechanism: If the Operator says "The proof is valid," and a Challenger says "No it's not," they play a game to find the one specific NAND gate where they disagree.

• On-Chain Execution: Bitcoin only ever sees and executes that single disputed gate.

Analogy: Imagine trying to verify an entire book is correct. instead of reading the whole book on-chain, you binary search until you find the single typo on one specific page. You only publish that one page to the judge.

---

2. Notes from Your Discussion (The Citrea Implementation)

These are the specific engineering choices Citrea made to use that theory.

• The Bridge Name: Clementine.

• The Proof Pipeline:

• Step 1: Generate a STARK (fast, no trusted setup).

• Step 2: Compress it into a Groth16 SNARK (tiny proof size).

• Step 3: The BitVM circuit verifies this Groth16 SNARK.

• The "Broken Leaf": Your note "Check tree to find leafs that are broken" refers to the BitVM2 dispute game. The "leaf" is the specific step in the ZK verification logic that was computed incorrectly.

• Wait Time: Your note "Sequencer commitment = 6 blocks" implies they wait for Bitcoin L1 probabilistic finality before considering a batch safe to prove.

• Data Structure: They use Jellyfish Merkle Trees (JMT) for state storage because it's optimized for the specific type of database reads/writes needed for high-throughput rollups (unlike Ethereum's Patricia Trie).

---

3. How Clementine Works

This is the business logic wrapping the BitVM physics.

• Role: It is a 1-of-N Trust-Minimized Bridge.

• The "Optimistic" Flow:

• Deposit: User locks BTC on L1.

• Withdrawal: User burns funds on L2.

• Operator Action: The Operator pays the user out of their own pocket on L1 (front-loads the liquidity).

• Reimbursement: The Operator submits the ZK proof to the BitVM contract to unlock the original user deposits from the vault to reimburse themselves.

• Why this matters:

• The user gets their BTC immediately (from the Operator).

• The Operator takes the risk.

• If the Operator tries to steal from the Vault (by faking a proof), anyone (a Watchtower) can challenge them using the BitVM NAND gate game.

• 1-of-N: As long as there is one honest person (verifier/watchtower) online, the bridge is secure.