I reread those parts of the settlement process for @BabylonLabs_io again and realized there’s one thing I’ve never quite figured out: the vault script was signed in advance—something nobody can change—so how does it “know” when to release BTC?
My previous understanding was that there must be something like an oracle watching from the side: a signal is sent off-chain, and then the on-chain execution happens. Turns out that’s not the case at all—TBV does the reverse. It doesn’t ask Bitcoin to proactively sense what’s happening on the host chain; instead, it requires the party that wants to use BTC to take what has already occurred on the host chain and translate it into a cryptographic proof that a Bitcoin script can verify, then submit that.
The script itself, from start to finish, doesn’t understand lending, doesn’t understand settlement, and doesn’t understand price. It only does one thing—checks whether the proof satisfies a pre-defined spending path.
That’s also why the whitepaper’s “claim transaction” and “challenge transaction” design exists. If the borrower wants to get their BTC back, they first send a claim; if nobody challenges it, it passes after a timelock. But as long as the lender suspects something is wrong, they can initiate a challenge, forcing the borrower to reveal the signed ZK proof on the spot. If the proof is valid, the BTC is released; if it’s invalid, the secret is extracted from the obfuscation circuit and the withdrawal is directly blocked.
Throughout the process, there’s no third party making a ruling on the Bitcoin chain. The power to decide is encoded in the script conditions—not handed to a person.
With this understanding, what TBV changes isn’t “whether BTC exists,” but rather gives Bitcoin, for the first time, the ability to produce a verifiable reaction to an external event it itself can’t understand at all. You don’t need to trust what someone says—you only need to verify whether that proof is good enough.
How long exactly is the timelock set for the specific challenge window? I couldn’t find a single unified value in the document—it may be set differently by different integrated applications, and I haven’t checked that part yet. If you were to design the length of this challenge window, would you lean toward making it longer for safety, or shorter for better user experience?#baby $BABY
My previous understanding was that there must be something like an oracle watching from the side: a signal is sent off-chain, and then the on-chain execution happens. Turns out that’s not the case at all—TBV does the reverse. It doesn’t ask Bitcoin to proactively sense what’s happening on the host chain; instead, it requires the party that wants to use BTC to take what has already occurred on the host chain and translate it into a cryptographic proof that a Bitcoin script can verify, then submit that.
The script itself, from start to finish, doesn’t understand lending, doesn’t understand settlement, and doesn’t understand price. It only does one thing—checks whether the proof satisfies a pre-defined spending path.
That’s also why the whitepaper’s “claim transaction” and “challenge transaction” design exists. If the borrower wants to get their BTC back, they first send a claim; if nobody challenges it, it passes after a timelock. But as long as the lender suspects something is wrong, they can initiate a challenge, forcing the borrower to reveal the signed ZK proof on the spot. If the proof is valid, the BTC is released; if it’s invalid, the secret is extracted from the obfuscation circuit and the withdrawal is directly blocked.
Throughout the process, there’s no third party making a ruling on the Bitcoin chain. The power to decide is encoded in the script conditions—not handed to a person.
With this understanding, what TBV changes isn’t “whether BTC exists,” but rather gives Bitcoin, for the first time, the ability to produce a verifiable reaction to an external event it itself can’t understand at all. You don’t need to trust what someone says—you only need to verify whether that proof is good enough.
How long exactly is the timelock set for the specific challenge window? I couldn’t find a single unified value in the document—it may be set differently by different integrated applications, and I haven’t checked that part yet. If you were to design the length of this challenge window, would you lean toward making it longer for safety, or shorter for better user experience?#baby $BABY