BitVM liquidity crisis issue

BitVM has recently come under some scrutiny after Taproot Wizards Tyler and Rijndael posted criticism of the liquidity requirements imposed on BitVM-based two-way peg operators. In all the recent discussions about BitVM-based layer 2 solutions, I’ve taken for granted that people discussing them and interested in the design space understand the collateral/liquidity requirements that the architecture imposes on operators. Recent discussion of the “liquidity crisis” issue shows that I was wrong about this assumption and that many people outside of those actively involved in BitVM development were unaware of this issue.

Before addressing the issue of liquidity crisis, I think it is important to clarify one of the unique properties of BitVM pegs (referred to as bridges by altcoin developers). In bridges built on other networks, the funds held in the actual bridge contract that controls the movement of funds between networks are actually used to process withdrawals. In the case of BitVM pegs, these funds are not accessible to perform withdrawals. The operator of the system (rollup, sidechain, etc.) must actually secure its own liquidity to process user withdrawal requests.

When a user withdrawal request comes in, the operator who actually moves the rollup state forward looks at all the requests and processes those withdrawals using his or her own personal funds. After a certain period of time, the system checks a cutoff status that commits all pending withdrawals. After operator In the last state, you have fulfilled all pending withdrawals. They can then participate in the claim process for their BitVM security funds, making themselves whole for any capital they face. The BitVM contract is set up to allow operators to claim canceled funds if they default on all pending withdrawals from the last state.

So the typical user flow is that deposits go into a contract secured by BitVM, the operator frontends his own capital to process withdrawals, and then periodically reimburses himself for the money the operator spent out of pocket on the BitVM contract. This differentiates BitVM pegs from other types of two-way pegs, introducing liquidity requirements similar to the Lightning Network.

liquidity crisis

The issues identified by Taproot Wizards in their article are the result of a combination of upfront liquidity requirements imposed on operators and an anti-fraud scheme that allows BitVM validators to revoke operators’ access to funds if they do not. You have completed all withdrawals in a particular rollup era. This poses a huge potential problem for the system, especially for the operators.

For now, let’s completely ignore the potential scenario where an operator intentionally refuses to process a withdrawal due to malicious censorship. If the operator looks at the potential problem as if they had done so, there is no need to worry at this time. must Your access will be revoked and any funds you have already spent processing withdrawals will be lost.

It is absolutely possible for an honest operator, without malicious intent, to encounter a situation where he or she does not have access to sufficient liquidity to cover pending withdrawals in the single rollup era. When this happens, honest operators are now unable to compensate themselves for what they paid in the BitVM contract. have Appeals to a single validator are processed without permanently losing access to your funds. Any money you spend processing withdrawals in those days will be lost funds that you may not be able to recover.

This poses a huge risk to peg operators. Even without any malicious activity, you can lose a significant amount of money simply due to limited funds, rising interest rates when borrowing funds, and the time it takes to access funds. This brings great potential instability to the peg and raises questions about where users’ money goes if the operator is proven to be fraudulent.

option

The important thing to note is that where the funds end up will depend on the specific design chosen by the particular peg executor. There is considerable freedom in design choices, the final destination of funds after a challenge discharge gives the operator several options, the period during which the operator must fulfill all withdrawals after the end of the epoch is configurable, none of these are set. The only possible way to construct it is in stone.

Now that we understand the problem, let’s look at some potential solutions.

control

You can solve the problem by limiting withdrawals. This entails creating a maximum funding limit that the operator can be contractually bound to fulfill in a given rollup era. This allows operators to ensure that they have sufficient capital to cover the maximum amount required. Each period, the operator can process a large number of withdrawals, go through a claims process, compensate themselves in the BitVM contract, and then recycle those funds in the next epoch to fulfill the next wave of withdrawals.

The problem with this is that you never know when the amount of money locked in the system will increase significantly, and you never know when market activity will align to encourage huge amounts of money wanting to lock up in the system. . As more funds are pegged in, there is a greater possibility that the volume to be pegged out will increase significantly at once. This dynamic essentially causes the queue to exit the system to continue to grow unless the maximum epoch withdrawal amount is increased, which also increases the liquidity requirements of the operator.

This worsens the liquidity requirements of these pegs and inherently creates great friction for withdrawals. Swapping out doesn’t solve the problem. Unlike other two-way pegs that can facilitate a swap and then terminate it practically immediately, this ultimately locks counterparties’ liquidity in an ever-growing queue.

multiple operators

Both BitVM 1 and BitVM 2 support having multiple validators in various ways, allowing more than one to participate and revoking an operator’s access to funds. With BitVM 2 (and some BitVM-based pegs, such as Citrea Rollup), it is also possible to have multiple operators working in parallel. Multiple liquidity pools can be used to facilitate a peg, as more than one institution can help process withdrawals from the peg.

This would, in principle, make the entire liquidity dynamic much more scalable. You are no longer limited to a single entity needing to frontload liquidity to facilitate timely withdrawals from the system, but this raises questions about complexity. Each UTXO deposited into a BitVM peg and bound by a contract must have defined billing terms. The contract must now be able to distinguish between different operators, ensure a means of distinguishing which withdrawals are associated with which operator, and ensure that only the funds it facilitates are claimed, rather than funds intended for other operators. .

Additionally, all operators must consider how to handle the global withdrawal demand that exists to facilitate. What happens if all operators have used up all their capital and there is still unmet demand? Do you have access to all your canceled BitVM funds? None of them? Is there a rollover grace period similar to queue throttling? If so, who is to blame if withdrawals are still not facilitated in the next era? These are all things that need to be addressed specifically.

multiple linear operators

In addition to multiple parallel operators, we can also have a set of linear operators. A single operator can function at a time to facilitate withdrawals, and if liquidity issues arise and access is revoked from BitVM funds, funds can be immediately transferred to a new BitVM after a challenge/revocation process. New operator. This in no way addresses the risk of a single operator experiencing a liquidity crisis, realizing the loss of withdrawals they have already deposited, but having the opportunity for others to step in and continue to facilitate withdrawals. Claim compensation from BitVM.

However, this adds significant cost to the peg-in process. Creating a BitVM instance is not cheap in terms of data and interaction. This means that if you want to chain linear BitVM operators together like this, you need to create that number of BitVMs for the peg-in.

backstop

In all cases of pegs using BitVM, there is one ultimate question: In the worst-case scenario, where will the money end up if it fails? Ultimately, you have two options: In effect, either burning the funds or placing them under the control of the validator. The first means that the user’s funds are now destroyed and anyone holding funds in the peg is now solidified. The second means that the trust model has completely shifted to trusting individual validators or groups of validators in a federation that unilaterally controls the funds.

In models without withdrawal controls, fund burning does not begin. Because this may validate the worst-case scenario concerns expressed by Taproot Wizards. Continuous instances of operator failure, whether parallel or linear, actually result in the destruction of users’ funds. The only models on which this is remotely safe are those with pull-out throttles. However, even if the operator defined in the contract disappears or has access revoked, the risk of permanent loss of funds still exists.

This puts the funds back under the control of a single validator or group of them. If all operators fail completely, the validators involved in the system can reclaim users’ funds and make them whole. I don’t think this is that bad.

Every BitVM instance is set up with n-of-n multi-signature, which handles signing all pre-signed transactions associated with a BitVM contract. The ultimate root security model of the entire scheme is that for the system to be secure, only one key holder must be honest and refuse to sign a dishonest distribution of funds.

If the entire operator fails, the same security model can be applied to determine where the funds go (except the operator). This could also make this a traditional m-of-n multi-signature, with the risk of a single key being lost or not cooperating in depleting funds.

I don’t see any problem with this type of setup. This achieves the goal of ensuring that users’ funds are not irreversibly burned without significantly changing the trust model. Ultimately, even if you are not a direct participant in the BitVM contract, i.e. you directly hold one of the n keys, you are still trusting some sort of federation. Having to honestly trust only one member to keep everything safe is obviously superior to having to trust three in 5/7 multi-sig, but it’s still a form of delegated trust.

finish

Ultimately, I think the liquidity crisis problem identified by Taproot Wizards is a very legitimate problem. Depending on the specific architecture of the peg in question, problems can range from completely draining a user’s funds, to losing an operator’s funds without any malicious action, to creating ever-growing queues to stop deposits or exit without retreating. . n-of-n groups bypass the queue.

However, in my opinion this does not mean that the idea of ​​using BitVM to secure a two-way peg is a fundamentally broken idea. I think the specific implementation laid out a number of ways to prevent or mitigate the problem and ultimately presented the reality of n-of-n groups existing and the possibility of sending funds to delegated groups in failed cases. Processing withdrawals addresses the risk of permanent loss of funds.

Lastly, the pace of development in this space has reached the highest level I’ve ever seen in the last year or so during my time here. I think it’s important to take a step back and remain calm when discussing these developments. We look at the debates that arise about trade-offs and risks. Yes, public perception is one aspect of these conversations that take place in public, but these discussions must be rooted in the goal of reaching an accurate understanding of the issues at hand. It should not take a backseat to attempts to first delegitimize or defend a particular public perception.