BitVM

What Is BitVM?

BitVM (Bitcoin Virtual Machine) is a computing paradigm that allows the verification of arbitrary computations on Bitcoin. Rather than executing programs directly on-chain, BitVM verifies that off-chain computations were performed correctly. If a prover makes a false claim about a computation's result, anyone can submit a compact fraud proof to Bitcoin's Layer 1 to disprove it.

Published by Robin Linus of ZeroSync in October 2023, BitVM represents a significant breakthrough for Bitcoin's programmability. Unlike Ethereum's EVM, which executes smart contracts on-chain, BitVM keeps all computation off-chain and only uses Bitcoin as a dispute resolution layer. This approach works within Bitcoin Script's existing limitations and requires no protocol changes.

The core insight is that any computable function can be decomposed into a circuit of basic logic gates (specifically NAND gates), and Bitcoin Script is expressive enough to verify individual gate operations. Combined with a challenge-response protocol and economic incentives, this allows Bitcoin to act as a court of last resort for any computation.

How It Works

BitVM follows an optimistic execution model. A prover stakes Bitcoin and claims that a specific computation produces a specific result. If no one challenges the claim within a timeout period, the claim is accepted. If a verifier detects an error, they initiate a challenge that resolves on-chain through fraud proofs.

Bit Value Commitments

The most fundamental building block in BitVM is the bit value commitment. Similar to Lamport signatures, each commitment uses two hash preimages to represent a single bit:

OP_IF
  OP_HASH160 <hash1>
  OP_EQUALVERIFY <1>
OP_ELSE
  OP_HASH160 <hash0>
  OP_EQUALVERIFY <0>
OP_ENDIF

The prover sets a bit to "0" by revealing the preimage of hash0, or to "1" by revealing the preimage of hash1. The security guarantee is economic: if the prover ever reveals both preimages (equivocation), the verifier can use both as a fraud proof and seize the prover's deposit.

Logic Gates in Bitcoin Script

BitVM uses NAND gates as the universal building block, since any computation can be constructed from NAND gates alone. Although Bitcoin Script has no native NAND opcode, the behavior is implemented by combining existing opcodes:

// NAND gate: output = NOT(input_a AND input_b)
<input_a> <input_b>
OP_BOOLAND    // Compute AND of the two inputs
OP_NOT        // Invert the result to get NAND
<claimed_output>
OP_EQUALVERIFY  // Verify result matches the claimed output

Each gate uses two input bit commitments and one output bit commitment. An entire program is decomposed into a circuit of these gates, potentially containing millions or billions of nodes for complex computations.

Taproot Circuit Commitment

The prover commits to the entire program by encoding each logic gate as a tapleaf in a Taproot tree. Both parties construct matching trees, and the resulting Taproot address serves as the on-chain commitment to the full circuit. This leverages Taproot's ability to commit to large numbers of spending conditions without revealing them all upfront.

Challenge-Response Protocol

When a dispute arises, the protocol resolves it through a structured on-chain interaction:

1. The prover and verifier deposit BTC into a shared Taproot output. They pre-sign a sequence of challenge-and-response transactions covering all possible dispute rounds.
2. The prover claims a computation result off-chain. If the verifier disagrees, they initiate a challenge by selecting a specific gate in the circuit.
3. The prover must reveal that gate's inputs and outputs by providing the relevant hash preimages. The verifier uses binary search (bisection) to efficiently narrow down which gate is incorrect, halving the search space each round.
4. If the prover executes a gate incorrectly or equivocates (assigns contradictory values to the same wire), the verifier constructs a fraud proof and claims the prover's deposit. If the prover responds correctly to all challenges, they recover their deposit after a timelock.

BitVM2: Permissionless Verification

Released in August 2024 by Robin Linus and co-authors, BitVM2 addresses the most significant limitations of the original design. The improvements are substantial:

• Permissionless challenges: anyone can dispute an incorrect claim, not just parties defined at setup time. This enables a 1-of-n honesty assumption where only one honest participant in the entire network is needed.
• Reduced on-chain footprint: disputes shrink from approximately 70 on-chain transactions in BitVM1 to just 3 transactions in BitVM2. Assertion data drops from roughly 1 GB to 2-4 MB.
• SNARK verification: BitVM2 implements a Groth16 SNARK verifier in Bitcoin Script. Since the verifier exceeds Bitcoin's 4 MB block size limit, the program is split into sub-programs that each fit within a single block.
• State continuity via Lamport signatures: since Bitcoin Script is stateless, BitVM2 uses Lamport signatures to connect computation steps across different transactions. Equivocation on any intermediate state automatically produces a fraud proof.

These improvements make BitVM2 practical for real-world applications like bridges and rollups, where the original BitVM1 design was largely theoretical due to its data requirements and interactive constraints.

Use Cases

Trust-Minimized Bitcoin Bridges

The most immediate application of BitVM is enabling trust-minimized bridges for moving BTC to Layer 2 networks and other chains. Traditional Bitcoin bridges rely on multisig schemes where users must trust a majority of signers. BitVM bridges replace this with a 1-of-n honesty model: funds are safe as long as at least one participant can detect and prove fraud.

In a BitVM bridge, users lock BTC in a contract on Bitcoin and receive equivalent tokens on the target chain. When withdrawing, an operator pays the user from their own funds and then reclaims from the bridge contract. If the operator submits an invalid claim, anyone can challenge it using BitVM's fraud proof mechanism.

Rollups on Bitcoin

BitVM is the key enabling technology for rollups on Bitcoin. Rollups execute transactions off-chain and submit compressed state updates to Bitcoin. BitVM provides the verification mechanism: if a rollup operator submits an incorrect state transition, any verifier can challenge it through the fraud proof protocol. Several projects are actively building Bitcoin rollups using BitVM, including Citrea (a ZK rollup) and Bitlayer. For a broader comparison of Bitcoin scaling approaches, see the Bitcoin second-layer scaling landscape.

Verifiable Off-Chain Computation

Beyond bridges and rollups, BitVM opens the door to any scenario requiring verifiable computation anchored to Bitcoin. This includes oracle result verification, complex multi-party contract execution, and cross-chain protocol coordination. Because the system is trustless and does not require consensus changes, it can be deployed incrementally without network-wide coordination.

Current Development

BitVM has moved beyond theory into active implementation. The BitVM Alliance, founded by Robin Linus and Lukas George, coordinates development across multiple teams including Citrea, Bitlayer, BOB, Alpen, and ZeroSync. Key milestones include:

• Bitlayer launched the first BitVM bridge on mainnet in July 2025, with a 1:1 BTC-pegged token (YBTC) and integrations with multiple chains.
• Citrea deployed the first complete BitVM bridge design (Clementine) on testnet in September 2024, progressing toward mainnet as what it calls Bitcoin's first ZK rollup.
• BitVM3, announced in 2025, uses garbled circuits to achieve approximately 1,000x improvement in dispute costs over BitVM2, reducing on-chain disproof data to roughly 200 bytes. This version is still in the research phase.

For more on how BitVM fits into the broader landscape of Bitcoin programmability, see the research article on Bitcoin Script programmability and the Bitcoin covenants deep dive.

Risks and Considerations

Complexity and Audit Surface

BitVM introduces significant complexity. The pre-signed transaction trees, SNARK verification in Script, and multi-step challenge protocols all expand the potential attack surface. Implementations require extensive auditing, and the novelty of the approach means there is limited production track record.

Data and Interaction Requirements

Even with BitVM2's improvements, the system requires substantial off-chain data management. Operators and verifiers must maintain the full circuit data to construct and verify fraud proofs. In BitVM1, this could reach gigabytes for complex programs. Participants must also be available to respond within timeout windows, creating liveness requirements.

No Consensus-Level Enforcement

BitVM does not add new opcodes or change Bitcoin's consensus rules. While this is a strength (no fork required), it also means BitVM's guarantees are weaker than native protocol enforcement. The security model relies on economic incentives and the assumption that at least one verifier is honest and online. If proposed covenant opcodes like OP_CAT were activated, some BitVM use cases could be implemented more efficiently at the protocol level.

Bridge-Specific Risks

BitVM bridges, while more trust-minimized than multisig alternatives, still involve bridge operators who front capital and claim reimbursement. Operator liquidity constraints, timeout misconfigurations, and challenge period attacks are all potential failure modes that bridge implementations must carefully address.

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.