BitVM
BitVM is a computing paradigm, introduced by Robin Linus in October 2023, for verifying arbitrary computations on Bitcoin without changing consensus rules. Computation runs off-chain. Bitcoin is used as a dispute court: a prover claims that a function evaluated to a particular output, and if the claim is false a verifier can punish the prover with a succinct fraud proof. The original paper compared the model to optimistic rollups.
Bitcoin Script is deliberately limited. It has no loops, a small set of opcodes, and no general way to verify an arbitrary program on-chain. Proposals that would add that capability as a consensus change require a Softfork and have not been activated. BitVM takes a different route: it encodes a verifier as a large Taproot tree of pre-signed transactions and hashlocks, so that only the disputed fragment of a computation is executed on-chain, and only if the parties disagree.
The first design committed to a Boolean circuit, typically NAND gates, bit by bit in Taproot leaves. Prover and verifier jointly pre-signed a challenge–response sequence. As long as they cooperated, the computation left no extra on-chain footprint. A dispute required many interactive bisection steps, and only a fixed set of parties who had participated in setup could challenge. Those limitations motivated later revisions.
In the original model, the parties compile a program to a circuit and commit to each gate in a Taproot address. They exchange the data needed to evaluate the circuit off-chain and deposit funds to the resulting address. The prover later asserts an output. If the verifier disagrees, the two follow the pre-signed challenge path, repeatedly asking the prover to reveal intermediate bits until a single gate is isolated. That gate is evaluated in Script. A false assertion is then unsatisfiable, and the honest party claims the deposit. Timelocks bound the game so that silence loses.
BitVM2, published in 2024 with collaborators including Lukas George and others associated with the ZeroSync project, changes the verification target. Instead of walking a NAND circuit, the prover produces a SNARK (the published design uses Groth16) that the off-chain program executed correctly. The SNARK verifier is itself split into sequential sub-programs small enough to fit in a Bitcoin block. If challenged, the operator must reveal intermediate states of that verifier. Anyone who can run a full node may then execute one sub-program on-chain and show a mismatch. The dispute is specified to complete in a small number of transactions (the BitVM2 paper describes three), and challenging is permissionless rather than limited to the setup participants.
BitVM3 research, presented in 2025, moves more of the verifier into garbled circuits so that almost all work stays off-chain and a dispute reveals a compact opening. All three generations share the same security claim: as long as at least one honest party is willing to challenge within the timeout, a false assertion cannot steal the locked coins. They also share the same limitation: setup still requires an n-of-n pre-signing of the transaction graph, so operators and counterparties must be available at setup time even if later challenges are permissionless.
The main applied design built on this mechanism is a bridge that locks bitcoin on the main chain and credits an operator-managed second layer (sometimes discussed alongside Sidechain and Lightning Network designs), with a BitVM dispute path if the operator claims an invalid withdrawal. The construction does not make Bitcoin Turing-complete for ordinary payments. It makes fraud proofs about off-chain computation expressible in today's Script.
BitVM is a design and a set of open-source libraries, not a consensus change and not a wallet feature. The ZeroSync-associated BitVM implementation in Rust, together with SNARK-verifier scripts used in BitVM2, is the reference codebase. Bridge prototypes have been built by several teams. Whether a particular bridge is in production is independent of the BitVM papers and should be evaluated on that project's own documentation. No Bitcoin Core change is required to use BitVM. Related terms such as Tapscript and covenant proposals are separate from BitVM itself.