We took care in the article not to mention Robin at all. We looked through all the documentation/code we could find on BitVM pegs/bridges (which is sparse), and found that for some bridge proposals it seemed that the ultimate outcome of a bridge operator failing to front the withdrawals was them losing access to the bridge funds (https://www.blog.citrea.xyz/unveiling-clementine/). There was no mention of the funds going to a final validator, only that any bridge operator who failed to make a payment would lose access to bridge funds forever (emphasis not my own). There was no implementation of the challenge/response process, and the BitVM repo has been nuked, so it's hard to find accurate information on this. Admittedly, I believe we may have misinterpreted this description and what the ultimate fate of the bridge funds would be. I'm continuing to educate myself on this possible misstep today.

If you could also point me to any discussion around how the last validator is determined (if there has been any), I would appreciate it. My assumption will continue to be that if a bridge operator fails to make a payment for a bridge at large scale, all validators will also be unable to do this and we reduce to a 1/1 with the final validator.

That being said, I still take major issue with the claim that:

It feels either like a complete oversight or disingenuous to claim that "trusting" the validators requires them to: a.) become a bridge operator, and b.) source liquidity to front all withdrawals.

That is a far cry from what we mean by "honest" in every other situation in blockchains. A Bitcoin node being honest means rejecting blocks that break consensus. A multisig bridge being honest is signing valid withdrawals and rejecting invalid ones. A BitVM validator being honest means in the event of operator failure potentially sourcing millions or billions of dollars in liquidity? There is a a stark disonnect in what validation/honesty means on BitVM vs every other system.

There is nothing inherently wrong with the BitVM design, it works great at the small scale. But I still believe the economic description of how the system works has been at best ignored and at worst obfuscated. It should be made abundantly transparent that "safety" for a BitVM bridge means a bridge operator keeping a 1:1 capital ratio with the locked bridge funds.

I see L2s claiming to be "safer" by using BitVM, but also clearly aiming to attract a large amount of capital users. I believe these two goals are inherently at odds for capital efficiency reasons, and I believe this fact needs to be acknowledged by the broader Bitcoin community (builders, VCs, etc.).

Hey Super! Thanks for putting together this writeup. It definitely helps clarify the nuances of setting up a BitVM bridge. And I appreciate that you are one of the very few people who actually put together a bridge implementation.

In the article, we said "burned" for a couple reasons.

First, it just helped simplify it for the reader. The main point of the piece was that a safe bridge (as your design is) requires a 1:1 collateralization ratio. If the bridge operators all fail to pay out, then the users effectively lose access to their funds/require enormous trust assumptions to get them back.

Second, I think the options for places the funds go if the final operator cannot pay out effectively reduce to three options: the final verifier, anyone-can-spend, burn address. 1.) The final verifier - requires a 1/1 trust assumption to get funds back to users. not great. 2.) anyone-can-spend - miners get the lion's share of the bridge 3.) burn address - cryptographic security that bridge funds are inaccessible by anyone In each of these cases, we range from highly unlikely to impossible redemption of funds.

With that said, the higher level point is that we were frustrated with the narrative that BitVM bridges fix the issues we have wrt trusting bridges. Companies like Citrea, BOB, etc. are good actors, but the landscape is littered with many others who are not. A bridge of your design is 100% safe, but it also doesn't scale economically. There are other designs that do not require these collateral requirements and scale better but also put users' funds at risk.

The worst case is a company building a BitVM bridge and not understanding the economic reality and design tradeoffs of the system. It's very easy for me to imagine a scenario where an L2 bridge decides a 10% collateralization is acceptable, grows large in terms of TVL, and all users funds get burnt/lost following a mass withdrawal. This is terrible for our space, and something I strongly prefer we avoid. My hope is that by putting this information out there, we can go in eyes wide open to the economic realities of bridges built on BitVM.

Yes, optimistic rollups operate differently from zk rollups.

If we start with the similarities, both optimistic and zk rollups:

The difference comes in when we consider how they verify that a transaction on the rollup was valid.

Optimistic rollups assume all transactions are valid (hence "optimistic"). They rely on actors searching for invalid transactions in the transaction data that is posted back to the main chain. If an invalid tx is found, whoever found it can post a "fraud proof" that demonstrates it is invalid. If their fraud proof is successful, then the validator that included the invalid tx gets slashed.

Zk rollups operate differently. They rely on zero-knowledge proving systems to ensure that transactions on the rollup are valid. Through some cryptography wizardry, zk proving systems produce a "proof" to go along with each tx that shows it was executed correctly. Given the start state, the end state, and a proof, a verifier can validate that each tx was executed correctly.

So, the big difference is that zk rollups verify every transaction on the rollup whereas optimistic rollups only verify transactions when a fraud proof is submitted.

If you want to dive more into these two topics, I recommend Ethereum's developer docs on each: