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…



Source link