The BitVM Liquidity Crunch Issue

BitVM has recently come under some scrutiny after the Taproot Wizards, Tyler and Rijndael, posted their criticism of the liquidity requirements imposed on the operator of a BitVM based two-way peg. In all the recent discussions around BitVM based layer two solutions, I had taken for granted that people discussing them and interested in the design space understood the collateralization/liquidity requirements imposed by the architecture on the operator(s). The recent discussion around the “liquidity crunch” issue shows me I was incorrect about this assumption, and that many people outside of those actively involved in BitVM development were not aware of this issue.

Before I go into the liquidity crunch issue, I think it’s important to clarify one of the unique properties of a BitVM peg (called bridges by altcoin developers). In bridges built on other networks, the funds held in the actual bridge contract controlling the movement of funds between networks are what is used to actually process withdrawals. In the case of a BitVM peg, these funds are not accessible in order to fulfill withdrawals. The operator of the system (rollup, sidechain, etc.) must actually front their own liquidity in order to process user withdrawal requests.

As user withdrawal requests come in, the operator actually moving the rollup state forward looks at every request, and processes those withdrawals using their own personal funds. After a period, the system then check-points its state in a cutoff committing to all pending withdrawals. After the operator has fulfilled all pending withdrawals from the last state they can then engage in a claim process from the BitVM secured funds to make themselves whole for all the capital they have fronted. The BitVM contract is established so that operators can have their ability to claim these funds revoked if they have not honored all pending withdrawals from the last state.

So the general user flow is a deposit goes into a contract secured by BitVM, the operator fronts their own capital to process withdrawals, and then periodically the operator compensates themselves for the money they’ve spent out of pocket from the BitVM contract. This sets a BitVM peg apart from any other type of two way peg, introducing a liquidity requirement similar to the Lightning Network.

The Liquidity Crunch

The problem that Taproot Wizards identified in their write up is a result of the combination of the up-front liquidity requirements imposed on the operator and the fraud proof scheme that allows the verifiers of the BitVM to revoke the operator’s access to funds if they have not fulfilled all withdrawals in a given rollup epoch. This creates a big potential problem for the system, and particularly for the operator.

For now let’s completely ignore the potential scenario of an operator intentionally refusing to process a withdrawal due to malicious censorship. That is not a concern for now in looking at the potential problems, as if an operator did such a thing, they should have their access revoked and incur the loss of whatever funds they have already spent on processing withdrawals.

It is absolutely possible for an honest operator to run into a situation where, through no malicious intent on their part, they do not have access to enough liquidity to process the withdrawals pending in a single rollup epoch. If this were to occur, then an otherwise honest operator can now not compensate themselves from the BitVM contract for what they have processed without opening themselves up to a single verifier challenging them and resulting in them permanently losing access to the funds. Everything that they have spent processing withdrawals in that epoch would be lost funds they could not recover.

This creates a big risk for a peg operator. Through no malicious action at all, simply through limitations of their own funds, interest rates increasing in borrowing funds, just factors of time required to access funds, they can lose a massive amount of money. This introduces a big potential instability in the peg, and it also begs the question where does the users’ money go in the event of an operator being hit with a fraud proof?

The Options

The important thing to note is that where the ultimate dead end destination of funds is depends on particular design choices made by the implementers of any given peg. There is a good degree of freedom available in design choices, the end destination of funds after a challenge ejects an operator has multiple options, the period after an epoch end that an operator has to fulfill all withdraws is configurable, none of these things are set in stone as a single possible way to configure them.

So now that we understand the problem let’s look at some potential solutions.

Throttling

You could address the issue by throttling withdrawals. This would entail creating a maximum limit of funds that an operator could be bound by the contract to fulfill in any given rollup epoch. This would allow the operator to ensure that they had enough capital in order to process the maximum amount they have to. Each period the operator could process that many withdrawals, go through the claim process to compensate themselves from the BitVM contract, and then in the next epoch recycle that amount to fulfill the next wave of withdrawals.

The problem with this is you don’t know when a large uptick in funds pegged into the system will occur, and you also don’t know when market activity will align to incentivize a massive amount of money to want to peg out of the system. As more funds are pegged in, the possibility of a large increase in the volume wanted to peg out at once increases. This dynamic essentially leads to an ever growing queue to get out of the system unless you increase the maximum epoch withdrawal amount, which also increases the liquidity requirements for the operator.

This exacerbates the liquidity requirement these pegs have, and essentially creates a huge friction to withdrawals. Swap outs do not solve the issue, as this ultimately traps the counterparties liquidity in this ever growing queue, unlike other two way pegs where they could exit practically immediately after facilitating the swap.

Multiple Operators

Both BitVM 1 and BitVM 2 support having multiple verifiers in different ways, allowing more than one more to participate and be capable of revoking an operator’s access to funds. It is also possible in BitVM 2 (and some BitVM based pegs such as the Citrea rollup) to have multiple operators working in parallel. More than one entity can help process withdrawals from the peg, so multiple pools of liquidity are available to facilitate the peg.

This would in principle make the entire liquidity dynamic much more scalable, as it would no longer be limited to a single entity having to front the liquidity to facilitate timely withdrawals from the system, but it introduces questions of complexity. Each UTXO deposited into the BitVM peg and bound by the contract needs to have the terms of claiming defined. That contract needs to now be able to distinguish between multiple operators, and ensure a means of distinguishing which withdrawals are associated to which operator, and ensure they can only claim what they have facilitated rather than funds meant for a different operator.

It also needs to take into account how to handle the global withdrawal demand that all operators exist to facilitate. What if every operator has used all the capital they have, but there is still unmet demand? Do they all have access to BitVM funds revoked? None of them? Is there some rollover grace period similar to having a queue throttle? If there is, who is responsible if those withdrawals still aren’t facilitated the next epoch? These are all things that need to be concretely worked out.

Multiple Linear Operators

In addition to having multiple parallel operators, you could have a chain of linear operators. A single operator could function at a time, facilitating withdrawals, and if they were to ever run into a liquidity problem and had their access revoked from the BitVM funds the funds after a challenge/revocation process could be immediately sent to a new BitVM with a new operator. This would not address at all the risk of a single operator suffering a liquidity crunch, and they would realize the loss of whatever withdrawals they already deposited, but it would ensure someone else could step in and have a chance to continue facilitating withdrawals with the ability to claim compensation from the BitVM.

This however adds a good deal of cost to the peg-in process. Generating a BitVM instance is not cheap in terms of data and interactivity, meaning that to chain linear BitVM operators together like this, you must generate for peg-ins that number of BitVMs.

The Backstop

In all of the cases of any peg using BitVM, there is one ultimate question: where do the funds eventually go in the worst case failure? There are ultimately two options. Either you actually burn the funds, or you put them under the control of a verifier. The first means that users’ funds are now destroyed, and everyone holding funds in the peg is now rugged. The second means that the trust model has shifted outright to trusting an individual verifier or group of verifiers in a federation who unilaterally control the funds.

Burning the funds is a non-starter in a model without a withdrawal throttle, as that would validate the worst-case scenario concerns voiced by Taproot Wizards. A consistent failure case of operators, regardless of parallel or linear, would result in users’ funds actually being destroyed. The only model this would be remotely safe in, would be with a withdrawal throttle; but even then if the operator(s) defined by the contract were to disappear or have their access revoked, the risk of permanent fund loss would still exist.

So that leaves putting the funds back under the control of a single verifier or a group of them. In the event of a total failure of all operators, this would allow the verifier(s) involved in the system to recover users’ funds and make them whole. I don’t think this is that bad.

Every BitVM instance is set up with an n-of-n multisig that handles signing all the pre-signed transactions involved in the BitVM contract. The ultimate root security model of the entire scheme is that a single one of those key holders must remain honest, and refuse to sign a dishonest dispersion of funds, in order for the system to be secure.

That same security model can be applied to where funds go (minus the operator(s)) in the event of a total operator failure. That introduces the risk of a single key being lost or not cooperating burning funds though, so you could also just make it a conventional m-of-n multisig.

I see no problem in this type of set up at all, it accomplishes the goal of ensuring users’ funds are not irrevocably burned without creating a wild alteration to the trust model. Ultimately if you are not a direct participant of the BitVM contract, i.e. holding one of those n-of-n keys yourself, you are still trusting a federation of some sort. Only needing to trust a single member to be honest to keep things safe is obviously superior to having to trust 3 people in a 5-of-7 multisig, but it is still a form of delegated trust.

Wrapping Up

At the end of the day, I think the liquidity crunch issue identified by Taproot Wizards is a very legitimate issue. Depending on the specific architecture of the peg in question, it could introduce problems from completely burning users’ funds, to losing operators’ funds even without malicious action, to simply creating an ever growing queue to exit without either halting deposits or falling back on the n-of-n group to bypass the queue.

It is not however, in my opinion, something that means the idea of using BitVM to secure a two way peg is a fundamentally broken idea. I think I’ve laid out a good number of ways that specific implementations could backstop or mitigate the issue, and ultimately the reality of the n-of-n group existing and the potential to push funds in a failure case to a delegated group to handle withdrawals could address the risk of permanent loss of funds.

As a last note, the pace of development in this space has hit a pace in the last year or so that I have never seen in my time here, I think it is important when discussing these developments to step back and keep a calm head while looking at the discussions that occur over trade-offs and risks. Yes, public perception is an aspect of these conversations happening in public, but these discussions should be rooted in the goal of arriving at an accurate understanding of the issues at hand. That should not take a backseat to trying to illicit or defend any particular public perception first.