The first time I put native BTC into Aave v4 on the testnet and then borrowed test assets, I kept staring at the health factor. I mistakenly thought that as long as I didn’t touch the liquidation line, this position was safe. Only when I continued through to repayment and redemption did I realize I’d understood just half of it.

Inside Trustless Bitcoin Vaults (TBV) with ID @BabylonLabs_io , several “clocks” are running at the same time. On the Aave side, it’s watching whether the position is underwater—that is, whether it can’t cover its debts. The proof and challenge window must verify that states like borrowing, repayment, and liquidation haven’t been forged. Bitcoin’s confirmation order is responsible for locking in the outcome that has already happened. The first layer stops chaos in the moment; the second layer prevents backtracking after the fact. It’s not something that can be fully solved just by over-collateralizing more.

That’s also why TBV is more appealing to me than wrapped BTC or custodial lending. Traditional approaches usually require you to hand over $BTC first, then rely on a custodial ledger or cross-chain asset proofs to determine balances. TBV doesn’t move native UTXOs. Instead, it uses preset spending conditions and cryptographic proofs to answer: who can spend this BTC right now, and under what state. $ETH

However, the testnet also revealed a very practical problem: during the waiting period, if the page only shows “processing,” users have no idea whether they’re waiting for Bitcoin confirmations, generating proofs, or being held in the challenge period. I suggest displaying the three stages, the remaining time, and the corresponding risk separately. Otherwise, even if the technical separation is crystal clear, users will still experience it as one big mess.

$BABY #baby

If you borrow using native BTC as collateral, which part do you care about most?