Às 14:07:18, o Health Factor na minha simulação de liquidação caiu abaixo de 1,0.

A posição ficou oficialmente liquidável.

Mas a liquidação não começou exatamente nesse momento.

Minha linha do tempo simulada mostrou:

Colateral selecionado: 0,2694
Preço de referência: US$ 64.712,80
Detecção do indexador: +4,81s
Transmissão da transação: +11,54s
Primeira confirmação: +19,36s
Vault entrou em escrow: +27,92s
Repasse para settlement: +43,17s

Durante esses 43,17 segundos, apliquei mais uma queda de 0,68% no preço.

O colateral selecionado perdeu aproximadamente US$ 118,55 em valor antes da rota chegar ao settlement.

Cada componente se comportou corretamente.

O limite foi acionado.

O estado insalubre foi detectado.

O liquidator enviou uma transação válida.

O vault chegou ao escrow.

Mas o mercado continuou se movendo entre essas ações corretas.

Essa é a Liquidation Latency Budget:

A quantidade de variação de preço e perda econômica que um sistema deve absorver entre a elegibilidade para liquidação e a execução real.

A cadeia foi simples:

HF < 1 → detecção → transação → confirmação → escrow → exposição ao settlement.

Meu feedback no Public Testnet não é prometer liquidação instantânea.

É tornar o atraso mensurável.

A interface deve mostrar:

Tempo desde que o HF cruzou 1,0
Estágio atual de execução
Status de transação pendente
Desvio de preço desde a detecção
Exposição estimada do colateral
Fallback caso nenhum liquidator responda

Um limite de liquidação define quando a ação é permitida.

A liveness da execução determina o preço em que essa ação se torna real.

Você avaliaria a segurança da liquidação apenas pelo limite do contrato, ou pelo tempo completo necessário para transformar esse limite em settlement?

@BabylonLabs_io $BABY #baby
$AKE
$KOMA