Um 14:07:18 fiel der Health Factor in meinem Liquidations-Replay unter 1.0.
Die Position war offiziell liquidierbar.
Aber die Abwicklung begann nicht genau in diesem Moment.
Meine simulierte Zeitleiste zeigte:
Ausgewähltes Sicherheitenkapital: 0.2694
Referenzpreis: $64,712.80
Indexer-Erkennung: +4.81s
Transaktions-Weiterleitung: +11.54s
Erste Bestätigung: +19.36s
Vault gelangte in Escrow: +27.92s
Abgabe zur Abwicklung: +43.17s
Während dieser 43.17 Sekunden wandte ich einen weiteren Kursrückgang von 0.68% an.
Die ausgewählten Sicherheiten verloren ungefähr $118.55 an Wert, bevor die Route die Abwicklung erreichte.
Jede Komponente verhielt sich korrekt.
Der Grenzwert wurde ausgelöst.
Der ungesunde Zustand wurde erkannt.
Der Liquidator reichte eine gültige Transaktion ein.
Der Vault erreichte den Escrow.
Aber der Markt bewegte sich weiterhin zwischen diesen korrekten Aktionen.
Das ist das Liquidation Latency Budget:
Die Menge an Kursbewegung und wirtschaftlichem Verlust, die ein System zwischen Liquidationsberechtigung und tatsächlicher Ausführung absorbieren muss.
Die Kette war einfach:
HF < 1 → Erkennung → Transaktion → Bestätigung → Escrow → Abwicklungs-Exposition.
Mein Feedback aus dem Public Testnet lautet: Versprecht keine sofortige Liquidation.
Es geht darum, die Verzögerung messbar zu machen.
Die Benutzeroberfläche sollte Folgendes anzeigen:
Zeit seit der HF die 1.0 überschritten hat
Aktuelle Ausführungsphase
Status der ausstehenden Transaktion
Kursdrift seit der Erkennung
Geschätzte Sicherheiten-Exposition
Fallback, falls kein Liquidator reagiert
Ein Liquidationsschwellenwert definiert, wann eine Aktion erlaubt ist.
Execution Liveness bestimmt den Preis, bei dem diese Aktion real wird.
Würdet ihr die Liquidationssicherheit nur anhand des Vertragsgrenzwerts beurteilen – oder anhand der vollständigen Zeit, die benötigt wird, um diesen Grenzwert in eine Abwicklung zu verwandeln?
@BabylonLabs_io $BABY #baby
$AKE
$KOMA
Die Position war offiziell liquidierbar.
Aber die Abwicklung begann nicht genau in diesem Moment.
Meine simulierte Zeitleiste zeigte:
Ausgewähltes Sicherheitenkapital: 0.2694
Referenzpreis: $64,712.80
Indexer-Erkennung: +4.81s
Transaktions-Weiterleitung: +11.54s
Erste Bestätigung: +19.36s
Vault gelangte in Escrow: +27.92s
Abgabe zur Abwicklung: +43.17s
Während dieser 43.17 Sekunden wandte ich einen weiteren Kursrückgang von 0.68% an.
Die ausgewählten Sicherheiten verloren ungefähr $118.55 an Wert, bevor die Route die Abwicklung erreichte.
Jede Komponente verhielt sich korrekt.
Der Grenzwert wurde ausgelöst.
Der ungesunde Zustand wurde erkannt.
Der Liquidator reichte eine gültige Transaktion ein.
Der Vault erreichte den Escrow.
Aber der Markt bewegte sich weiterhin zwischen diesen korrekten Aktionen.
Das ist das Liquidation Latency Budget:
Die Menge an Kursbewegung und wirtschaftlichem Verlust, die ein System zwischen Liquidationsberechtigung und tatsächlicher Ausführung absorbieren muss.
Die Kette war einfach:
HF < 1 → Erkennung → Transaktion → Bestätigung → Escrow → Abwicklungs-Exposition.
Mein Feedback aus dem Public Testnet lautet: Versprecht keine sofortige Liquidation.
Es geht darum, die Verzögerung messbar zu machen.
Die Benutzeroberfläche sollte Folgendes anzeigen:
Zeit seit der HF die 1.0 überschritten hat
Aktuelle Ausführungsphase
Status der ausstehenden Transaktion
Kursdrift seit der Erkennung
Geschätzte Sicherheiten-Exposition
Fallback, falls kein Liquidator reagiert
Ein Liquidationsschwellenwert definiert, wann eine Aktion erlaubt ist.
Execution Liveness bestimmt den Preis, bei dem diese Aktion real wird.
Würdet ihr die Liquidationssicherheit nur anhand des Vertragsgrenzwerts beurteilen – oder anhand der vollständigen Zeit, die benötigt wird, um diesen Grenzwert in eine Abwicklung zu verwandeln?
@BabylonLabs_io $BABY #baby
$AKE
$KOMA