I used to think if a protocol calls itself trustless there is no room left for any system level failure, everything gets settled by code alone. Reading through Babylon's TBV testnet troubleshooting docs quietly pushed back on that... it turns out if a vault sits in Pending for close to 24 hours the system assumes the off chain setup failed, the vault expires on its own and the peg in fee gets refunded. My first reaction was that this felt responsible, knowing your funds will not just sit frozen forever matters. But sitting with it longer raised a different question, who or what actually decides that the off chain setup failed, the whole sequence of authentication, signature collection and acknowledgments happens off chain before the vault ever becomes active, and if that entire judgment sits outside the chain then calling the process fully trustless feels like it is skipping over something, maybe it is less an absence of trust and more a trust that has been quietly relocated somewhere the user cannot directly watch. I kept circling back to the 24 hour number itself too, is it tuned around signet's irregular block times or is it just a conservative buffer picked for testnet convenience, because that single choice tells you a lot about how much slack the off chain layer actually needs to keep functioning. None of this makes the design bad, expiring a stuck vault and refunding the fee is still far better than leaving someone's BTC stuck in limbo indefinitely 🙌 it just means the word trustless is doing more work in the marketing than in the mechanism, at least at this stage of testing 🤔 (@BabylonLabs_io) is there a plan to make that off chain setup window verifiable on chain eventually, or does it stay a black box by design for now?
@BabylonLabs_io #baby $BABY
$GRVT
$memes