Author: Janusz
Source: https://insider.btcpp.dev/p/bitvm-based-bridges-and-emergency
The original article was published in August 2025.
As BitVM-based bridged contracts near production deployment, I began to consider the topic of what's known as the "emergency update" path. With the help of Citrea's team, I was able to understand the different ways to verify the cost paths of a BitVM bridged contract, thus determining whether it includes an emergency update mechanism. This article attempts to discuss how future projects might implement these cost paths. Note that emergency update paths, and multi-signature mechanisms for cost contracts, are not "BitVM-specific features"; they are mechanisms widely used in bridged contracts protected by proof systems, and I believe they will also be utilized in the construction of BitVM-based bridged contracts. This article is explanatory and hopefully will spark a discussion about how we should disclose the types of these cost paths.
Have you ever faced a situation where you needed to withdraw money from the bank immediately? For example, your car broke down and you needed to pay the mechanic right away. Or, your friend drank too much at a bar and you needed to pay a sum of money to bail him out.
The BitVM bridging contract likely wants the same guarantees. We want the operators of the bridging contract to be bound to the specific rules initially set up by BitVM. But what if something goes wrong? What if there's a vulnerability in the system that allows an attacker to take all the money out of thin air, or causes the funds to be permanently frozen?
Even if a friendly person discovers a bug, they might want a way to preemptively transfer all the money out of the bridging contract to prevent it from being breached.
This guarantee is achieved through an emergency multi-signature device —an additional spending path that can be implemented in the BitVM bridging contract, allowing a group (or a single) signer to completely bypass the challenge game and optimistic reimbursement mechanism and transfer funds out of a bridging contract.
BitVM is a new technology, and its corresponding bridging mechanisms are also new. Some teams are reluctant to release these new bridging contract constructs without any insurance mechanisms. Early adopters of bridging contracts and liquidity providers may also want an emergency switch to ensure their funds can be withdrawn if a bug is discovered. Immutability is not always perfectly aligned with commercial incentives.
Some existing BitVM bridge contract implementations may already include multi-signature devices for emergency updates. More bridge contract constructs are coming soon, and they may launch with a security council—a group of licensed signers who operate the emergency multi-signature device. If the security model of these systems eventually reverts to a licensed M-of-N multi-signature device (even if it's a one-time use device), users have the right to know.
I spent two weeks researching how to establish such a security council and kept thinking about how to verify their existence (with the help of some members of the BitVM camp, of course).
These exercises raise an interesting "problem." We cannot verify these spending paths (within the blockchain) until they are actually used. That is, if insiders do not disclose them at all, some users may never even know that a permissioned M-of-N multisignature device is based on the ultimate trust assumption of a BitVM-based bridging contract.
BitVM Bridge Contract Review
" BitVM ," proposed by Robin Linux, is a method that allows arbitrary computation to be performed within the Bitcoin blockchain. It has sparked a new wave of Bitcoin development, with many teams using this technology to develop layer 2 bridging contracts. These contracts support layer 2 structures where multiple operators can hold Bitcoin as collateral, acting as backers for the Bitcoin assets encapsulated on that layer 2. More importantly, it also enables an additional optimistic detection mechanism that can be used to challenge any malicious (or improper) withdrawal attempts from the operators.
During the initiation phase, a group of signers forms an N-of-N multi-signature device to pre-sign the transaction graph for a bridging contract. If any one of them destroys their private key used in this pre-signing ceremony, then the UTXOs locked in the bridging contract can only be spent by a predefined spending script.
In some cases, the operator must advance funds (as liquidity) and then request reimbursement from the bridging contract. The operator is only able to reimburse themselves after a period of time. Another design allows users to work with honest operators who release the private keys needed to transfer funds out of the bridging contract.
Regardless of the design, at least one honest operator is required to process withdrawals. If an operator is dishonest—for example, if they witness a withdrawal that conflicts with the initial state of the system—an observer (watchtower service) can challenge them.
The watchtower mentioned here is an entity (or a person) that runs the BitVM validator software and can challenge and then halt withdrawal requests from BitVM bridge contract operators.
Regarding improper withdrawals, for example, an operator might attempt to withdraw more funds than they should have from their BitVM instance. This is why expenditures from the bridging contract include a time lock . It gives the watchtower time to submit a challenge. This time window from when the withdrawal contract is broadcast to when the time lock unlocks is called the " challenge window ."
Only after the challenge window closes and the scouts are alerted can the operator (or user) withdraw funds from the bridge contract. In a BitVM-based bridge contract, theft requires collusion between all operators and watchtowers (which could completely plunder the bridge contract). Funds will not be stolen as long as one of them is honest, regularly checks the blockchain, their validator is online, and is willing to submit challenges. This 1-of-N trust assumption is good because it means we need to trust fewer people than in a standard consortium, where a majority of dishonest individuals are sufficient to steal funds.
The aforementioned mechanism creates a bridging mechanism with even less trust than those already in use on the Bitcoin network. However, in reality, this core trust assumption may ultimately revert to a permissioned multi-signature mechanism (albeit temporarily). (Translator's note: The situation after this reversion is the same as with currently implemented mechanisms (multi-signature consortia for sidechains).)
Introduction of emergency multi-signature
As noted in the introduction, development teams can (and will) add an emergency spending path to their BitVM instances. Whether they should or shouldn't is irrelevant. What's more important is that almost all BitVM-based bridging contracts going into production include an emergency spending mechanism before they're fully mature. What we should expect is that these development teams will properly disclose the nature of these emergency spending paths.
Emergency multi-signature mechanisms are not a feature of BitVM. They are a mechanism widely used in bridge contracts protected by proof systems to update the system when bugs are discovered. Rollup instances in other ecosystems have already set precedents in this regard.
The BitVM bridge contract uses the Segregated Witness v1 (Taproot) script to create the spending path for the pre-signed bridge contract. The Taproot script uses MAST, which allows multiple spending conditions to exist in a single UTXO. When a leaf script is used to spend this UTXO, only that leaf script is exposed (other concurrently existing leaf scripts do not need to be exposed).
The BitVM2 paper correctly points out that pre-signed transactions can restrict operators to using only methods that can be challenged when withdrawing funds. However, nothing prevents the developers of a specific BitVM instance from including additional spending paths in the Taproot script tree that allow withdrawals from the bridge contract.
In the Taproot script tree, each spending path is called a "leaf" script. To unlock and spend a UTXO that is locked by this script tree, you only need to reveal one of the valid leaves (and provide witness data that satisfies that leaf script).
Let's look at an example: The first path (or the first leaflet) is the standard withdrawal path, with a challenge window. The other path is the emergency spending path, which bypasses the challenge window.
Leaf A: Spending conditions protected by 1-of-N fraud proof
OP_PUSHBYTES_2 <SomeDelay>OP_CSVOP_DROPOP_PUSHBYTES_32 <OperatorPubKey>OP_CHECKSIGLeaf B: 2-of-3 Emergency De-anchoring Cost Conditions
OP_PUSHBYTES_32 <pubkey1>OP_CHECKSIGOP_PUSHBYTES_32 <pubkey2>OP_CHECKSIGADDOP_PUSHBYTES_32 <pubkey3>OP_CHECKSIGADDOP_PUSHNUM_2OP_NUMEQUAL "Leaf A" is a standard withdrawal reimbursement condition in a BitVM instance. After a challenge period ( <SomeDelay> ), a pre-designated operator can withdraw funds from the bridge contract. If an operator spends UTXOs locked in the bridge contract dishonestly, a watchtower can challenge them during the challenge period (that is, the time between spending the BitVM contract and the expiration of <SomeDelay> time lock) to prevent dishonest withdrawal requests.
Leaf A can be the cost of a pre-signed transaction constructed by an N-of-N pre-signed committee.
On the other hand, "Leaf B" is an immediately effective spending path; a 2-of-3 multi-signature device can instantly transfer all funds in the BitVM contract. This can be done if the development team discovers an exploitable bug in the contract, or if they decide to abscond with the funds.
When I say "contract," I always mean the BitVM contract that controls the spending conditions of a Bitcoin UTXO.
These two cost conditions can coexist on the taproot script tree of a bridging contract. While adding a cost condition that can bypass the BitVM Challenge-Response game is not always reasonable, there is objectively nothing preventing developers from implementing such a cost condition.
Furthermore, the spending conditions on the script tree can be highly flexible. In the examples above, we only demonstrated two spending conditions. However, development teams can create script trees containing a wide variety of spending conditions. Leaf B above is an example: this emergency update mechanism has no delay and can be spent by a 2-of-3 signer set, leading to the theft of user funds. More extensive protocol upgrades can be initiated by a 9-of-12 security council and include time locks.
The specific design may vary across implementations; the important thing is that we must be able to verify these spending conditions. One "problem" with modern Bitcoin scripts is that you cannot publicly verify a script until it is spent. This is strictly related to BitVM-based bridging contracts, meaning we cannot verify all spending paths until a specific leaf script is used to spend a UTXO. Remember, when a leaf is spent, only the spending conditions represented by that leaf are revealed. Therefore, if only a regular withdrawal is performed in our instance, we cannot verify the existence of an urgent spending path; and vice versa.
This could present a problem. If the development team inserts an emergency spending mechanism into the script tree but never exposes it, users may never be able to be certain that there isn't a licensed multi-signature device (or a licensed individual) that can spend all the funds locked in the bridging contract.
After thinking about it for a week, I came up with some ways for the development team to reveal the cost path of the bridge contract.
Disclosure Methods
Disclose the expenditure path directly in the instruction manual
For the development team, the simplest approach is to disclose the privileged roles in the documentation. The development team can directly disclose who operates the bridging contract, who participated in the pre-signing ceremony, who runs the lightweight client, and who the watchtower is.
Some disclosure is better than nothing, but we still can't verify the cost path of the bridging contract simply based on the specifications on the website. It would be even better if we could directly verify the script.
Test before depositing funds.
The development team can send test transactions for different spending paths. They can spend some funds from a given instance to eventually reveal all the spending paths, and users can also verify the spending paths themselves.
This requires the development team to spend every leaf in the script tree. Even so, we can never be certain they won't insert additional spending conditions that have never been revealed. The development team can always selectively choose not to spend a particular leaf or reveal spending conditions. This is often considered a feature of Taproot MAST, but in the context of bridging contracts, it reduces user confidence that the development team has actually revealed all spending scripts.
Unfortunately, the test transaction did not provide the transparency we expected.
Using large-scale restrictive clauses to simulate committees
Another approach is for the development team to use a sufficiently large constraint to simulate a committee and give independent participants the opportunity to participate in all transactions within the pre-signed bridging contract transaction graph. This would give independent participants the opportunity to verify the existence of emergency multi-signatures and how many signers are involved.
However, this still requires users to trust the participants of the restrictive terms committee, rather than having them directly verify the script. I would say the way forward is that we can give any user the opportunity to verify the cost path of the bridging contract.
Create a standardized disclosure method
In my personal opinion, we should expect the development team to release the complete script tree they created for their BitVM instances.
If the development team provides the internal key for creating tapscripts, the complete set of leaf scripts, and the corresponding bridge contract address, we can do it ourselves.
Using this information—the internal public key used to generate the cost path, and the Merkle root derived from the taproot script tree—we can add them together to obtain an adjusted public key. If this adjusted public key matches the address in the BitVM bridge contract, we have verified that the address actually contains only these cost scripts.
Look! We have a verifiable disclosure method. If a development team exposes an incorrect taproot script tree, the adjusted public key will not match the address in the bridge contract.
This disclosure method allows us to truly verify the key trust assumptions associated with a BitVM bridge contract instance. However, it requires the development team to expose the entire script tree and the associated internal public key.
The importance of transparency
Even without disclosing the signer's identity, we still need the script to understand the true trust assumption. These systems are designed with a 1-of-N honest participant trust assumption. But if the trust assumption ultimately reverts to a permissioned multi-signature mechanism, users who deposit funds into these contracts have a right to know.
I anticipate that the vast majority of BitVM-based bridging contracts will contain such emergency update cost paths. I hope these bridging contracts won't always have these cost paths, and we can upgrade to a more trust-minimized design. However, we cannot ignore them or use the excuse that they are not the only trust pattern.
As long as the emergency spending path exists, it is undoubtedly a trust model itself.
(over)
