Incident Case Files
Dated accounts of documented failures in restaking and liquid restaking, each written from primary sources and each stating plainly what the sources do not agree on.
Why these exist. The guides describe failure modes in the abstract: what slashing can do, how an exit queue behaves, where contract layers stack up. A case file does the opposite. It takes one event that actually happened, reconstructs the sequence from what the parties involved published, and records which parts remain contested.
Our editorial method admits numbers only when they are tied to specific, publicly documented occurrences. These pages are where that rule does the most work — and where it is easiest to check, because every figure carries the source it came from.
What gets a case file
Four conditions, all of which must hold:
- The parties published. At least one organisation directly involved has put out its own account. Press coverage alone is not enough to open a file.
- The mechanism is legible. It is possible to say what failed and in what order, rather than only how much was lost.
- It teaches something structural. The event has to illustrate a durable property of these systems, not a one-off operational slip.
- The disagreements can be shown. Where accounts conflict, both are reproduced. A file is not opened if doing that would mean inventing a resolution.
Naming a protocol in a case file records a documented event. It is not an allegation of wrongdoing, it is not a safety assessment, and it is not a judgement between parties who dispute what happened. Where they disagree, the disagreement is the finding.
Case files
2026
-
116,500 rsETH left a bridge escrow against a cross-chain message for a burn that never happened. Every smart contract in the path behaved exactly as written; what failed was a single-verifier trust setting and the machines that verifier read the chain through.
2024
-
A reward function with no reentrancy guard sat in production for a year without being a vulnerability. It became one when a change elsewhere made pool registration permissionless — and the audit of that change excluded the vulnerable contract, because that contract had not changed.
-
146 liquidations in twenty-three minutes, priced by an oracle reading pools that the liquidators were selling into. The receipt token had no redemption path yet, so no redemption value existed for a safer oracle to read. No component failed.
Three files are published so far. The conditions above are deliberately strict, and several widely-reported restaking losses do not meet them — usually because no party involved published an account, so every figure in circulation traces back to secondary reporting that disagrees with itself. Those are left out rather than written up with the uncertainty hidden.
Read together, they say something the guides cannot say as sharply. In none of the three did a smart contract misbehave. Two are about the limits of an audit: the rsETH file shows what sits outside its perimeter, in configuration and infrastructure, and the Penpie file shows what sits behind it, in an assumption that stopped holding while the code never changed. The third does not involve a defect at all — every system worked as designed, and the loss came from what the design was reading.
Related reading
The failure map sets these files against the four layers of the restaking map, and shows that none of the three entered through a layer of the stack itself. The guides cover the same failure modes as mechanisms rather than events; slashing risk, exit liquidity and buffer and exit lessons are the closest. Corrections to these pages are recorded on the changelog.