BitVM Bridges Considered Unsafe

7 min readApr 5, 2024

Intro

BitVM bridges are inherently economically unstable. They rely on reimbursement from a bridge operator. If the bridge operator successfully reimburses all L2-to-L1 withdrawals during a pre-specified period, then the bridge operator is able to claim an equivalent amount of funds locked in the BitVM bridge contract. If they do not, then the verifiers can effectively burn the funds locked in the BitVM bridge contract.

The challenge for BitVM bridges is that they must rely on pre-signed transactions. Because we do not have covenants, the only option in a BitVM setup is to either: a.) pay out the locked UTXO to the prover, or b.) burn the UTXOs.

The bridge operator relies on being able to source liquidity to front any withdrawal payments. The liquidity requirement scales linearly with the TVL of the bridge. If a bridge operator fails to make all withdrawal payments, the bridge funds are burned. This means the larger a BitVM bridge gets, the more at-risk the users’ funds become.

This piece will walk through a toy example of a BitVM bridge’s ultimate fate.

Update: This article states that if withdrawals aren’t fully processed, the funds are burnt. This is incorrect. In reality, there is no clear specification of what happens if withdrawals aren’t processed. Some designs suggest electing another pre-defined operator who would attempt to process withdrawals, but that new operator would face the same liquidity challenge as the first operator. Others have suggested moving the funds to a multisig, turning the bridge to a centralized custodial bridge. The fundamental issue remains the same: the operator must source capital in order to process withdrawals, otherwise the security model breaks.

1. Initial Configuration

This diagram shows an initial configuration of a BitVM bridge to an L2. Alice and Bob both have 5 BTC on the L1, and Lisa has 0 BTC. The Bridge Operator has 3 BTC in liquidity. No coins have been deposited into the bridge or credited on the L2 yet. Verifiers are configured and monitoring the entire system.

2. Alice & Bob Deposit 10 BTC to the Bridge

In Step 2, Alice and Bob deposit their 5 BTC UTXOs into the BitVM Bridge Contract. The L2 is “listening” to the bridge contract. When it sees a deposit, it credits both Alice and Bob with 5 L2_BTC each.

3. Bob Sends Lisa L2_BTC

In Step 3, Bob sends Lisa 4 L2_BTC. Perhaps he lost a bet, or Lisa sold him some art.

4. Lisa & Bob Withdraw

In Step 4, Lisa and Bob have completed all of their L2 transacting and are ready to return to L1. They both create a withdrawal transaction for 4 L2_BTC and 1 L2_BTC respectively. When this happens, their L2_BTC is burned by the bridge contract, but the bridge operator only has 3 BTC available to pay out on the L1!

Withdrawals on BitVM Bridges
Let’s talk about how BitVM bridge withdrawals work. Every N months, the BitVM Bridge Contract has a cutoff where it checks the status of withdrawals. The Bridge Operator then has an additional M months to pay out any withdrawals initiated before the cutoff during the commit period. Importantly, this payout must come from liquid BTC that the bridge operator sourced. The bridge operator CANNOT gain access to any of the BTC locked in the Bridge Contract until ALL withdrawals have been paid out.

5. The Bank Run

In Step 5, Alice realizes that the withdrawals of Bob & Lisa (5 BTC total) surpass the total liquid funds of the bridge operator (3 BTC). She knows if the bridge operator fails to make the 5 BTC of payments to Lisa and Bob, the bridge funds can be burnt to fees by the verifiers. Thus, she does the economically rational thing and also withdraws her funds. She hopes she potentially gets paid back a share of the 3 BTC the bridge operator has rather than being stuck on an L2 with 0 BTC in its bridge. The cutoff period ends right after Alice submits her withdrawal request.

BitVM Contract Spend Paths
The core issue with BitVM is that the L2 users have no ability to claim the funds locked in the bridge. There are only two spend paths: 1.) to the bridge operator, or 2.) burned. This means that in the event of a bridge operator failing, the L2 participants only recourse is to hope the validators burn the bridge.

6. The Liquidity Crisis

In Step 6, the Bridge Operator faces a liquidity crisis. The cutoff just passed, and they are responsible for fronting 10 BTC of withdrawals from their L2. The bridge operator needs to source 7 BTC of liquidity with only 3 BTC on hand. The commit period ends without successful payments to L1 from the bridge operator.

Liquidity Requirements for the Bridge Operator
In order to be able to pay off any withdrawals in a period, the bridge operator would need to maintain a 1:1 ratio of liquid BTC to BTC locked in the BitVM bridge. This means that the more successful the bridge is, the higher the capital requirements are for the bridge operator!

7. Verifiers Challenge the Bridge Operator

In Step 7, the verifiers see that the withdrawals from the BitVM Bridge Contract were not paid out on the L1. Verifier 1 initiates the challenge-response game with the bridge operator. Since the bridge operator did not pay out all withdrawals initiated before the cutoff, they will lose this game.

Challenge-Response Game
The challenge-response game between a verifier and the bridge operator takes a pre-established time to settle (ranging from weeks to months). It involves trading pre-images that were agreed upon in the BitVM Bridge Contract setup along with L1 SPV proofs of payment.

8. Verifiers Burn Bridge Funds

In Step 8, Verifier 1 wins the challenge-response game. This allows the coins locked in the BitVM Bridge Contract to be burnt. The L2 withdrawers watch as the funds they locked in the bridge are now lost forever.

9. Bridge Collapse Complete

In our final state, the bridge has collapsed. The bridge operator pays out the 3 BTC it had in proportion to the amount withdrawn from the L2 and is left with 0 BTC. Alice, Bob, and Lisa all get pennies on the dollar.

Conclusion

BitVM bridges are not bridges, they are optimistic reimbursement mechanisms for bridge operators. Rather than having the bridge operator put capital at risk, THE BRIDGE USERS’ ACTUAL FUNDS ARE PUT AT RISK.

This toy example illustrates the unstable nature of BitVM bridges. The larger and more successful a bridge is, the harder it will be for the bridge operator to meet the liquidity requirements. At some point, there could be an outflow above the collateral held by a bridge operator. For example, in 2021 Arbitrum saw a $1B+ outflow in a single week (source: @Data_Always). The rational action for everyone in the L2 will be to withdraw to the L1 under the assumption that the bridge operator will not be able to source the necessary liquidity.

One final interesting point regarding MEV

Some bridge designs propose the punishment for a malicious bridge operator will be verifiers turning the UTXOs into “anyone can spend”. Should a bridge collapse, all the funds locked inside will be spent to fees. The larger the TVL, the more incentive the largest mining pools have to collude to collapse a bridge and collect the fees [1]. It’s easy to conceive of a Bitcoin L2 with $5B+ TVL. If this bridge were built on BitVM, it would be the largest opportunity for MEV we’ve ever seen on Bitcoin.

Notes

[1] The BitVM bridge failure mode is very different from a drivechain bridge attack. There is no requirement for a majority of hashrate to collude to collapse a BitVM bridge, it’s just helpful for them to collaborate since it is otherwise uncertain which one of them receives the reward.