Today, I spent most of the day to try native BTC-backed borrowing on Babylon’s public testnet. The part I found most interesting was how a Trustless Bitcoin Vaults (TBV) can use a compact Groth16 proof to support redemption based on state from another chain. The proof itself is extremely small.

But once I looked into how BABE handles a disputed proof on Bitcoin, the size of the proof started to look like only part of the story. Bitcoin Script doesn't verify Groth16 directly. BABE has to represent the parts of the proof that may be challenged in a form Bitcoin can authenticate through transactions and scripts. That creates a distinction between proof compression and dispute cost. The Groth16 proof may be succinct, while the Bitcoin transactions needed to contest it are considerably larger.

What I don't know yet is whether the savings from Groth16 survive once a proof is actually disputed on Bitcoin. A small proof matters less if enforcing its validity still requires a much larger on-chain path.

The question is whether compression lowers the cost of the dispute itself, or only the size of the proof being carried into it.

That why I am watching the full transaction footprint and fee cost of real challenge paths, not the Groth16 proof size quoted in isolation.
$BABY $HEI #baby @BabylonLabs_io