À 14:07:18, le Health Factor dans ma relecture de liquidation est passé sous 1,0.
La position était officiellement liquidable.
Mais le règlement n’a pas commencé à ce moment précis.
Ma chronologie simulée a montré :
Collatéral sélectionné : 0,2694
Prix de référence : 64 712,80 $
Détection de l’indexeur : +4,81 s
Diffusion de la transaction : +11,54 s
Première confirmation : +19,36 s
Le coffre est entré en escrow : +27,92 s
Transmission du règlement : +43,17 s
Pendant ces 43,17 secondes, j’ai appliqué une nouvelle baisse de prix de 0,68 %.
Le collatéral sélectionné a perdu environ 118,55 $ de valeur avant que le trajet n’atteigne le règlement.
Chaque composant a fonctionné correctement.
Le seuil s’est déclenché.
L’état insalubre a été détecté.
Le liquidateur a soumis une transaction valide.
Le coffre a atteint l’escrow.
Mais le marché a continué d’évoluer entre ces actions correctes.
Voici le Liquidation Latency Budget :
La quantité de variation de prix et de pertes économiques qu’un système doit absorber entre l’éligibilité à la liquidation et l’exécution réelle.
La chaîne était simple :
HF < 1 → détection → transaction → confirmation → escrow → exposition au règlement.
Mon retour sur le Public Testnet est de ne pas promettre une liquidation instantanée.
Il s’agit de rendre le délai mesurable.
L’interface devrait afficher :
Temps écoulé depuis le franchissement de 1,0 par le HF
Étape d’exécution actuelle
Statut de la transaction en attente
Dérive du prix depuis la détection
Exposition estimée du collatéral
Solution de repli si aucun liquidateur ne répond
Un seuil de liquidation définit quand une action est autorisée.
La vivacité de l’exécution détermine le prix auquel cette action devient réelle.
Considérez-vous la sécurité de la liquidation uniquement par le seuil du contrat, ou par l’ensemble du temps nécessaire pour transformer ce seuil en règlement ?
@BabylonLabs_io $BABY #baby
$AKE
$KOMA
La position était officiellement liquidable.
Mais le règlement n’a pas commencé à ce moment précis.
Ma chronologie simulée a montré :
Collatéral sélectionné : 0,2694
Prix de référence : 64 712,80 $
Détection de l’indexeur : +4,81 s
Diffusion de la transaction : +11,54 s
Première confirmation : +19,36 s
Le coffre est entré en escrow : +27,92 s
Transmission du règlement : +43,17 s
Pendant ces 43,17 secondes, j’ai appliqué une nouvelle baisse de prix de 0,68 %.
Le collatéral sélectionné a perdu environ 118,55 $ de valeur avant que le trajet n’atteigne le règlement.
Chaque composant a fonctionné correctement.
Le seuil s’est déclenché.
L’état insalubre a été détecté.
Le liquidateur a soumis une transaction valide.
Le coffre a atteint l’escrow.
Mais le marché a continué d’évoluer entre ces actions correctes.
Voici le Liquidation Latency Budget :
La quantité de variation de prix et de pertes économiques qu’un système doit absorber entre l’éligibilité à la liquidation et l’exécution réelle.
La chaîne était simple :
HF < 1 → détection → transaction → confirmation → escrow → exposition au règlement.
Mon retour sur le Public Testnet est de ne pas promettre une liquidation instantanée.
Il s’agit de rendre le délai mesurable.
L’interface devrait afficher :
Temps écoulé depuis le franchissement de 1,0 par le HF
Étape d’exécution actuelle
Statut de la transaction en attente
Dérive du prix depuis la détection
Exposition estimée du collatéral
Solution de repli si aucun liquidateur ne répond
Un seuil de liquidation définit quand une action est autorisée.
La vivacité de l’exécution détermine le prix auquel cette action devient réelle.
Considérez-vous la sécurité de la liquidation uniquement par le seuil du contrat, ou par l’ensemble du temps nécessaire pour transformer ce seuil en règlement ?
@BabylonLabs_io $BABY #baby
$AKE
$KOMA