Lido postmortem details SRv3 Accounting Oracle and VEBO incident

What happened

Following the SRv3 release, Lido's Accounting Oracle and Validators ExitBus Oracle experienced report delays and edge-case failures. The July 25 Accounting Oracle report omitted one in-flight 32 ETH deposit, and some VEBO reports from July 26 through July 28 were not produced.

What changed

The omitted balance was included in the July 26 rebase. Lido replaced slow BLS verification, fixed the VEBO zero-weight edge case, and added Accounting Oracle invariant checks, circuit breakers, three-way input matching, and expanded logging.

What did not change

Lido reported no lost or frozen funds. Withdrawal finalization remained below the Ethereum network average, and the incident did not establish a change to stETH redemption rights. Existing rebase guardrails did not stop the 32 ETH discrepancy because it was within their allowed range.

Confirmed

• AO and VEBO report delivery was delayed by approximately three to six hours between July 24 and July 28.
• The July 25 report omitted one in-flight 32 ETH deposit and showed an extrapolated APR of 2.04% rather than the expected 2.15%.
• A manually checked July 26 report included the missing ETH and showed an extrapolated APR of 2.29%.
• Some VEBO reports were not produced between July 26 and July 28, modestly extending withdrawal-request finalization.
• Lido reported that no funds were lost or frozen and deployed oracle-code remediations.

Still open

• The exact cause of the single omitted pending deposit could not be reproduced or established; a CL, EL, and KAPI response race remained a working assumption.
• The long-term effectiveness of the new invariant checks and circuit breakers requires observation across subsequent oracle-report cycles.

What it means for an advisor

• Add the incident and remediation details to the Lido diligence record because accounting and exit-oracle reliability directly affect reported backing, rebases, and withdrawal timing.
• Review subsequent AO and VEBO reports for repeated balance mismatches or delayed exit processing before treating the issue as fully closed.
• The confirmed recovery and absence of loss do not independently justify a restriction, but they do require memo review of SRv3 oracle dependencies.