BitVM<\/a> has recently come under some scrutiny after the Taproot Wizards, Tyler and Rijndael, posted their criticism of the liquidity requirements imposed on the operator<\/a> 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 \u201cliquidity crunch\u201d 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. <\/p>\n Before I go into the liquidity crunch issue, I think it\u2019s 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. <\/p>\n 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<\/em> 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. <\/p>\n 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\u2019ve 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.<\/p>\n 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\u2019s 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. <\/p>\n For now let\u2019s 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<\/em> have their access revoked and incur the loss of whatever funds they have already spent on processing withdrawals. <\/p>\n 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<\/em> 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. <\/p>\n 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\u2019 money go in the event of an operator being hit with a fraud proof? <\/p>\n 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. <\/p>\n So now that we understand the problem let\u2019s look at some potential solutions. <\/p>\n 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. <\/p>\n The problem with this is you don\u2019t know when a large uptick in funds pegged into the system will occur, and you also don\u2019t 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. <\/p>\n 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. <\/p>\nThe Liquidity Crunch<\/h2>\n
The Options<\/h2>\n
Throttling<\/h3>\n
Multiple Operators<\/h3>\n