The Platform

Pushing the boundaries of secure computation on Bitcoin, enhancing its interoperability and scalability

BitVMX lets you create 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, which can either accept or reject the spending. The program must be defined when the UTXO is created, but the program input is provided dynamically to satisfy the program at the time of UTXO spending.

The BitVMX covenant is enforced by a set of N parties, and only one to be honest is needed to enforce it. By honesty we mean that the party is live when the protocol requires it, and follows the protocol rules, even if sometimes deviations could be more profitable in the short term. While the formal and colloquial definitions of honesty match, there is a huge practical gap between a party staying honest when there are no incentives for corruption, and staying honest when stealing could be carried out surreptitiously with low-risk or anonymously. BitVMX, as most 1-of-N honesty protocols, only requires a very weak form of honesty, because incentives for individual corruption can be made very low. A BitVMX-based system can be protected by a large committee where anyone can detect and penalize misbehaviour based on cryptographic accountability. This discourages corruption. On the other hand, a majority-voting federation with small committee size incentivizes collusion. Both systems require some number of honest participants, but the honesty quantity also affects their quality: the chance of supposedly honest participants switching sides.

In addition to 1-of-N honesty security, BitVMX also enables large committees and permissionless joining those committees, which makes the system fair for anyone.

In its simplest form, BitVMX provides a two-party protocol where the first participant is the operator and the second is the verifier that protects a BitVMX-encumbered UTXO. First, both of them initially collaborate to create a set of presigned transactions, generate and exchange public keys and other cryptographic tables. The transactions guide the dispute resolution protocol. Participants also compute an initial deposit address and funds sent to this address that will be governed by the predefined program.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. The kick-off transaction signals the intention for the operator to withdraw the funds and often provides the input to the program or a commitment to it. If the input does not make the program accept the spanding, the verifier becomes a challenger, and its goal is to prove that the operator has cheated. The operator becomes the responder (also known as prover), the goal is to respond to each challenger question, and prove she has not cheated. In a more advanced setting, BitVMX allows N-parties to participate, where some of them are operators (who can prove and challenge), and some are only watchtowers, who can only challenge other operators. BitVMX provides several protocols to handle this challenge-response, depending on the needs of the protocol designers. Currently BitVMX has support for the BitVMX-CPU, Its first verification protocol integrated. Support for BitVMX-GC, based on garbled circuits, is coming in 2026.

Verification using BitVMX-GC

The BitVMX-GC verification plug-in uses Garbled Circuits (GCs) and Designated-Verifier SNARKs (DV-SNARKs) efficiently composed verify SNARK proofs on Bitcoin—where those SNARKs, in turn, verify arbitrary programs proven by a STARK.

At a high level, the construction follows a four-layer verification stack. Arbitrary programs are first proven using a STARK, leveraging its transparency and scalability. That STARK proof is then verified by a succinct SNARK, drastically reducing verification complexity. The SNARK is verified by a garbled-circuit, which conditionally discloses a secret hash pre-image in case the STARK is invalid. Last, the revealed pre-image is published onchain to penalize the malicious operator and prevent the malicious spending. In contrast with other BitVM solutions, the SNARK verification is realized through garbled circuits rather than monolithic script evaluation. This approach allows Bitcoin to indirectly enforce the correctness of general computation, without modifying consensus rules or introducing trusted parties.

BitVMX-GC is the garbled-circuit plug-in for the BitVMX platform. BitVMX-GC provides a practical verification backend in which the SNARK verifier is compiled into a garbled circuit whose execution is enforced through BitVMX’s generic challenge-response framework. Importantly, the resulting garbling tables remain compact—on the order of hundreds of megabytes, not gigabytes—placing them well within realistic bandwidth and storage budgets for adversarial dispute resolution.

Unlike earlier BitVM-style constructions that rely on cut-and-choose techniques to achieve malicious security, BitVMX-GC attains full malicious security via direct zero-knowledge proving of correct garbling. This design choice substantially reduces both bandwidth requirements and computational overhead, while simplifying protocol logic. In particular, the elimination of cut-and-choose removes the need for multiple parallel garblings and expensive consistency checks, leading to a more streamlined and performant verification pipeline.

BitVMX-GC achieves significantly lower bandwidth consumption and prover/verifier cost compared to prior garbled-circuit-based BitVM designs such as BitVMV3.

The Verification using the BitVMX-CPU

The BitVMX-CPU uses a virtual RISC-V CPU to run the program that controls the spending of a UTXO. This verification method can be used in the layered manner, similar to BitVMX-GC, where programs are first proven by a STARK, then verified by a SNARK on the BitVMX-CPU, or in a direct mode. In the direct mode, the original program is directly verified by the BitVMX-CPU onchain, which avoids relying on the correctness of a huge amount of third party code for proving and verification codes, the ZK-proving costs, additional security assumptions and the SNARK trusted-setup.

The BitVMX-CPU protocol works as follows. When the operator wants to withdraw the locked funds, she posts onchain the kick-off transaction together with the input that makes the program halt with an exit code that represents success. The verifier obtains the input from the on-chain transaction, then executes the program locally on the virtual CPU 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 and the operator becomes the responder. 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 signed by the operator such that the first step has a correct step hash, and the second step has an incorrect step hash. The malfunction is defined from the point of view of the challenger. From the point of view of the operator, 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-CPU 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 on-chain and comparing the on-chain 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. The BitVMX platform allows moving from two-party to N-party (N>2). However, the protocol designers must make multiple design decisions based on bandwidth-compute-cost trade-offs. Some of these include selecting:

• Number of provers/verifiers
• Cooperation or independence between verifiers
• Simultaneous versus serialized disputes to prevent challengers overloading operators with disputes.
• Withdrawal rate limits to prevent operators from overloading the verifiers with disputes.
• Sharing security bonds between multiple BitVMX-encumbered UTXOs or using per-UTXO bonds.

The BitVMX platform provides several pre-built templates of N-Party protocols that provide proven solutions to address these design issues.