A las 14:07:18, el Health Factor en la repetición de mi liquidación bajó de 1.0.
La posición era oficialmente liquidable.
Pero la liquidación no comenzó en ese momento exacto.
Mi cronología simulada mostró:
Colateral seleccionado: 0.2694
Precio de referencia: $64,712.80
Detección del indexador: +4.81s
Difusión de la transacción: +11.54s
Primera confirmación: +19.36s
La bóveda entró en escrow: +27.92s
Cesión para liquidación: +43.17s
Durante esos 43.17 segundos, apliqué otra caída del 0.68% en el precio.
El colateral seleccionado perdió aproximadamente $118.55 de valor antes de que la ruta llegara al momento de liquidación.
Cada componente se comportó correctamente.
Se activó el umbral.
Se detectó el estado no saludable.
El liquidador envió una transacción válida.
La bóveda llegó al escrow.
Pero el mercado siguió moviéndose entre esas acciones correctas.
Ese es el Liquidation Latency Budget:
La cantidad de movimiento de precio y pérdida económica que un sistema debe absorber entre la elegibilidad para liquidación y la ejecución real.
La cadena fue sencilla:
HF < 1 → detección → transacción → confirmación → escrow → exposición a la liquidación.
El feedback de mi Public Testnet es que no se prometa una liquidación instantánea.
Es hacer que el retraso sea medible.
La interfaz debería mostrar:
Tiempo desde que el HF cruzó 1.0
Etapa de ejecución actual
Estado de transacción pendiente
Deriva de precio desde la detección
Exposición estimada del colateral
Plan de respaldo si ningún liquidador responde
Un umbral de liquidación define cuándo se permite la acción.
La vivacidad de la ejecución determina el precio en el que esa acción se vuelve real.
¿Juzgarías la seguridad de la liquidación solo por el umbral del contrato, o por el tiempo completo necesario para convertir ese umbral en liquidación?
@BabylonLabs_io $BABY #baby
$AKE
$KOMA
La posición era oficialmente liquidable.
Pero la liquidación no comenzó en ese momento exacto.
Mi cronología simulada mostró:
Colateral seleccionado: 0.2694
Precio de referencia: $64,712.80
Detección del indexador: +4.81s
Difusión de la transacción: +11.54s
Primera confirmación: +19.36s
La bóveda entró en escrow: +27.92s
Cesión para liquidación: +43.17s
Durante esos 43.17 segundos, apliqué otra caída del 0.68% en el precio.
El colateral seleccionado perdió aproximadamente $118.55 de valor antes de que la ruta llegara al momento de liquidación.
Cada componente se comportó correctamente.
Se activó el umbral.
Se detectó el estado no saludable.
El liquidador envió una transacción válida.
La bóveda llegó al escrow.
Pero el mercado siguió moviéndose entre esas acciones correctas.
Ese es el Liquidation Latency Budget:
La cantidad de movimiento de precio y pérdida económica que un sistema debe absorber entre la elegibilidad para liquidación y la ejecución real.
La cadena fue sencilla:
HF < 1 → detección → transacción → confirmación → escrow → exposición a la liquidación.
El feedback de mi Public Testnet es que no se prometa una liquidación instantánea.
Es hacer que el retraso sea medible.
La interfaz debería mostrar:
Tiempo desde que el HF cruzó 1.0
Etapa de ejecución actual
Estado de transacción pendiente
Deriva de precio desde la detección
Exposición estimada del colateral
Plan de respaldo si ningún liquidador responde
Un umbral de liquidación define cuándo se permite la acción.
La vivacidad de la ejecución determina el precio en el que esa acción se vuelve real.
¿Juzgarías la seguridad de la liquidación solo por el umbral del contrato, o por el tiempo completo necesario para convertir ese umbral en liquidación?
@BabylonLabs_io $BABY #baby
$AKE
$KOMA