The first time I simulated Babylon TBV, I spent 20 minutes resizing two Vaults... and realized I had misunderstood the game from the start.
i tried 10,000 USD in BTC collateral, with a 78% Collateral Factor, borrowing 7,000 USD.
Health Factor came out around 1.11.
price drops 15% → HF slides to roughly 0.95 → Liquidatable State.
sounds simple, right?
no.
the real problem started when I split the position into a Sacrificial Vault and a Protected Vault.
one Vault maps to one UTXO, so UTXO Indivisibility turns Liquidation into a question of execution order, not just collateral size.
Single Vault is easier to understand, but runs into the Liquidation Cliff.
Two-Vault Split softens the impact, yet introduces Vault Configuration Risk, Vault Ordering Risk, even Operational Risk.
i reversed the two Vaults a few times... one small change was enough to alter the Minimum Liquidation Unit, Target Seizure Amount, and which assets could be claimed first.
honestly, this is where TBV becomes fascinating and irritating at once.
@BabylonLabs_io can optimize the UI, suggest Vault Reordering, and calculate Target Health Factor or Liquidation Bonus.
but Oracle Price does not ask whether you understood the system.
Liquidation Bot Speed will not wait for you to finish your coffee.
Confirmation Time cares even less that you planned to adjust a Vault five minutes later.
Fairness Payment may return the Over-Seizure Surplus, and I respect that.
but compensation is compensation, execution path is execution path... not the same thing.
what I want to watch now is Average Over-Seizure Ratio, Liquidation Count, settlement time, and what happens when a real Mainnet Stress Test arrives.
because to me, the best protocol is not the one that hides complexity best.
it is the one that makes users understand which part of their assets gets priority execution.
if Partial-Position Liquidation cannot naturally exist because of the UTXO structure, should the protocol absorb that complexity... or should users manage it themselves?
#baby $BABY @BabylonLabs_io $BEAT $COTI
i tried 10,000 USD in BTC collateral, with a 78% Collateral Factor, borrowing 7,000 USD.
Health Factor came out around 1.11.
price drops 15% → HF slides to roughly 0.95 → Liquidatable State.
sounds simple, right?
no.
the real problem started when I split the position into a Sacrificial Vault and a Protected Vault.
one Vault maps to one UTXO, so UTXO Indivisibility turns Liquidation into a question of execution order, not just collateral size.
Single Vault is easier to understand, but runs into the Liquidation Cliff.
Two-Vault Split softens the impact, yet introduces Vault Configuration Risk, Vault Ordering Risk, even Operational Risk.
i reversed the two Vaults a few times... one small change was enough to alter the Minimum Liquidation Unit, Target Seizure Amount, and which assets could be claimed first.
honestly, this is where TBV becomes fascinating and irritating at once.
@BabylonLabs_io can optimize the UI, suggest Vault Reordering, and calculate Target Health Factor or Liquidation Bonus.
but Oracle Price does not ask whether you understood the system.
Liquidation Bot Speed will not wait for you to finish your coffee.
Confirmation Time cares even less that you planned to adjust a Vault five minutes later.
Fairness Payment may return the Over-Seizure Surplus, and I respect that.
but compensation is compensation, execution path is execution path... not the same thing.
what I want to watch now is Average Over-Seizure Ratio, Liquidation Count, settlement time, and what happens when a real Mainnet Stress Test arrives.
because to me, the best protocol is not the one that hides complexity best.
it is the one that makes users understand which part of their assets gets priority execution.
if Partial-Position Liquidation cannot naturally exist because of the UTXO structure, should the protocol absorb that complexity... or should users manage it themselves?
#baby $BABY @BabylonLabs_io $BEAT $COTI