BitVM: Trustless Computation on Bitcoin Without a Soft Fork

Bitcoin's scripting language was deliberately designed to be limited. There are no loops, no complex state transitions, and no way to verify arbitrary computations on-chain. For years, this meant that Bitcoin could not natively support the kind of smart contract logic that other chains take for granted. BitVM, introduced by Robin Linus in October 2023, changes that equation: it enables verification of arbitrary computations on Bitcoin through a fraud proof model, without requiring any consensus changes or soft forks.

The core insight is deceptively simple. Instead of executing computations on-chain, BitVM moves all execution off-chain and uses Bitcoin only as a court of last resort. A prover claims that a computation produced a certain result. If no one challenges the claim, it stands. If a verifier disputes it, a challenge-response protocol plays out on-chain, and the dishonest party loses their staked funds. This is the same optimistic rollup pattern used on Ethereum, but adapted to work within Bitcoin Script's constraints.

Why Bitcoin Script Cannot Do This Natively

Bitcoin Script is a stack-based, non-Turing-complete language. It supports conditional logic (IF/ELSE), cryptographic operations (signature checks, hash preimage verification), and timelocks, but it deliberately excludes loops, persistent state, and unbounded computation. Every possible execution path must be known at the time the script is created. This design prevents denial-of-service attacks and keeps validation predictable, but it also means Bitcoin cannot natively verify complex claims like "this zero-knowledge proof is valid" or "this batch of transactions was processed correctly."

Previous attempts to bring more expressivity to Bitcoin have focused on consensus changes: covenants like CTV, OP_CAT, and OP_VAULT would add new opcodes to enable spending restrictions and introspection. These proposals require soft forks and community consensus, a process that can take years. BitVM sidesteps this entirely by working within Bitcoin's existing rule set, relying on Taproot and pre-signed transaction protocols rather than new opcodes.

Key distinction: BitVM does not execute programs on Bitcoin. It verifies claims about programs that were executed off-chain. The blockchain is used only when there is a dispute, functioning as a decentralized arbitration layer.

The Original BitVM: NAND Gates on Bitcoin

The original BitVM whitepaper proposed compiling arbitrary programs into binary circuits composed entirely of NAND (NOT-AND) logic gates. NAND gates are functionally complete: any Boolean function, and therefore any computation, can be expressed using only NAND gates. This is a foundational result in computer science, and BitVM exploits it to achieve quasi-Turing completeness on Bitcoin.

How NAND Gate Circuits Work

A program is first compiled into a Boolean circuit where all operations reduce to NAND gates. Each gate takes two binary inputs and produces one output. The circuit representing even a simple program can contain billions of gates, but the structure is deterministic: given the same inputs, the circuit always produces the same outputs.

BitVM commits these gates to a Taproot address using MAST (Merkelized Alternative Script Trees). Each NAND gate becomes a tapleaf script within the Taproot tree. The prover and verifier jointly construct this tree before any funds are locked, agreeing on the circuit structure and the commitment scheme.

Bit Commitments

To prove statements about gate inputs and outputs, BitVM uses a bit commitment scheme based on hash preimages. For each bit in the circuit, the prover commits to two hash values: one representing 0 and one representing 1. Revealing the preimage for one hash locks in that bit's value. If the prover ever reveals preimages for both values of the same bit (an equivocation), the verifier can use this as proof of fraud and claim the prover's stake.

The Challenge-Response Protocol

The original BitVM protocol works in two phases. During the commit phase, the prover stakes funds and asserts a computation result. During the challenge phase, the verifier can selectively challenge specific gates in the circuit, forcing the prover to reveal the inputs and outputs of those gates on-chain. The verifier uses a bisection protocol (binary search over the execution trace) to efficiently locate the exact gate where the prover's claim diverges from the correct computation.

This bisection approach means the verifier does not need to check every gate. By repeatedly halving the search space, the faulty gate can be identified in logarithmic rounds relative to the circuit size. Once pinpointed, the verifier presents the conflicting gate on-chain, and Bitcoin Script verifies whether the NAND operation was computed correctly. If the prover cheated, their stake is forfeited.

Limitations of BitVM1

The original design had significant practical constraints that limited real-world deployment.

• The protocol was restricted to two parties (one prover, one verifier), with the verifier needing to be designated at setup time
• Dispute resolution required approximately 70 on-chain transactions, making challenges expensive and slow
• Compiling programs to pure NAND gates produced enormous circuits: a Groth16 SNARK verifier compiled to approximately 3 GB of Bitcoin Script
• The entire circuit had to be committed upfront, creating massive storage and communication overhead between parties

These limitations made BitVM1 a breakthrough as a proof of concept but impractical for production systems. The protocol demonstrated that arbitrary computation verification was theoretically possible on Bitcoin, setting the stage for more efficient designs.

BitVM2: Permissionless Verification

Robin Linus and collaborators released BitVM2 in August 2024, addressing the most critical limitations of the original design. BitVM2 represents a fundamental architectural shift from interactive bisection games to succinct fraud proofs using zero-knowledge proof verification.

Key Improvements

The most important change is permissionless verification. In BitVM1, verifiers had to be predetermined during setup. If the designated verifier went offline or was compromised, the prover's claim would go unchallenged. BitVM2 allows anyone to act as a verifier, even parties who were not involved in the original setup. This dramatically strengthens the security model.

BitVM2 also reduced the on-chain dispute resolution from approximately 70 transactions down to 3 to 4 transactions. The challenge period was compressed to approximately 2 weeks, compared to the potentially months-long process in BitVM1. This was achieved by replacing the interactive bisection protocol with a single-round challenge mechanism based on SNARK verification.

SNARK Verification in Bitcoin Script

BitVM2 shifts the verification target from raw NAND gate evaluation to verifying zero-knowledge proofs. Specifically, it implements a Groth16 SNARK verifier encoded in Bitcoin Script. The prover executes an arbitrary program off-chain, generates a SNARK proof of correct execution, and publishes the proof. If challenged, the on-chain dispute resolves whether the SNARK proof is valid.

Implementing a full Groth16 verifier in Bitcoin Script is non-trivial. Bitcoin Script lacks native big-integer arithmetic, meaning the elliptic curve operations required for pairing-based cryptography must be emulated using only the available opcodes. Early implementations required approximately 1.2 GB of script, though optimization techniques (batched multi-scalar multiplication, affine coordinate representations, and hint-based verification) have reduced this substantially. Research from Alpen Labs and others has pushed the script size below 1.1 GB using these techniques.

The script is split across multiple Tapscript leaves within a Taproot tree. Each leaf contains a sub-program that verifies a portion of the SNARK verification computation. During a dispute, only the relevant leaves are revealed on-chain, keeping the actual on-chain footprint to a few megabytes rather than the full script size.

BitVM3: Garbled Circuits

Robin Linus presented BitVM3 at Bitcoin Amsterdam in 2025, introducing another major architectural shift. Instead of encoding verification logic in Bitcoin Script, BitVM3 uses garbled circuits to move nearly all computation off-chain.

In this model, the challenger evaluates a garbled circuit off-chain and obtains a fraud proof only if the operator's claims are incorrect. The on-chain footprint is dramatically reduced: total dispute costs drop to approximately $9 at typical fee rates, with individual challenge transactions costing around $0.20. This represents roughly a 1,000x improvement over BitVM2's on-chain costs.

BitVM3 remains in the research phase as of mid-2026, with critical security and scaling questions still being addressed. The BOB (Build on Bitcoin) engineering team has implemented initial proof-of-concept work using cut-and-choose verification with adaptor signatures on mainnet Bitcoin transactions.

The 1-of-N Trust Model

BitVM's security rests on what is called the 1-of-n honest verifier assumption. Out of n participants who could potentially challenge a fraudulent claim, only one needs to be honest and online for the system to remain secure. This is a significantly weaker trust assumption than traditional multisig bridges, which typically require an honest majority (t-of-n where t > n/2).

In practice, this means that as long as a single party is willing to monitor the system and submit a fraud proof when it detects an invalid claim, no funds can be stolen. The verifier does not need special permissions or pre-registration (in BitVM2 and beyond): anyone with a Bitcoin node and the verification software can serve as a watchtower.

Trust comparison: A typical multisig bridge with 5-of-9 signers requires that at least 5 participants remain honest. BitVM requires only 1 honest verifier out of potentially thousands. This is the same security assumption behind optimistic rollups on Ethereum, a model that has proven effective in practice.

Practical Applications

BitVM's primary use cases center on infrastructure: bridges, rollup settlement, and cross-chain verification. These are backend systems, not user-facing applications. The protocol is too complex and latent for interactive use, but it can secure the foundational layers that user-facing protocols depend on.

Trust-Minimized Bitcoin Bridges

The most immediate application is trust-minimized bridging of BTC to other chains. Traditional Bitcoin bridges rely on multisig committees to custody locked BTC, creating honeypots that have been exploited repeatedly. A BitVM bridge replaces the multisig with a fraud-proof mechanism: the bridge operator posts a bond, and any verifier can challenge an invalid withdrawal by proving fraud on-chain.

Bitlayer launched the first production BitVM bridge on Bitcoin mainnet in July 2025, enabling BTC to be used in DeFi applications across multiple chains. BOB (Build on Bitcoin) launched a BitVM bridge testnet in early 2025, with mainnet planned for later that year. The BitVM Bridge paper by Robin Linus details the architecture for a bridge where operators advance liquidity for withdrawals and are reimbursed from the bridge pool, with fraud proofs ensuring they cannot steal funds.

Rollup Settlement on Bitcoin

BitVM enables Bitcoin to serve as a settlement and data availability layer for rollups. Projects like Citrea are building ZK rollups that post state commitments to Bitcoin and use BitVM for dispute resolution. This brings Ethereum-style rollup scaling to Bitcoin without modifying Bitcoin's consensus rules.

The settlement model works as follows: the rollup operator publishes a state root to Bitcoin. If the state root is correct, nothing happens on-chain beyond a single commitment transaction. If it is incorrect, a verifier can use BitVM to prove that the state transition was invalid, triggering a rollback and slashing the operator's bond.

Oracle and Cross-Chain Verification

BitVM can also verify oracle data feeds on Bitcoin. An oracle operator commits to a data feed value and stakes collateral. If the reported value is incorrect, a verifier can prove this through the challenge protocol, slashing the oracle's bond. This is particularly relevant for discreet log contracts and other Bitcoin-native financial instruments that depend on external data.

Criticisms and Open Problems

BitVM is not without significant limitations, and understanding them is important for evaluating where the technology fits in the Bitcoin scaling landscape.

On-Chain Footprint

When disputes occur, the on-chain cost is substantial. BitVM2 assert transactions are approximately 4.8 MB, and disprove transactions are 3.5 to 4 MB. These nearly fill entire Bitcoin blocks, which have a 4 MB weight limit under SegWit. While disputes are expected to be rare (the optimistic assumption), a burst of simultaneous challenges could congest the network. BitVM3's garbled circuit approach addresses this, but it remains in research.

Challenge Period Latency

BitVM2's challenge period is approximately 2 weeks. During this window, withdrawals from a BitVM bridge cannot be fully finalized. Operators can advance liquidity to provide faster withdrawals, but this introduces capital costs and operational complexity. Compared to validity proof systems that achieve finality as soon as a proof is verified, the optimistic model trades speed for simplicity.

Implementation Complexity

Building a BitVM system is extraordinarily complex. Implementing a Groth16 verifier in Bitcoin Script requires emulating big-integer field arithmetic using only the limited opcodes available. The Taproot trees containing the verification scripts span hundreds of thousands of leaves. Bugs in any of these scripts could allow a malicious prover to steal funds or prevent legitimate challenges. The attack surface is large, and formal verification of these scripts is still in early stages.

Liveness Requirements

The 1-of-n security assumption requires that at least one verifier is online and watching at all times. If all verifiers go offline during a challenge window, a fraudulent claim goes unchallenged. This is not a theoretical concern: maintaining verifier infrastructure requires operational commitment and resources. The permissionless verifier model in BitVM2 mitigates this by allowing anyone to step in, but someone still needs to be running the software.

Fixed Denomination Constraints

Current BitVM bridge implementations use fixed denominations for peg-in and peg-out amounts. Users cannot bridge arbitrary amounts; they must use predetermined sizes. This is a practical limitation driven by the need to pre-sign transaction trees during the setup phase. Future iterations may address this, but it currently limits user experience.

BitVM in the Bitcoin L2 Landscape

BitVM occupies a specific niche in the broader Bitcoin Layer 2 landscape. It is not a Layer 2 protocol itself but rather a primitive that other Layer 2 protocols can use for settlement and bridging. Understanding where it fits relative to other approaches helps clarify its value.

Lightning provides instant payments through payment channels but cannot verify arbitrary computations. Liquid uses a federation for faster settlement but requires trusting the majority of federation members. Spark uses statechains with FROST threshold signatures for instant transfers with a 1-of-n operator trust model. BitVM enables a different class of applications: verifiable computation and trust-minimized bridges.

Spark's statechain model does not require BitVM for its core functionality. Spark transfers work through key rotation and pre-signed exit transactions, enabling instant settlement without on-chain computation verification. However, BitVM could enable new forms of interoperability between Bitcoin Layer 2 protocols. A BitVM bridge could connect different L2 networks in a trust-minimized way, enabling users to move assets between systems without relying on centralized intermediaries.

What Would Change with New Opcodes

Several proposed Bitcoin covenant opcodes would significantly improve BitVM's efficiency if activated. OP_CAT, which concatenates two stack elements, would dramatically simplify the Tapscript-based verification logic. Covenants like CTV would reduce the pre-signing requirements by allowing scripts to constrain how outputs are spent.

Even without these opcodes, BitVM works today. The progression from BitVM1 to BitVM2 to BitVM3 shows that significant optimization is possible within existing Bitcoin Script. But new opcodes would shift the efficiency frontier, potentially reducing dispute costs by orders of magnitude and making the technology accessible to a broader range of applications.

Current State and What to Watch

As of mid-2026, BitVM has moved from theoretical research to early production deployment. Bitlayer's BitVM bridge is live on mainnet, multiple teams are building rollup infrastructure, and the BitVM3 research track promises further efficiency gains. The BitVM Bridge paper received the Bitcoin Research Prize in 2025, and the ZeroSync Association (Robin Linus's organization) continues to drive core protocol development.

Key milestones to watch include BitVM3's maturation from research to implementation, additional bridge deployments, and the growing ecosystem of rollups settling on Bitcoin. The technology's impact on bridge security alone could be transformative: replacing multisig committees with fraud proofs fundamentally changes the risk profile of cross-chain Bitcoin transfers.

For developers interested in building on Bitcoin's evolving Layer 2 infrastructure, the Spark SDK documentation provides a starting point for integrating instant Bitcoin and stablecoin transfers. While BitVM addresses the computation verification layer, protocols like Spark solve the everyday payment layer, and the two approaches are complementary. For further reading on how Bitcoin scaling approaches compare, see our Bitcoin Layer 2 comparison.

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.