В 14:07:18 фактор здоровья (Health Factor) в моем воспроизведении ликвидации опустился ниже 1.0.
Позиция официально подлежала ликвидации.
Но расчёт (settlement) не начался в тот самый момент.
Мой смоделированный таймлайн показал:
Выбрано обеспечение: 0.2694
Референсная цена: $64,712.80
Обнаружение индексатором: +4.81с
Публикация транзакции: +11.54с
Первое подтверждение: +19.36с
Вхождение в escrow (хранилище): +27.92с
Передача на settlement: +43.17s
За эти 43.17 секунды я применил ещё одно снижение цены на 0.68%.
Выбранное обеспечение потеряло примерно $118.55 в стоимости до того, как маршрут достиг расчёта.
Каждый компонент работал корректно.
Сработал порог.
Было обнаружено нездоровое состояние.
Ликвидатор отправил корректную транзакцию.
Валюта дошла до escrow.
Но рынок продолжал двигаться между этими правильными действиями.
Это Лимит Латентности Ликвидации (Liquidation Latency Budget):
Количество движения цены и экономического убытка, которое система должна выдержать между моментом, когда ликвидация становится допустимой, и моментом фактического исполнения.
Цепочка была простой:
HF < 1 → обнаружение → транзакция → подтверждение → escrow → подверженность settlement.
Мой отзыв с Public Testnet — не обещать мгновенную ликвидацию.
Цель — сделать задержку измеримой.
Интерфейс должен показывать:
Время с момента, когда HF пересёк 1.0
Текущую стадию исполнения
Статус ожидающей транзакции
Отклонение цены с момента обнаружения
Оценку подверженности по обеспечению (collateral exposure)
Резервный сценарий, если ликвидатор не отвечает
Порог ликвидации определяет, когда действие разрешено.
Живость исполнения (execution liveness) определяет цену, при которой это действие становится реальным.
Как вы считаете: оценивать безопасность ликвидации только по порогу контракта, или по полному времени, необходимому, чтобы превратить тот порог в settlement?
@BabylonLabs_io $BABY #baby
$AKE
$KOMA
Позиция официально подлежала ликвидации.
Но расчёт (settlement) не начался в тот самый момент.
Мой смоделированный таймлайн показал:
Выбрано обеспечение: 0.2694
Референсная цена: $64,712.80
Обнаружение индексатором: +4.81с
Публикация транзакции: +11.54с
Первое подтверждение: +19.36с
Вхождение в escrow (хранилище): +27.92с
Передача на settlement: +43.17s
За эти 43.17 секунды я применил ещё одно снижение цены на 0.68%.
Выбранное обеспечение потеряло примерно $118.55 в стоимости до того, как маршрут достиг расчёта.
Каждый компонент работал корректно.
Сработал порог.
Было обнаружено нездоровое состояние.
Ликвидатор отправил корректную транзакцию.
Валюта дошла до escrow.
Но рынок продолжал двигаться между этими правильными действиями.
Это Лимит Латентности Ликвидации (Liquidation Latency Budget):
Количество движения цены и экономического убытка, которое система должна выдержать между моментом, когда ликвидация становится допустимой, и моментом фактического исполнения.
Цепочка была простой:
HF < 1 → обнаружение → транзакция → подтверждение → escrow → подверженность settlement.
Мой отзыв с Public Testnet — не обещать мгновенную ликвидацию.
Цель — сделать задержку измеримой.
Интерфейс должен показывать:
Время с момента, когда HF пересёк 1.0
Текущую стадию исполнения
Статус ожидающей транзакции
Отклонение цены с момента обнаружения
Оценку подверженности по обеспечению (collateral exposure)
Резервный сценарий, если ликвидатор не отвечает
Порог ликвидации определяет, когда действие разрешено.
Живость исполнения (execution liveness) определяет цену, при которой это действие становится реальным.
Как вы считаете: оценивать безопасность ликвидации только по порогу контракта, или по полному времени, необходимому, чтобы превратить тот порог в settlement?
@BabylonLabs_io $BABY #baby
$AKE
$KOMA