“If building a position fails, you can get the BTC back yourself” sounds like tapping for a refund after a failure. I arranged the TBV testnet timeout parameters for @BabylonLabs_io into a timeline, and only then realized that trustlessness guarantees final funds are reclaimable—not that the transfer returns immediately back to the original route.
On the current testnet, you first need to wait for 12 signet block confirmations; a full peg-in usually takes about 2 hours. Participants must complete the ACK within about 24 hours. After the vault verification is complete, the user must submit activation within roughly 48 hours from the time it was created. If any step isn’t completed, the status moves to Expired—but on the Bitcoin side, the refund leaf is still constrained by a 3-day timelock, and only after that time can you use your own BTC private key to broadcast the refund.
It’s like self check-in at a hotel: the room key card machine is broken, and the deposit won’t be swallowed by the front desk, but the safe can only be opened when the timed lock reaches the preset point. Recoverability is a safety guarantee; waiting, monitoring the status, and rebroadcasting transactions are still user costs.
The fees for the two failure scenarios are also different. If the offline coordination isn’t completed within about 24 hours, the peg-in fee is automatically refunded. If the system has already built the vault to the Verified state but the user forgets to activate within the 48-hour window, the BTC can still follow the refund path—but that service fee isn’t refunded. Protocol failures and users ghosting don’t end up on the same bill.
This distinction is reasonable: in the former case, the service hasn’t been completed, so the fee is returned; in the latter, the participant has already done the signing and preparation work—if the user didn’t press the button, you can’t demand that all backend labor should go to zero. But if the frontend only says “funds are safe,” without putting the 24-hour, 48-hour, and 3-day countdowns together, ordinary people will easily misread recoverability as “instant arrival.”
So looking at the TBV experience for #baby , I’ll focus on testing the failure paths: whether notifications are timely, whether the reason for Expired is clear, and whether the refund transaction can be broadcast smoothly. The product narrative for $BABY is truly mature—not that the flow is pretty when everything goes right, but that when it gets stuck, users still know what to do next.
$BLESS $CYS
On the current testnet, you first need to wait for 12 signet block confirmations; a full peg-in usually takes about 2 hours. Participants must complete the ACK within about 24 hours. After the vault verification is complete, the user must submit activation within roughly 48 hours from the time it was created. If any step isn’t completed, the status moves to Expired—but on the Bitcoin side, the refund leaf is still constrained by a 3-day timelock, and only after that time can you use your own BTC private key to broadcast the refund.
It’s like self check-in at a hotel: the room key card machine is broken, and the deposit won’t be swallowed by the front desk, but the safe can only be opened when the timed lock reaches the preset point. Recoverability is a safety guarantee; waiting, monitoring the status, and rebroadcasting transactions are still user costs.
The fees for the two failure scenarios are also different. If the offline coordination isn’t completed within about 24 hours, the peg-in fee is automatically refunded. If the system has already built the vault to the Verified state but the user forgets to activate within the 48-hour window, the BTC can still follow the refund path—but that service fee isn’t refunded. Protocol failures and users ghosting don’t end up on the same bill.
This distinction is reasonable: in the former case, the service hasn’t been completed, so the fee is returned; in the latter, the participant has already done the signing and preparation work—if the user didn’t press the button, you can’t demand that all backend labor should go to zero. But if the frontend only says “funds are safe,” without putting the 24-hour, 48-hour, and 3-day countdowns together, ordinary people will easily misread recoverability as “instant arrival.”
So looking at the TBV experience for #baby , I’ll focus on testing the failure paths: whether notifications are timely, whether the reason for Expired is clear, and whether the refund transaction can be broadcast smoothly. The product narrative for $BABY is truly mature—not that the flow is pretty when everything goes right, but that when it gets stuck, users still know what to do next.
$BLESS $CYS