Failure Map
The restaking map describes four layers a deposit passes through, and the guides describe what can go wrong in each. The case files describe things that did go wrong. This page sets one against the other.
This page makes no claims of its own. Every statement of fact here is sourced on the page it links to. It exists because the answer to "which layer failed?" turned out to be the same for all three documented cases, and that is easier to see in one table than across three pages.
1. The four layers
The layers are defined on the restaking map and are not restated here. What follows is what each one is expected to fail by, and whether this site holds a documented case of it doing so.
| Layer | Expected failure | Documented case |
|---|---|---|
| 1. Base capital | Consensus penalties on the underlying stake — double-signing, downtime. See slashing risk. | None published here |
| 2. Operator infrastructure | An operator's outage, misconfiguration or key loss, charged to everyone delegated to them. | None published here |
| 3. Middleware | A service's slashing rules firing — by proof, by resolver, or by committee. See the three enforcement models. | None published here |
| 4. Receipt token | Discount to net asset value, exit friction, buffer exhaustion. See LRT depegs and exit liquidity. | Partly — the ezETH cascade ran through a receipt, though not by the receipt failing |
2. What the empty rows do not mean
They do not mean those layers are safe, and they do not mean nothing has happened in them. They mean no event in those layers has met the conditions for a case file, which are set out on the case file index and are strict on one point above all: a party involved must have published its own account.
Slashing in particular is a likely gap rather than a quiet record. Penalties have been enforceable on EigenLayer since April 2025, and an operator fault is the one failure this site describes most. An absence of published post-mortems is what you would expect from individual operators taking individual losses, because nobody in that position is obliged to write anything. Read the empty rows as a limit on the record, not as a finding.
3. Where the losses actually entered
All three documented cases entered through something attached to the stack rather than through a layer of it. None involved a slashing penalty. None involved a smart contract behaving incorrectly.
| Surface | Case | What it is |
|---|---|---|
| Cross-chain messaging | rsETH bridge, April 2026 | The route a receipt uses to exist on more than one chain. Not restaking; distribution. A single verifier, reading poisoned infrastructure. |
| Composition on top | Penpie, September 2024 | A yield layer built over the stack. Audited code, made unsafe by a later change elsewhere that removed the condition it was safe under. |
| Collateral venues | ezETH, April 2024 | Lending markets that accept receipts. An oracle priced collateral from pools that the liquidators it dispatched were selling into. |
The collateral venues appear twice. They are where the ezETH cascade happened, and they are also how the rsETH loss was converted: tokens that should not have existed were supplied as collateral and borrowed against within the hour. A receipt's acceptance elsewhere is not a separate topic from restaking risk. It is the mechanism by which restaking risk reaches people who never restaked.
4. What this changes about diligence
Our five questions ask about unbonding paths, slashing conditions, contract layers, operator dependency and the reward spread. On the evidence of these three cases, a reader answering all five carefully would still have missed every one of them. The questions interrogate the stack. The losses came from its edges.
Three questions the case files suggest adding, each of which is answerable before depositing:
- How many independent verifiers stand behind the bridge this receipt uses, and who operates the machines they read the chain through? One verifier is one compromise.
- What has been built on top of this position since it was last reviewed? An audit is a statement about particular code under particular assumptions on a particular date. A later change elsewhere can remove the assumption without touching the code.
- Where is this receipt accepted as collateral, and what prices it there? A market-price oracle on an asset with no redemption path hands the decision to the thinnest pool in the stack.
None of these is a prediction. Each is the question that the relevant case file shows would have mattered.
This page is explanatory and not a recommendation. It summarises the case files and the guides linked above and introduces no facts of its own; the sources for each are on those pages.