Beim ersten Mal, als ich Babylon TBV simuliert habe, habe ich 20 Minuten damit verbracht, zwei Vaults umzuresizen… und gemerkt, dass ich das Spiel von Anfang an falsch verstanden hatte.
Ich habe 10.000 USD als BTC-Kollateral ausprobiert, mit einem 78%-Collateral Factor, und 7.000 USD ausgeliehen.
Der Health Factor lag bei etwa 1,11.
Preis fällt um 15% → HF rutscht auf grob 0,95 → liquidierbarer Zustand.
Klingt einfach, oder?
nein.
Das eigentliche Problem begann, als ich die Position in einen Sacrificial Vault und einen Protected Vault aufgeteilt habe.
Ein Vault entspricht genau einem UTXO, also macht die UTXO-Unteilbarkeit Liquidation zu einer Frage der Ausführungsreihenfolge – nicht nur zur Größe des Kollaterals.
Ein einzelner Vault ist leichter zu verstehen, kollidiert aber mit der Liquidation Cliff.
Die Aufteilung in zwei Vaults entschärft den Effekt, führt jedoch Vault-Konfigurationsrisiko, Vault-Ordering-Risiko und sogar Operational Risk ein.
Ich habe die beiden Vaults ein paar Mal vertauscht… eine kleine Änderung reichte, um die Minimum Liquidation Unit, die Target Seizure Amount und zu ändern, welche Assets zuerst beansprucht werden konnten.
Ehrlich gesagt ist das der Punkt, an dem TBV gleichzeitig faszinierend und zum Ärgern wird.
@BabylonLabs_io can optimize the UI, suggest Vault Reordering, and calculate Target Health Factor or Liquidation Bonus.
aber der Oracle-Preis fragt nicht, ob du das System verstanden hast.
Die Liquidation-Bot-Speed wartet nicht, bis du mit deinem Kaffee fertig bist.
Die Confirmation Time ist noch weniger daran interessiert, dass du vorhattest, den Vault fünf Minuten später anzupassen.
Fairness Payment kann den Over-Seizure Surplus zurückgeben, und ich respektiere das.
aber Entschädigung ist Entschädigung, Ausführungspfad ist Ausführungspfad… nicht das Gleiche.
was ich mir jetzt anschauen will, ist das Average Over-Seizure Ratio, die Liquidation Count, die Settlement-Zeit und was passiert, wenn ein echter Mainnet-Stresstest eintrifft.
Denn für mich ist das beste Protokoll nicht das, welches Komplexität am besten versteckt.
Es ist das, welches Nutzer verstehen lässt, welcher Teil ihrer Assets Priorität bei der Ausführung bekommt.
Wenn Partial-Position Liquidation nicht natürlich existieren kann, weil die UTXO-Struktur das verhindert – sollte das Protokoll diese Komplexität übernehmen… oder sollten Nutzer sie selbst managen?
#baby $BABY @BabylonLabs_io $BEAT $COTI
Ich habe 10.000 USD als BTC-Kollateral ausprobiert, mit einem 78%-Collateral Factor, und 7.000 USD ausgeliehen.
Der Health Factor lag bei etwa 1,11.
Preis fällt um 15% → HF rutscht auf grob 0,95 → liquidierbarer Zustand.
Klingt einfach, oder?
nein.
Das eigentliche Problem begann, als ich die Position in einen Sacrificial Vault und einen Protected Vault aufgeteilt habe.
Ein Vault entspricht genau einem UTXO, also macht die UTXO-Unteilbarkeit Liquidation zu einer Frage der Ausführungsreihenfolge – nicht nur zur Größe des Kollaterals.
Ein einzelner Vault ist leichter zu verstehen, kollidiert aber mit der Liquidation Cliff.
Die Aufteilung in zwei Vaults entschärft den Effekt, führt jedoch Vault-Konfigurationsrisiko, Vault-Ordering-Risiko und sogar Operational Risk ein.
Ich habe die beiden Vaults ein paar Mal vertauscht… eine kleine Änderung reichte, um die Minimum Liquidation Unit, die Target Seizure Amount und zu ändern, welche Assets zuerst beansprucht werden konnten.
Ehrlich gesagt ist das der Punkt, an dem TBV gleichzeitig faszinierend und zum Ärgern wird.
@BabylonLabs_io can optimize the UI, suggest Vault Reordering, and calculate Target Health Factor or Liquidation Bonus.
aber der Oracle-Preis fragt nicht, ob du das System verstanden hast.
Die Liquidation-Bot-Speed wartet nicht, bis du mit deinem Kaffee fertig bist.
Die Confirmation Time ist noch weniger daran interessiert, dass du vorhattest, den Vault fünf Minuten später anzupassen.
Fairness Payment kann den Over-Seizure Surplus zurückgeben, und ich respektiere das.
aber Entschädigung ist Entschädigung, Ausführungspfad ist Ausführungspfad… nicht das Gleiche.
was ich mir jetzt anschauen will, ist das Average Over-Seizure Ratio, die Liquidation Count, die Settlement-Zeit und was passiert, wenn ein echter Mainnet-Stresstest eintrifft.
Denn für mich ist das beste Protokoll nicht das, welches Komplexität am besten versteckt.
Es ist das, welches Nutzer verstehen lässt, welcher Teil ihrer Assets Priorität bei der Ausführung bekommt.
Wenn Partial-Position Liquidation nicht natürlich existieren kann, weil die UTXO-Struktur das verhindert – sollte das Protokoll diese Komplexität übernehmen… oder sollten Nutzer sie selbst managen?
#baby $BABY @BabylonLabs_io $BEAT $COTI