As a representative of Gateway.fm AS, node operator 35 in the Curated module, I would like
to share the following post-mortem with the Lido DAO.
Two unrelated incidents affected our validators in August 2026. Neither involved slashing
and neither put stake at risk.
Gateway.fm AS takes full responsibility for both.
We have reimbursed the DAO 1.0054 ETH sent to the Execution Layer Rewards Vault on 2 September 2026 in transaction 0xaeca4781…b60014.
That figure is the DAO’s own calculation, which we accepted in full. We would like to thank
the NOM workstream for producing it.
Incident 1 — Validators without a signer, and invalid signatures during recovery
18–19 August 2026. Resolved.
A batch of signing keys registered to our operator had no corresponding shares loaded in
our remote signer. The gap had no symptom while those keys stayed undeposited. When the
protocol deposited into that range, eight validators activated with no signer and could
not attest, for between 7.5 and 13.1 hours each.
While restoring the missing shares, a misconfiguration in our signing cluster caused
signatures to be rejected by the network. This affected approximately 7,300 validators for
75 minutes.
There was no slashing. An absent key produces no signature at all, and a malformed
signature is rejected before inclusion. No double-signing occurred at any point.
Impact
- 8 validators offline, 7.5–13.1 hours each — ~0.0117 ETH
- ~7,300 validators unable to attest for 75 minutes — ~0.892 ETH
- No slashing, no stake at risk
Root cause
Key registration was never reconciled against key custody. The gap was invisible to our
internal checks because each of them is populated by the provisioning step itself; only a
comparison against the on-chain registered key set can detect it. The second fault followed
from a restoration step that our pre-deployment verification was not able to validate.
What we have changed
- Reconcile the keys registered to us on chain against the keys our signer can serve, and
- alert on any difference
- Mandatory verification gate before any signer deployment
- Automated share provisioning, replacing manual steps
- Post-deployment signing check before an instance is treated as healthy
Incident 2 — Delayed validator exits
21–22 August 2026. Resolved; all affected validators have exited.
Four exit requests issued by the Validator Exit Bus Oracle were not actioned promptly by
our exit automation. The longest delay between a request being published and the
corresponding voluntary exit being submitted was 14 hours 15 minutes.
The cause was a loss of availability of an upstream endpoint, with no fallback configured.
The component failed silently, continuing to report itself healthy.
Impact
-
4 validators, longest exit delay 14h 15m
-
No slashing, no missed attestation or proposal duties, no stake at risk
-
The validators performed their consensus duties normally throughout; only the exit was delayed
What we have changed
-
Unfulfilled-exit-request alerts routed to the on-call paging rotation
-
Redundant upstream endpoints with automatic failover
-
Positive liveness monitoring of the exit-processing cycle, so a silent stall is detected
whether or not an exit is pending
Closing
Both sets of actions are tracked internally with named owners and target dates.