Are BitVM Bridges Economically Secure?
Exploring the capital efficiency and feasibility of BitVM bridges
Today, I read that "BitVM bridges are inherently economically unstable." The claim is that BitVM Operators must post collateral equal to or greater than the bridge deposits from all users, or they risk a bank run that burns all bridged funds.
Are BitVM bridge users insured up to their own deposits or the Operator’s collateral?
Let's explore this claim. It comes from a blog post by two Bitcoin builders known for awesome educational resources, innovative uses of inscriptions, and experimentation with Bitcoin programmability in general.
Wait a second —
computer, zoom in
computer, ENHANCE
🚨 op_cat enjoyooors detected 🚨
Motives uncovered in the 2nd paragraph. The Wizards are at it again, fighting for the re-introduction of concatenation into Bitcoin Script to enable more “spam” (pronounced: /fʌn/ˌ /fun/).
The Critiques from the Wizards
In all seriousness, the Taproot Wizards team has made a great effort to innovate Bitcoin, spread knowledge about opcodes/technologies, and coordinate a network upgrade for op_cat (and, by extension, covenants for real L2s). Let’s examine their claims.
The presented issue involves a scenario where user withdrawals from a BitVM bridge exceed the collateral of the Operator.
Users might want to leave an L2 rather than keep their liquidity there indefinitely? And they’re saying BitVM bridges only work when BTC is going in but not when it’s coming out — i.e., they only work when they’re growing?
It's a Ponzi, just like the rest of this industry? (one of us!) Not really.
The argument highlights how, in their explored model, the necessary liquidity to process withdrawals is custodied by the BitVM Bridge Contract rather than the BitVM Bridge Operator, but the Operator is the one who needs that liquidity in order to avoid getting rekt by Verifiers.
i.e., bridge Operators must be fully collateralized to the value of the bridge Contract deposits or, more realistically, overcollateralized.
The penalty of being undercollateralized when a bank run hits (remember, we’re talking about the Operator here. The Contract, of course, is fully collateralized by the actual user deposits) would be the burning of funds. Verifiers would challenge this failure of withdrawal and win, causing the funds in the bridge Contract to be burnt.
This claim is disputed and explored further in the Community Discussion section below.
The conclusion is that user deposits in a BitVM bridge are insured up to the value of the Operator’s collateral, not their own deposits.
This claim means BitVM bridges are not economically safe unless fully matched (collateralized) by Operators. This would be hard to achieve for any bridge with meaningful adoption, and cut the utilization rate of BTC in half.
While the bridge Contract itself is not overcollateralized, the entire system must be 100% (or more) overcollateralized, i.e., to get 10 BTC on an L2 you need 20 BTC locked up on L1, split between the bridge Contract itself and the bridge Operator.
The Operator technically only needs to match bridge Contract collateral at the time of withdrawals (and there is an arbitrary time window for this), but you’re playing with fire if you have a successful bridge and must source billions in a short amount of time. In your bridge design, you must now temper liquidity risk with making users wait a longer time for withdrawals.
BitVM be like:
the risks of fractional reserve banking 🤝 the capital inefficiency of 100%+ overcollateralized deposits
or is it?
Community Discussion
I’ve included some insight from the BitVM Builders chat
Which funds are actually burnt?
Burnt == made inaccessible
First, a clarification on which funds are burnt when the Verifier catches an Operator lackin (being undercollateralized during a bank run).
The bridge Contract funds do not get burnt, as suggested in the original blog. Instead, the connector UTXOs are burnt. The connector UTXOs are essentially the Operator’s keys to access bridge funds. So, that specific Operator loses access to the bridge Contract funds (and gets financially punished) rather than the bridge Contract funds being burnt.
If the Operator can’t access the funds, who can? Aren’t they burnt anyway at this point if nobody can access them? The Operator can be replaced/replicated by another (according to Citrea’s Clementine model), or custom logic can be implemented to direct funds elsewhere.
We still run into the same problem if another Operator is put in place, as they also won’t be able to facilitate withdrawals of all bridge deposits unless they’re fully collateralized to the value of the bridge deposits.
We’re in purgatory, stuck between three choices
Non-overcollateralized Operators: we ritualistically sacrifice Operators at times of high outflows until a liquidity savior steps up
Overcollateralized Operators: returning to capital inefficiency
Centralization: a federated backup plan can be put in place to receive and distribute the funds if a non-overcollateralized Operator gets caught lackin
How Do Depositors Get Re-paid?
The Operator fronts the money for withdrawals and is later paid back by the bridge Contract. This is why there’s a potential throughput issue.
If the exits exceed the Operator’s funds, the Operator doesn’t have the luxury of incrementally proving that they executed a proper withdrawal for only some of the depositors, which would allow them access to bridge Contract funds to pay themself back and then execute more withdrawals, because the Verifiers will first punish them for not processing all withdrawals in that batch.
Couldn’t this be solved by limiting bridge throughput relative to Operator collateral?
If the Operator only posts collateral equivalent to 1/10th of the bridge Contract, the guarantee for withdrawal is 10x the challenge period if you’re last in the queue. Now adjust the Verifier’s parameters only to punish the Operator if they’re slacking (i.e., not distributing maximum withdrawals according to their set collateral) while there’s a queue in place.
That’s not so great for UX, but an Operator with a better guarantee (e.g., 2x time guarantee instead of 10x by having collateral equivalent to 50% of the bridge Contract funds instead of 10%) could charge a higher fee for their liquidity service. The economics should work themself out here.
Conclusion
BitVM is a fairly new protocol, so it’s good to try to poke holes in it now before real funds are locked in BitVM-based bridges. I recommend joining the BitVM Builder Telegram chat to participate in this discussion, as I myself am not an expert.
Remember, we're talking about tools and abstract protocols here, not specific implementations. CAT, CTV, or any other opcode that enables covenants would be complementary to BitVM rather than rivalrous and would make everything about L2 bridging easier. That said, a soft fork to add a covenant-enabling opcode is no easy feat, so BitVM is our best right now for less-custodial bridging.
These are exciting times for sovereign BTC bridges to programmable environments! Unilateral exits are a requirement for a protocol to fit the definition of an L2, meaning all Bitcoin layers (other than Lightning Network and other state channels) are just that: ambiguous layers.
Follow us on Twitter (X) @BitcoinLayers to follow risk assessments on Bitcoin layers, infrastructure, and bridges as they launch and iterate.
