Lido: когда инцидент на 32 ETH важнее суммы

Это follow-up по Lido. Раньше в канале уже был разбор Core 2026 Upgrade и Staking Router v3. Тогда вопрос был в дизайне: как Lido меняет модули, учёт валидаторов и ответственность операторов.

Теперь появился новый факт: Lido опубликовал постмортем по инциденту Staking Router v3, Accounting Oracle и VEBO от 25 июля. Это не история про украденные деньги. По отчёту Lido, средства не были потеряны или заморожены. Но для оценки протокола тут важна не сумма, а место поломки.

Что подтвердилось по форуму Lido:

• после SRv3 отчёты Accounting Oracle и Validators ExitBus Oracle задерживались на 3-6 часов между 24 и 28 июля;

• в отчёте Accounting Oracle за 25 июля не был учтён один pending deposit на 32 ETH;

• из-за этого stETH rebase показал 2.04% вместо ожидаемых 2.15%, а следующий отчёт исправил расчёт до 2.29%;

• часть VEBO-отчётов не была собрана из-за edge-case с делением на ноль, что могло увеличить время финализации выводов;

• точную причину пропуска 32 ETH команда не восстановила, рабочая гипотеза - race condition между CL, EL и KAPI.

Для меня это проверка слоя отчётности. В liquid staking мало посмотреть на TVL, доходность и список операторов. После крупных апгрейдов надо отдельно разбирать, кто считает баланс, какие источники сверяются, что происходит при задержке oracle-отчёта, где стоят circuit breakers и что именно они блокируют.

Хороший момент: автоматические guardrails у Lido были, и команда пишет, что при более крупном отклонении отчёт был бы остановлен. Плохой момент: конкретный 32 ETH сбой не был воспроизведён, то есть часть вывода остаётся на уровне гипотезы и усиленного логирования на будущее.

Я бы здесь не делал вывод «Lido сломался» или «всё безопасно». Более честная рамка другая: SRv3 проверил модули, операторские штрафы и наблюдаемость протокола. Если oracle ошибся мало - это бухгалтерская поправка. Если ошибся сильно - это уже риск для rebase, выводов и внешних DeFi-интеграций, которые верят отчётам по stETH.

Что проверить аналитику перед тем, как доверять похожему апгрейду:

• есть ли постмортем с точным impact, а не только фраза «funds are safe»;

• воспроизведён ли root cause или он остался гипотезой;

• какие sanity checks добавили после инцидента;

• есть ли независимые alert-системы, а не только ручной мониторинг;

• может ли ошибка oracle повлиять на lending markets, withdrawals или ликвидность derivative-токена.

В таких историях риск обычно прячется не в заголовке, а в скучной связке: oracle - отчёт - задержка - интеграции.