Zero-Knowledge Proofs on Bitcoin: From Client-Side Validation to ZK Rollups

Zero-knowledge proofs allow one party to prove a statement is true without revealing anything beyond the statement's validity. On Ethereum, this technology already secures billions of dollars across production rollups. On Bitcoin, the situation is fundamentally different: Bitcoin Script cannot natively verify ZK proofs, forcing builders to find creative workarounds. Despite this constraint, a growing ecosystem of protocols is applying ZK technology to Bitcoin for scaling, privacy, and cross-chain verification.

This article examines how zero-knowledge proofs work, which proof systems matter for Bitcoin, and the concrete projects pushing these boundaries in 2026: from RGB Protocol's client-side validation to Citrea's ZK rollup, BitVM's optimistic verification, and the OP_CAT proposal that could change everything.

What Are Zero-Knowledge Proofs?

A zero-knowledge proof (ZKP) is a cryptographic protocol where a prover convinces a verifier that a computation was performed correctly, without the verifier needing to re-execute the computation or learn any private inputs. Two properties make ZKPs particularly useful for blockchains:

• Succinctness: the proof is exponentially smaller than the computation itself, enabling a compact proof to attest to millions of transactions
• Zero-knowledge: the proof reveals nothing about the underlying data, enabling privacy-preserving verification

For Bitcoin, succinctness addresses scalability (verify large batches of off-chain transactions with a small on-chain footprint), while the zero-knowledge property addresses privacy (hide transaction amounts or other sensitive data). The two dominant proof system families are zk-SNARKs and zk-STARKs, each with distinct tradeoffs that shape which Bitcoin projects adopt them.

SNARKs vs STARKs

The choice of proof system affects security assumptions, proof size, verification cost, and quantum resistance. Both are actively used in Bitcoin projects, often in combination.

Why Groth16 dominates Bitcoin projects: Bitcoin's block space is expensive and Script is constrained. Groth16's ~192-byte proof size makes it the most practical format for on-chain anchoring. Several Bitcoin projects generate STARK proofs for their computation, then compress the final proof to Groth16 before posting to Bitcoin.

A common pattern has emerged: use STARKs for proving (no trusted setup, quantum-resistant computation) and compress the result into a Groth16 SNARK for on-chain verification (minimal footprint). Citrea, for example, processes transactions through a STARK-based zkVM and then wraps the output in a Groth16 proof before inscribing it on Bitcoin.

Client-Side Validation: RGB Protocol

RGB Protocol takes a fundamentally different approach to ZK on Bitcoin. Rather than trying to verify proofs on-chain, RGB moves all validation off-chain entirely. Asset data never touches Bitcoin's consensus layer. Instead, transactions are committed to Bitcoin via single-use seals (embedded in Bitcoin transactions) while the actual state transitions are validated by the transacting parties themselves.

From Pedersen Commitments to zk-STARKs

RGB v0.12, released in July 2025, marked a significant architectural shift. The protocol replaced its previous Pedersen commitment and Bulletproof-based confidential state system with native zk-STARK support via zk-AluVM: a compact, non-von-Neumann zero-knowledge virtual machine with just 40 instructions. This change delivered a 4x reduction in consensus code (from 8,610 to 3,198 lines) and an order-of-magnitude improvement in validation speed by separating blockchain synchronization from state verification.

The practical impact: RGB can now express confidential asset transfers where amounts and asset types are hidden using zero-knowledge proofs, verified entirely client-side without any on-chain computation. This model avoids the verification bottleneck that plagues other Bitcoin ZK approaches because Bitcoin's consensus layer never needs to evaluate a proof. In August 2025, Tether announced USDT issuance on RGB, making it the first major stablecoin deployed natively on Bitcoin through client-side validation.

Client-side validation tradeoff: RGB achieves ZK privacy and scalability by abandoning global state entirely. The sender must transmit the full provenance chain of an asset to the receiver, who validates it locally. This avoids on-chain verification costs but means every recipient must verify independently, and there is no shared ledger to query for balances.

ZK Rollups on Bitcoin

ZK rollups batch thousands of transactions off-chain, generate a validity proof attesting to their correctness, and post the proof to the base layer. On Ethereum, rollup contracts verify the proof directly via precompiled operations. On Bitcoin, this verification step is the central challenge: Bitcoin Script lacks the opcodes needed to check a ZK proof in a single transaction.

Citrea: Bitcoin's First Production ZK Rollup

Citrea launched on mainnet in January 2026 as Bitcoin's first production ZK rollup, providing full EVM-compatible smart contract execution settled on Bitcoin. The architecture works in stages: transactions are processed by a zkEVM built on RISC Zero (a RISC-V based zkVM), generating a STARK validity proof that is then compressed to Groth16 for a compact on-chain footprint. The proof is inscribed on Bitcoin, which serves as both the data availability layer and settlement layer.

For bridging, Citrea uses Clementine, a BitVM-based bridge with a 1-of-N trust model: only one honest signer is needed to ensure security. A trusted setup ceremony with 63 contributions was completed for the Groth16 verification circuit. The rollup launched with over 30 dApps, though TVL remains under $2 million as the ecosystem matures. Citrea is backed by Founders Fund, Galaxy, and Maven11.

GOAT Network and Ziren

GOAT Network is the first Bitcoin L2 built on BitVM2, powered by ZKM's Ziren zkVM (a MIPS-based zero-knowledge virtual machine). Ziren's real-time proving pipeline achieves block proofs in approximately 2.6 seconds, aggregate proofs in 2.7 seconds, and Groth16 compression in 10.4 seconds, supporting a 3.4-second block time through pipelined parallel architecture and a distributed GPU prover network. The underlying zkMIPS 1.0 launched in May 2025 with up to 19x faster proving over prior versions.

Other Bitcoin ZK Rollup Projects

Several other teams are building ZK rollups anchored to Bitcoin:

• Alpen Labs (Strata): raised $8.5 million in January 2025 for a Bitcoin ZK rollup focused on lending, stablecoins, and privacy payments. Developed Glock, a technology delivering efficiency gains over standard BitVM verification. Mainnet targeted for 2026
• BOB (Build on Bitcoin): a hybrid ZK rollup inheriting Bitcoin finality while bridging to Ethereum. BOB's implementation of BitVM3 reduced on-chain dispute costs by 87%, bringing them down to approximately $11 per dispute through garbled circuits
• Boundless (RISC Zero): launched in January 2026 for Bitcoin-based ZK proof verification and settlement of Ethereum and Base proofs

The On-Chain Verification Problem

The fundamental constraint for ZK proofs on Bitcoin is verification. Ethereum's Solidity contracts can verify a Groth16 proof with native precompiled elliptic curve operations at a cost of roughly 200,000 gas. Bitcoin Script has no equivalent. It lacks the pairing-based cryptography opcodes, arbitrary arithmetic operations, and Turing-complete looping constructs needed to evaluate a ZK proof in a single transaction.

Three approaches have emerged to work around this limitation:

BitVM: Optimistic Verification

BitVM enables Turing-complete computation on Bitcoin without consensus changes by splitting complex programs into chunks small enough for Bitcoin Script. For ZK verification, this means decomposing the Groth16 verification algorithm (multiple scalar multiplications and four pairing computations) into steps that each fit within Bitcoin's 400KB standardness limit. Verification happens off-chain by default; only if a result is disputed does an on-chain fraud proof execute the contested step.

BitVM2 improved the original design by reducing dispute resolution to three on-chain transactions and adopting a 1-of-N trust model where only one honest participant is needed for security. BitVM3 (December 2025) introduced garbled circuits, making disputes roughly 1,000x cheaper than BitVM2. Despite these improvements, the approach requires operator capital lockups, a trusted setup ceremony for the Groth16 circuit, and remains in an experimental state with immature tooling.

OP_CAT: Direct On-Chain Verification

OP_CAT (BIP-347) would reintroduce a simple stack concatenation opcode to Bitcoin Script. Despite its simplicity, this operation enables Merkle tree construction, covenant emulation via a Schnorr signature trick, and critically, STARK proof verification by splitting proofs across multiple chained transactions.

On July 12, 2024, the Bitcoin Wildlife Sanctuary project (sponsored by StarkWare) verified a Circle STARK proof on Bitcoin's Signet testnet using OP_CAT-based covenants and StarkWare's open-source Stwo prover. This was the first ZK proof verified on any Bitcoin network. The BIP-347 specification reached v1.0.0 completion in March 2026, but no Bitcoin soft fork has reached deployment stage since Taproot in November 2021. OP_CAT remains one of several competing covenant proposals alongside OP_CTV, LNHANCE, and OP_VAULT.

Sovereign Rollups: Sidestepping the Problem

Sovereign rollups post proof data to Bitcoin as inscriptions for data availability but verify proofs entirely off-chain or via separate proof networks. Bitcoin's security is borrowed for data integrity and immutability rather than proof verification. This avoids the on-chain verification bottleneck entirely but means Bitcoin's consensus does not enforce rollup validity. Users must trust the rollup's own verification network or run verification themselves.

ZK Proofs for Bitcoin Privacy

Before ZK rollups attracted attention, zero-knowledge techniques were already being applied to Bitcoin privacy. These narrower applications prove specific statements (an amount is in a valid range) without the generality of SNARK/STARK systems.

Confidential Transactions on Liquid

Blockstream's Liquid Network enables Confidential Transactions by default, using Pedersen commitments to hide transaction amounts. The homomorphic property of these commitments allows verifiers to confirm that outputs sum correctly without learning individual values. Range proofs (currently using Borromean Ring signatures for 52-bit ranges) prevent inflation by proving amounts fall within valid bounds.

Bulletproofs, short zero-knowledge range proofs without a trusted setup, were designed as an upgrade for Liquid's range proof system. Blockstream's Bulletproofs++ variant promises to reduce Confidential Transaction overhead from roughly 10x to 2x compared to unblinded transactions, though deployment on Liquid mainnet is still in progress as of mid-2026.

zkCoins and Privacy-Native Designs

ZeroSync's zkCoins project combines client-side validation with ZK proofs, targeting over 100 transactions per second with strong privacy guarantees. A first proof-of-concept was completed in March 2025. RGB v0.12's shift from Pedersen commitments to zk-STARKs similarly enables confidential asset transfers verified entirely off-chain. On the post-quantum frontier, Paradigm researcher Dan Robinson proposed PACTs (Provable Address-Control Timestamps) in May 2026: STARK proofs that privately timestamp Bitcoin address ownership today, recoverable later if quantum threats materialize.

Cross-Chain Verification: MAP Protocol

MAP Protocol uses zk-SNARKs (Groth16) for cross-chain light client verification. Instead of storing all validator public keys and weights on-chain, MAP's light clients store only commitment values. The heavy BLS signature verification and public key aggregation are expressed as arithmetic circuits and proven via Groth16, generating constant-size proofs for verification. This reduces the required number of on-chain light clients from O(N²) to O(N), with approximately 35% reduction in on-chain costs and 25% reduction in off-chain costs compared to full verification.

MAP uses Bitcoin as a checkpoint layer: MAPO clients retrieve checkpoints from Bitcoin to determine the canonical chain, protecting against long-range attacks by malicious validators. The protocol currently supports six or more public chains with over 200,000 cross-chain transactions processed.

Bitcoin vs Ethereum: ZK Ecosystem Maturity

The gap between Ethereum's ZK ecosystem and Bitcoin's is substantial. Understanding this gap clarifies both where Bitcoin stands and where opportunities exist.

The structural difference is clear: Ethereum's base layer was designed with extensibility in mind and has precompiled operations for elliptic curve pairings that make Groth16 verification trivial. Bitcoin's conservative scripting language was deliberately constrained for security and simplicity. Every Bitcoin ZK project is effectively building around a limitation that Ethereum does not have.

That said, Bitcoin's constraints have driven innovation. BitVM's optimistic verification, RGB's client-side validation, and the STARK compression-to-Groth16 pipeline are architectural patterns that emerged specifically because direct on-chain verification was impossible. Some of these designs offer advantages that Ethereum's approach does not: RGB's off-chain model, for instance, provides privacy by default without additional cost per transaction.

The Tradeoffs

Every Bitcoin ZK approach involves a distinct set of compromises. Developers and users should understand what each design gives up.

Proving Time and Cost

ZK proof generation is computationally expensive. GOAT Network's Ziren pipeline achieves block proofs in approximately 2.6 seconds with Groth16 compression in 10.4 seconds, but this requires a distributed GPU prover network. Most other Bitcoin ZK projects have not published detailed proving benchmarks. The academic literature estimates STARK proofs for Bitcoin block verification at minutes per proof. As Ethereum's ZK-ASIC ecosystem matures, similar hardware could benefit Bitcoin projects using the same proof systems.

Trust Assumptions

Trust assumptions vary significantly across the ecosystem:

• Groth16-based systems (Citrea, GOAT, MAP Protocol) require a trusted setup ceremony: if the ceremony's toxic waste is not properly destroyed, proofs can be forged. Citrea's ceremony had 63 contributions
• STARK-based systems (RGB v0.12, StarkWare/OP_CAT demos) have no trusted setup, making them transparent and quantum-resistant, but produce larger proofs that are more expensive to anchor on-chain
• BitVM-based bridges add a 1-of-N operator trust assumption on top of the proof system's own assumptions: operators must lock capital and at least one must remain honest
• Client-side validation (RGB) requires no trust in any third party for verification, but places the full validation burden on each recipient

On-Chain Footprint

Bitcoin block space is scarce and expensive. A Groth16 proof is only ~192 bytes, but BitVM dispute transactions, STARK proofs split across multiple transactions, and rollup data inscriptions all consume significant block space during edge cases or disputes. Sovereign rollups that use Bitcoin purely for data availability post all transaction data on-chain, competing directly with other Bitcoin users for block space.

The Verification Gap

Without native validity proof verification, Bitcoin ZK rollups cannot achieve the same guarantees as Ethereum rollups. BitVM-based verification is optimistic: it assumes proofs are valid unless challenged. This means security depends on at least one honest verifier watching for and challenging invalid proofs, rather than Bitcoin's consensus layer enforcing validity directly. If OP_CAT or similar opcodes are ever activated, this gap could close, but no timeline exists for such a change.

Implications for Bitcoin Layer 2 Architecture

ZK proofs could enhance Bitcoin Layer 2 architectures by enabling verifiable state transitions without revealing transaction details. For protocols like Spark, which uses FROST threshold signatures and a statechain-based architecture, ZK proofs offer a path toward proving that state transitions (key deletions, leaf splits, balance updates) were performed correctly without exposing the underlying values. This could strengthen both privacy, by hiding transaction amounts and metadata from operators, and trust minimization, by providing cryptographic evidence of correct behavior rather than relying solely on the 1-of-N operator honesty assumption.

The broader trend across Bitcoin Layer 2s is clear: as ZK tooling matures and proof generation becomes faster and cheaper, more protocols will incorporate zero-knowledge techniques, whether for rollup validity, confidential transfers, or compact state proofs. The question is not whether ZK proofs will play a role in Bitcoin's future, but which verification model (client-side, optimistic, or eventually native) will dominate.

Getting Started

For developers building on Bitcoin Layer 2 infrastructure, Spark provides an SDK and comprehensive documentation at docs.spark.money. To see how Bitcoin Layer 2 technology works in practice, explore General Bread, a Spark-powered wallet for self-custodial Bitcoin and stablecoin payments. For a broader comparison of how different Layer 2s approach scaling, see our research on the Bitcoin Layer 2 landscape and the second-layer scaling ecosystem.

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.