Join our community

Secure, Extensible, Open-Source

BitVMX is a new framework to optimistically execute arbitrary programs in Bitcoin based on the N-party disputable computation paradigm pioneered by BitVM. BitVMX framework provides the foundations to run any CPU on Bitcoin, with a focus to run a fully-compliant RISC-V processor programmable using a standard compilation toolchain.

Our vision is to create a secure, extensible, open-source, peer-reviewed and sidechain-agnostic framework that can be used to develop blockchain bridges, aggregator oracles, and SNARK/STARK verifiers. As soon as BitVMX is able to run a SNARK verifier, a myriad of new use cases can be brought to Bitcoin, from ZK-rollups to crazy use cases such as Zero Knowledge Contingent Payments (i.e. autonomous bug bounties paid for disclosure of vulnerabilities).

How Does BitVMX Work

BitVMX represents a new form of covenant that does not require a soft or hard fork to Bitcoin. Funds can be locked in an UTXO with a spend condition that depends on the result of the execution of a program. While the program must be defined when the UTXO is created, the program input does not. In its simplest form, this is a two-party protocol where a first participant is the operator and the second is the verifier. First, both of them initially collaborate to create a small set of presigned transaction that guide the dispute resolution protocol. Also both compute an initial deposit address. Funds sent to this address will be governed by the predefined program. One of the precreated transactions is the first kick-off transaction that signals the intention for the prover to withdraw the funds. After the setup, the parties can lock funds and security deposits into the protocol and the funds can’t be spent until the withdrawal kick-off transaction is included in the blockchain.

At a later time, when the operator wants to withdraw the locked funds, she posts the kick-off transaction together with the input that makes the program halt with an exit code that represents success. The input is always available to the verifier. The verifier watches the operator and executes the program locally to check the correctness of the execution. If the verifier detects cheating, she will challenge the operator and both of them enter a Dispute Resolution Protocol (DRP) on the Bitcoin blockchain (the DRP protocol is sometimes called the “Verification Game”) .

In the DRP, the verifier becomes the challenger, the goal is to prove that the operator has cheated, and the operator becomes the responder (also known as prover), the goal is to respond to each challenger question, and prove she has not cheated. All responses provided by the responder are signed, so that the challenger can use the responder’s responses in the further stages of the protocol to prove cheating.

The DRP is as follows: both the responder and the challenger locally execute the program associated with the UTXO with a predefined CPU and output the execution trace. The trace is a list of steps until the CPU halts. Each step of the trace represents a step of the execution. For each step, the honest parties compute a step hash, which compresses the previous step hash, along with the outputs of the current step, forming a cryptographically secure hash chain. The goal of the challenger in the DPR is to find a point in the trace where a “malfunction” occurs. This is the point where the computation was being executed correctly until it was no longer. To find the malfunction, the challenger will ask the prover to sign and publish different step hashes chosen by the challenger. To speed up the search, the challenger will use a n-ary dissection search.

The following simplified diagram shows how operator and verifier follow the trace dissection search protocol:

Formally, we define malfunction as a pair of consecutive steps such that the fist step has a correct step hash (which is signed by the responder), and the second step has an incorrect step hash (also signed by the responder). The malfunction is defined from the point of view of the challenger. From the point of view of the responder, there is no CPU fault: either she is cheating when providing the step hashes or she is providing the correct step hashes but the challenger still wants to engage in the DPR for some unknown reason. However, BitVMX DPR is different from other dispute protocols. In TrueBit and BitVM CPU dispute protocols, a Merkle tree of all hash steps is used for the verifier to find the first point of malfunction. In BitVMX we don’t use a tree data structure and the verifier only finds a point of malfunction, which may not be the first. However, the protocol gives enough information for the verifier to be able to prove that the operator has cheated in a number of communication rounds which is logarithmic to the number of executed steps.

Once the challenger knows the malfunctioning step, the next thing she must do to prove cheating is to learn what sub-operation within the step execution was faulty. The CPU does multiple things in one step: it reads a number of words from memory, it reads the program counter (PC), it fetches the opcode, it performs a computation and it writes back the results to one or more memory words. Any of these sub-operations may be incorrect.

Proving an incorrect PC is as simple as comparing the PC in the incorrect step with the PC written by the correct step immediately preceding it. Assuming correct input (the memory words, the PC and the opcode), proving an incorrect computation output is easy by executing the step onchain and comparing the onchain results with the results embedded in the responder’s signed step trace.

Proving an incorrect memory read takes a bit longer, because BitVMX does not merkelize the memory, but nevertheless it’s easy. Embedded in the trace, the responder always includes the step number corresponding to the last trace step when the memory word read was written. The challenger learns this and requests the trace step hash of that memory writing step. If the memory writing step hash is correct, the challenger can easily prove that the responder cheated, because the value written in the writing step must differ from the value read by the step reading the memory word. If the trace step hash is incorrect, then the challenger has found an incorrect step followed by a correct one (remember that originally the challenger found two consecutive steps, one correct and the other incorrect). Therefore the challenger and the responder can engage in a second step searching protocol on the trace, but this time the challenger tries to find a “recovery”, which is defined as a pair of steps where the first is incorrect, but the second is correct. Obviously such a miraculous recovery is infeasible in practice, because it means that the prover found by chance two different hash chains that end with the same hash digest (the correct step hash). Therefore we assume the  prover is cheating. Once the challenger finds this new pair of consecutive steps, she can just challenge the computation of the hash function that links both step hashes.

The following diagram describes the two search processes, the first searching from the start of the trace to the last step (F), finding the malfunction step (q) referencing a last write step (t),  then finding the recovery point (w):

The following flowchart represents the main challenger decision tree (simplified):


From Two-Party to N-Party

The BitVMX protocol can be easily described as a game of two parties, where they initially collaborate to create the transaction templates that establish a covenant DAG that guides the dispute process. Moving from two-party to N-party (N>2) is possible, but not straightforward, as there are multiple design decisions to make, as there can be collusion between parties.  Should there be one or multiple provers? Should all verifiers collaborate during the dispute or should each verifier proceed independently ? Should verifiers trust on the other verifier’s dispute process while it is conducted honestly or should they aggressively challenge as fast as they can to avoid losing valuable challenge time? If not a single UTXO but multiple UTXOs are encumbered by BitVMX covenants, then there are even more design choices to make. Should security bonds be shared? Should operator withdrawals  be rate limited to prevent overloading the verifiers? During the course of our research,  we plan to extend the 2-party protocol to multi-party and support different staking and parallel dispute models.

One of the properties that is inextricable to BitVM and derived protocols is that there is at least one transaction (the kick-off) which must be presigned by a set of parties (a committee), and if all those parties cheat, and later generate a different kick-off transaction, they can steal the funds. Since nobody can formally prove that she has destroyed a private key, users must trust this commitee. The consequence is that BitVM and derived protocols have a 1-of-N honesty assumption, where N is the size of the committee. This is true even if the DRP could be made permissionless and anyone could challenge.

Disputable Computation Paradigm

BitVM was the first attempt to bring the Disputable Computation paradigm to Bitcoin, it was conceived in Oct 2023 by Robin Linus. Under this paradigm, if all parties involved agree on the computation result, no computation is performed onchain. In case any party disagrees, an onchain interaction begins to formally and efficiently solve the dispute: in the worst case, only a single disputed gate, wire or step of the computation is verified onchain.

The Disputable Computation paradigm was first envisioned by the TrueBit project back in 2017 to be used for arbitration and later applied to the creation of blockchain bridges. Due to its average low computing cost, the paradigm was chosen by Optimistic Rollups to build 2nd layers on altchains.

The closest protocol to BitVMX is BitVM, but BitVM does not refer to a single concept, but four:

  1. The BitVM Gate-based protocol (a.k.a. tapleaf circuits or "BitVM0"),  partially defined in the BitVM white paper
  2. The BitVM CPU design that was informally presented by Robin Linus in several talks and interviews (currently called BitVM1).
  3. The partially implemented BitVM CPU, now deprecated, also authored by Robin Linus.
  4. The BitVM2 single-challenge protocol, partially defined here.

We’ll refer to the CPU when disambiguation is required. Since there is no full formal description of this BitVM CPU, we can only make our comparisons against the straightforward design we reconstruct from Linus’s interviews.

BitVMX vs BitVM (gate-based)

The BitVM gate-based protocol (BitVM0) is considered only of theoretical interest, it’s impractical for all interesting use cases, such as SNARK verification of running a sidechain light client. In contrast, BitVM CPU (a.k.a. BitVM1) and BitVMX are fully practical.


The BitVMX CPU is similar to the BitVM CPU in that it searches through the trace of the program execution. The “circuit” of BitVM is replaced by the trace of all instructions executed, where all loops are unrolled. However, the CPU protocols differ in the way information is exchanged, and instructions and memory hashed. In contrast with the BitVM CPU, BitVMX does not require the creation of a Merkle tree of instructions, nor a Merkle tree of memory words, nor even the use of the taproot tree! This makes BitVMX far more efficient to set up, and evaluate. BitVMX prover and verifiers build only a sequential hash chain that includes the outputs produced at each step plus each previous step hash.  By using memory mapped registers, the output of any instruction consists of two words written to memory, one of them being the program counter. This information is enough to perform an n-ary search over the trace.

To avoid the need for memory merkelization, BitVMX uses a new challenge/response protocol to detect memory access faults based on tracking the last time each memory cell was written. Combined with shorter hash inputs, BitVMX linear hashing method enables the use of arbitrary amounts of memory and runs the virtual processor locally more than two times faster than the BitVM CPU.

BitVMX construction is flexible enough to support the implementation of most of the existing CPUs, ranging from 8-bit to 64-bit cores. For example, it’s easy and efficient to implement a MIPS core, or even a 64-bit RISC-V processor and run a Linux application on top of BitVMX. In contrast, BitVM CPU is designed for a single CPU type that is non-standard. RISC-V programs require translation to be run in the BitVM CPU. While BitVMX is flexible to run both RISC and CISC cores, RISC processors result in a simpler implementation. CISC processors may require longer scripts, increasing the challenge/response cost. Implementing a CISC processor on BitVMX would probably require the prover to show intermediate results for microinstructions, and the verifier to challenge microinstructions instead of full instructions.

BitVM CPU is designed to perform a binary search on the trace. This is an inherent limitation of BitVM CPU, as adding additional branches in the tree increases the complexity of the design. The BLAKE3 hash function implemented in the BitVM CPU only hashes two 32-byte elements into one digest (a 2:1 compression). Adding more branches at each level of the tree requires some tricks. You can stack this 2:1 compression function multiple times (but you need to allow the verifier to challenge the intermediate hashes) or you can expand the size of the hash function input message. This last option is prohibitive due to the consequential expansion of the Bitcoin script. Currently BLAKE3 2:1 compression consumes 100 Kbytes of script. A 4:1 compression would reach the standard transaction limit. An additional trick (also used by BitVM2) is to split BLAKE3 computation into sub-functions and let the prover provide signed midstates for the verifier to choose which sub-function to challenge. This trick could reduce the script size 50%. However, all these tricks would make the BitVM CPU much more complex for limited benefits. On the contrary, BitVMX allows a smooth tradeoff between worse case round complexity and the amount of data included in transactions by allowing the free selection of the branch factor in the trace search. For example, using a binary search over a 32-bit space trace BitVMX requires 70 transactions in the worst case, while BitVM requires 40. But using a 4-way search, we can reduce it to 36, outperforming BitVM CPU. Remarkably, we found an optimization to BitVMX to reduce the number of transactions to 20 using a 16-way search (4 bits per query) without increasing the transaction payload assuming both prover and verifier act rationally during the dispute! This means that under approximately equally-sized payloads, the BitVMX worst case challenge period would be half of BitVM’s period. Increasing the number of hashes revealed in each iteration of the search we can reduce the number of rounds of the search. The impelmentators of BitVMX should choose thor sweep spot between challenge period and transaction cost.

BitVMX vs BitVM2

While the BitVM CPU attempts to run any user-defined program, BitVM2 focuses on running only a SNARK verifier, which in turn is capable of verifying the correct execution of longer programs. Instead of compiling the program directly to BitVM CPU or BitVMX, the BitVM2 protocol requires creating a SNARK circuit to prove the execution of the program (setup), then proving the program execution for a particular input. Advanced ZK virtual machines such as ZKVM can alleviate the task of writing the circuit, by leveraging on compilers that accept procedural languages. Nevertheless, these rely on STARK provers, so that the SNARK verifier must verify the execution of a STARK verifier which in turn verifies the execution of the program. This technique has both benefits and disadvantages. For complex programs, such as sidechain withdrawal verifications, there are several benefits of running a SNARK verifier. If the input is long, and there is no need to make the input publicly available, then the SNARK circuit can accept the input as a private witness. BitVMX requires all inputs to be public and signed (data availability of the input can be proven instead, but it’s costly, and also requires the use of SNARKs).  The second benefit is program size: with recursive SNARKs, the verifier trace is constant size, and does not depend on the length of the computation. The drawback of using SNARKs or SNARKs+STARKS is the complexity (amount of code involved) and attack surface. All the compilers, provers and verifiers may contain bugs. Therefore executing a SNARK is riskier.

Since BitVMX can also run a SNARK verifier, for complex programs the questions comes down to which SNARK verifier (BitVMX or BitVM2) is better in terms of round complexity and transaction cost. With the information available today on BitVM2, it’s seems that BitVM2 requires fewer onchain rounds, but parties must pay a higer transaction cost.

Using the limited data available regarding BitVM, we extrapolate it to show a comparison of each protocol executing a dispute over a SNARK verification, assuming it requires 1 billion steps. Round and transaction cost represent worse cases. Preprocessing time is based on a single thread process running on a standard laptop.

Protocol Preprocessing Time Storage Rounds Transaction virtual bytes
BitVM (gate-based) Weeks Terabytes ~ 50 ~ 6 Megabytes
BitVM CPU Days Gigabytes ~ 38 ~280 Kilobytes
BitVM2 Minutes Megabytes 1 ~ Tens of Megabytes
BitVMX (*) Milliseconds Kilobytes ~ 34 ~160 Kilobytes

(1) For the comparison we use a BitVMX protocol using 4-way search, and a hashing function split into 8 challengeable sub-functions.

Who we are

We are a group of researchers (some independent and some sponsored by companies) that are openly collaborating to achieve the first production-ready implementation of the BitVMX framework and the BitVMX RISC-V processor.
Our objective is to fully pass RISC-V official test suite, and be able to run any RISC-V program (even Linux!) on Bitcoin.
Anyone is invited to collaborate in both technical and project development areas.

The Team

Currently the team is composed of members of both Rootstock Labs and Fairgate Labs. The main sponsor is Rootstock Labs and the project is maintained by Fairgate Labs.



Currently different companies and individuals have committed resources to develop BitVMX over the course of 2024. The people participating are both researchers and coders. We can therefore present a roadmap to release a working system during 2024. However, the roadmap is tentative, as the BitVMX community may find improvements that lead to a better design.


πŸ”— BitVMX Repository
πŸ”— BitVMX Paper
πŸ”— Telegram Channel


BitVM was invented by Robin Linus and his work has inspired our research. RootstockLabs is the main sponsor of the BitVMX project. Fairgate Labs is committed long term to the BitVMX project. It will be providing a neutral repository open to collaboration, project management, testing environment, QA, a community roadmap, events and grants to build a community around BitVMX.

The BitVMX project is not and will not be affiliated with any token sale.

Join our community