Validity Proof

What Is a Validity Proof?

A validity proof is a compact cryptographic proof that demonstrates a set of computations was performed correctly. In the context of blockchain scaling, it allows a rollup operator to execute thousands of transactions off-chain, then submit a single proof to the base layer (such as Ethereum or Bitcoin) that attests to the correctness of every transaction in the batch. The base layer verifier checks this proof instead of re-executing each transaction, reducing on-chain work by orders of magnitude.

The term "validity proof" is more precise than the commonly used "ZK proof" or "ZK rollup." Most rollups labeled as "ZK rollups" use validity proofs to prove computational integrity but do not actually hide any data: all transaction details remain public. A true zero-knowledge proof has the additional property of concealing the underlying information. The industry frequently conflates the two, but the distinction matters: validity proofs guarantee correctness, while zero-knowledge proofs guarantee both correctness and privacy.

Validity proofs stand in contrast to fraud proofs, used by optimistic rollups. With fraud proofs, batches are assumed correct unless someone challenges them during a dispute window (typically seven days). With validity proofs, correctness is proven upfront: invalid state transitions are mathematically impossible to accept. This eliminates the need for a challenge period and enables near-instant finality once the proof is verified on-chain.

How It Works

The lifecycle of a validity proof in a rollup follows a consistent pattern regardless of the specific proof system used:

1. The rollup sequencer collects user transactions and executes them off-chain, producing a new state root
2. A prover takes the pre-state root, the batch of transactions, and the post-state root, then generates a validity proof attesting that the state transition is correct
3. The proof, along with the new state root and compressed transaction data, is submitted to a verifier contract on the base layer
4. The verifier checks the proof against the public inputs (pre-state root, post-state root, transaction batch commitment) in a single, cheap operation
5. If the proof is valid, the rollup contract updates its canonical state. If invalid, the transaction reverts and the state remains unchanged

The critical insight is asymmetry: generating a proof is computationally expensive (often 100x or more overhead compared to simply executing the transactions), but verifying it is extremely cheap. A proof covering thousands of transactions can be checked in milliseconds with minimal gas cost on the base layer.

SNARKs vs. STARKs

Two families of proof systems dominate validity proof construction, each with meaningful tradeoffs:

SNARKs (Succinct Non-Interactive Arguments of Knowledge) produce extremely compact proofs. A Groth16 proof is just 192 to 384 bytes regardless of the computation size, while PLONK proofs are around 576 bytes. Verification is fast and constant-time: roughly 3 milliseconds for Groth16. The tradeoff is that most SNARK constructions require a trusted setup ceremony. If the ceremony is compromised, an attacker could forge proofs for invalid state transitions. SNARKs also rely on elliptic curve cryptography, making them vulnerable to future quantum computers.

STARKs (Scalable Transparent Arguments of Knowledge) eliminate the trusted setup entirely, using only hash functions and publicly verifiable randomness. They are considered quantum-resistant because they do not depend on elliptic curves. The cost is larger proofs: typically 40 to 165 KB, roughly 100 to 180 times larger than SNARK equivalents. Verification takes longer (around 18 milliseconds) and costs more gas on-chain.

In practice, many production systems use a hybrid approach: generate a STARK proof internally for its transparency and security properties, then wrap it in a final SNARK proof for cheaper on-chain verification. Projects like Polygon zkEVM and zkSync Era employ this strategy.

Verification Cost on the Base Layer

On Ethereum, verifying a validity proof costs far less than re-executing the underlying transactions. Typical gas costs by proof system:

Because each proof covers an entire batch, the per-transaction cost can be remarkably low. StarkNet has achieved verification costs as low as 315 gas per transaction by amortizing a single proof across hundreds of transactions. Approximately 90% of the total L1 gas cost for a validity rollup goes to data availability (posting compressed transaction data), not proof verification itself.

Validity Proofs on Bitcoin

Bitcoin's scripting language is far more constrained than Ethereum's EVM, making direct on-chain proof verification a significant challenge. Two complementary approaches have emerged to bring validity proofs to Bitcoin, each with different tradeoffs and timelines.

BitVM-Based Verification

BitVM, introduced by Robin Linus in October 2023, enables arbitrary computation verification on Bitcoin using only existing consensus rules: no soft fork required. It works through an optimistic model: a prover claims a computation result is correct and posts a bond. If the claim is false, any verifier can submit a succinct fraud proof on-chain, and the dishonest prover forfeits their deposit.

For validity proof verification specifically, BitVM runs a SNARK verifier (typically Groth16) within Bitcoin Script. The verifier program is far too large for a single transaction, so it is split into approximately 1,000 chunks organized in a Merkle tree. Only a 32-byte root commitment goes on-chain during normal operation. The full verification data remains off-chain unless a dispute occurs.

BitVM has evolved through three generations. BitVM1 (2023) required up to 70 on-chain transactions to resolve disputes and was limited to designated verifiers. BitVM2 (August 2024) reduced disputes to three transactions resolvable within one to two weeks and introduced permissionless challenging: anyone can dispute a false claim. BitVM3 (2025) uses garbled circuits to move SNARK verification entirely off-chain, reducing dispute costs by roughly 1,000x to under $1 per fraud proof.

Citrea, built by Chainway Labs, became the first Bitcoin ZK rollup to reach mainnet in January 2026. Its Clementine bridge uses BitVM2 to enable trust-minimized BTC transfers between Bitcoin L1 and the rollup. The security model requires only one honest verifier among any number of participants to maintain bridge integrity.

OP_CAT-Enabled Verification

OP_CAT (BIP-347) would reactivate Bitcoin's original concatenation opcode, enabling direct STARK proof verification in Bitcoin Script. Despite its simplicity (it concatenates two stack elements), OP_CAT unlocks Merkle proof verification and covenant construction: the two building blocks needed for on-chain proof checking.

In July 2024, StarkWare demonstrated a working STARK verifier on Bitcoin's signet using OP_CAT: the first zero-knowledge proof verified on a Bitcoin network. The proof was split across multiple transactions chained together via OP_CAT-based covenants, with each transaction verifying a portion and passing intermediate state to the next.

The BIP-347 specification was marked complete in March 2026, but no activation timeline exists for Bitcoin mainnet. Community opinion remains divided: proponents argue OP_CAT enables a broad class of smart contracts through a minimal, well-understood opcode, while critics worry about recursive covenants and increased protocol complexity. Activation could take years, or may not happen at all.

Use Cases

• Rollup scaling: validity proofs are the core mechanism enabling ZK rollups to process thousands of transactions per second while inheriting base layer security. On Ethereum, projects like StarkNet, zkSync Era, Scroll, and Polygon zkEVM are live in production
• Trust-minimized bridges: validity proofs enable cross-chain bridges where the bridge contract cryptographically verifies that funds were correctly locked on the source chain, eliminating reliance on trusted multisig committees
• Instant chain synchronization: ZeroSync is building STARK-based proofs of Bitcoin's entire blockchain, which would allow new nodes to verify the chain state from a single compact proof instead of downloading and validating every block since genesis
• Privacy-preserving transactions: when combined with true zero-knowledge properties, validity proofs can verify that a transaction follows protocol rules (correct balances, valid signatures) without revealing sender, receiver, or amount
• Bitcoin programmability: through BitVM and OP_CAT, validity proofs bring general-purpose smart contract execution to Bitcoin without modifying its consensus layer, as explored in depth in the Bitcoin second-layer scaling landscape

Why It Matters

Validity proofs solve the fundamental tension between blockchain scalability and security. Traditional approaches to scaling either sacrifice decentralization (larger blocks, fewer validators) or security (trusted bridges, sidechains with weaker consensus). Validity proofs offer a third path: move execution off-chain while preserving the security guarantees of the base layer through mathematical proof.

For Bitcoin specifically, validity proofs represent the most promising path toward trust-minimized Layer 2 systems. Unlike federated sidechains that rely on multisig committees, or Lightning channels that require both parties to remain online, a validity-proven rollup can support arbitrary smart contract logic with security backed by Bitcoin's proof-of-work consensus. The OP_CAT covenant debate and BitVM development are actively shaping how this technology will reach Bitcoin users.

Risks and Considerations

Prover Centralization

Generating validity proofs requires specialized hardware and significant computational resources: often 100x overhead compared to simple execution. In practice, most rollups rely on a single centralized prover or a small set of provers. If the prover goes offline, the rollup cannot produce new state updates. Decentralizing the prover role remains an active area of research across the industry.

Trusted Setup Risk

SNARK-based systems like Groth16 require a one-time trusted setup ceremony. If every participant in the ceremony colludes or if the ceremony is fundamentally flawed, it becomes possible to forge proofs for invalid state transitions. STARK-based systems and newer SNARK constructions (such as Halo 2) eliminate this requirement, but many production systems still depend on trusted setups.

Circuit Bugs

The proof circuit: the mathematical representation of the computation being proven: is extremely complex. A bug in the circuit could allow invalid state transitions to produce valid-looking proofs. Unlike smart contract bugs that can sometimes be patched, a circuit bug undermines the fundamental security guarantee of the entire system. Rigorous auditing and formal verification of proof circuits is critical but difficult.

Bitcoin-Specific Limitations

On Bitcoin, direct validity proof verification remains constrained by Bitcoin Script limitations: the 4 MB witness size limit, the 520-byte stack element limit, and the absence of general arithmetic opcodes. BitVM works around these constraints using an optimistic model, but this reintroduces challenge periods (one to two weeks) and capital bond requirements for operators. True on-chain validity proof verification on Bitcoin awaits either OP_CAT activation or dedicated ZK verification opcodes, neither of which has a concrete timeline.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.