I tried to point the same TBV testnet vault at a second lending market today, after closing out my Aave v4 position — figured I could just redeploy the same collateral record somewhere else without redoing the whole peg-in. No option for it anywhere in the app. Clicked around looking for a setting I'd missed, some toggle to add a second protocol to an existing vault. Ran a brand new peg-in from scratch just to check if a fresh vault behaved differently. Same wall both times.
Sat with that before it actually clicked: this isn't a missing feature, it's a boundary built in on purpose. One vault, one app, full stop — and if you want a second use case, you peg in again from zero.
I'd assumed the whole point of "programmable Bitcoin collateral" was stacking it — same BTC plugged into as many protocols as would take it, more composable the better. It's actually the opposite bet. A single vault exposed to two apps at once means two different liquidation logics and two different sets of exit rules both claiming the same BTC. Babylon didn't leave that door half-open by accident. It's shut.
Felt like a landlord who won't let you sublet a unit while your own lease is active, even to someone reputable, even short-term. Not because the second tenant's risky. Because two people with a live, simultaneous claim on one unit is the actual risk, regardless of who they are.
Makes sense once I thought about why, specifically for Bitcoin. Composability is usually DeFi's whole pitch, but a UTXO's spending conditions are fixed the moment it's created. Two live protocols means two sets of exit rules trying to govern one lock at once, and if they ever disagreed about who gets to trigger what, there's no patch that fixes it after the fact — Bitcoin doesn't do upgrades to a script that's already committed.
Still not sure if that's a testnet-stage limitation that loosens later, or a permanent tradeoff — composability given up on purpose, specifically because it's Bitcoin underneath and not an EVM asset that can absorb that kind of complexity safely.
@BabylonLabs_io $BABY #baby
Sat with that before it actually clicked: this isn't a missing feature, it's a boundary built in on purpose. One vault, one app, full stop — and if you want a second use case, you peg in again from zero.
I'd assumed the whole point of "programmable Bitcoin collateral" was stacking it — same BTC plugged into as many protocols as would take it, more composable the better. It's actually the opposite bet. A single vault exposed to two apps at once means two different liquidation logics and two different sets of exit rules both claiming the same BTC. Babylon didn't leave that door half-open by accident. It's shut.
Felt like a landlord who won't let you sublet a unit while your own lease is active, even to someone reputable, even short-term. Not because the second tenant's risky. Because two people with a live, simultaneous claim on one unit is the actual risk, regardless of who they are.
Makes sense once I thought about why, specifically for Bitcoin. Composability is usually DeFi's whole pitch, but a UTXO's spending conditions are fixed the moment it's created. Two live protocols means two sets of exit rules trying to govern one lock at once, and if they ever disagreed about who gets to trigger what, there's no patch that fixes it after the fact — Bitcoin doesn't do upgrades to a script that's already committed.
Still not sure if that's a testnet-stage limitation that loosens later, or a permanent tradeoff — composability given up on purpose, specifically because it's Bitcoin underneath and not an EVM asset that can absorb that kind of complexity safely.
@BabylonLabs_io $BABY #baby
