> For the complete documentation index, see [llms.txt](https://etherfi.gitbook.io/etherfi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://etherfi.gitbook.io/etherfi/security/security-and-risks/stress-testing.md).

# Stress Testing

eETH is a 1:1 claim on staked ETH with no protocol-level leverage, no borrowing, and no liquidation engine. That shape means the failure modes that hurt leveraged protocols (forced liquidations, liquidation cascades, funding-rate blowups) cannot happen inside eETH. The risks that do matter are operational: can the protocol meet a wave of redemptions, and does the weETH price hold its peg under stress. This page sets out how eETH behaves under severe conditions, and points to the real event where that behavior was tested.

### How eETH holds up under stress

<table><thead><tr><th width="223.001708984375">Scenario</th><th width="551.1102294921875">What happens to eETH</th><th width="153.471435546875">Status</th></tr></thead><tbody><tr><td><strong>Mass redemptions</strong></td><td>Withdrawals are sourced through Ethereum's consolidation queue, which is separately from the exit queue, so redemptions can clear in both paths efficiently.</td><td>✅ Tested</td></tr><tr><td><strong>Sharp ETH price drop</strong></td><td>eETH's claim is denominated in ETH, so a fall in ETH's dollar price changes the dollar value of the holding but not the ETH you can redeem. With no leverage and no liquidation engine, there is nothing to force-sell, so the cascade failure mode is absent by design.</td><td>✅ Zero exposure</td></tr><tr><td><strong>Secondary-market peg deviation</strong></td><td>Anyone can redeem at the internal rate, which gives arbitrageurs a reliable path to close the gap. The peg held through the Apr–May 2026 redemption wave.</td><td>✅ Tested</td></tr><tr><td><strong>Restaking slashing</strong></td><td>None of ether.fi's restaked ETH is opted in to any slashable EigenLayer service, and as policy it does not join them, so there is no restaking slashing exposure. See <a href="/pages/3Ved9CQgdmFUa1SopzdR">Slashing Risk</a>.</td><td>✅ Zero exposure</td></tr></tbody></table>

### The April–May 2026 redemption wave

In April 2026, a security incident at another liquid restaking token set off a market-wide redemption wave. Ethereum's validator exit queue is the single, rate-limited line that every staker's withdrawal has to pass through, and it backed up to about **9 days**.

Over the following 33 days, ether.fi redeemed **542,792 ETH, or 19.6% of its TVL**. This was its largest redemption event ever, and it was handled **without adding measurable delay to that shared exit queue**. It did this by sourcing the ETH through Ethereum's *consolidation* queue instead of the exit queue. The two queues are rate-limited separately, so a congested exit queue does not slow consolidations. (Full mechanism in the [ether.fi blog](https://ether.fi/blog/how-ether-fi-redeemed-20-percent-of-tvl-without-adding-to-exit-queue).)

|                                   |                                  |
| --------------------------------- | -------------------------------- |
| Window                            | Apr 18 to May 21, 2026 (33 days) |
| Withdrawal requests               | 1,977                            |
| Total redeemed                    | **542,792 ETH (19.6% of TVL)**   |
| Median time to claimable          | **4.9 days**                     |
| Longest time to claimable         | 16.7 days                        |
| Requests claimable within 17 days | **100%**                         |

How the full set of requests was served (reconstructed from on-chain data):

| Claimable within… | Share of requests |
| ----------------- | ----------------- |
| 5 days            | 50%               |
| 7 days            | 55%               |
| 17 days           | **100%**          |

For comparison, funding that much ETH through ordinary validator exits would have consumed roughly 9 days of the *entire network's* exit capacity, on top of the existing \~9-day queue. That would have nearly doubled the wait for every staker on Ethereum. Spillover avoided it entirely.

### The peg held through the same event

The same redemption wave was the hardest test the weETH peg has faced. The largest outflow in the protocol's history is exactly when a receipt token would break its peg if it were going to. It didn't.

Measured on the direct weETH/ETH price over the trailing year:

|                                    | weETH                     | wstETH |
| ---------------------------------- | ------------------------- | ------ |
| Annualized peg volatility          | **2.49%**                 | 3.73%  |
| Days more than 1% below fair value | **0%**                    | 0.27%  |
| Worst single deviation             | **−0.58%** (Apr 20, 2026) | −1.88% |

weETH's worst day of the entire year was a deviation of just **−0.58%**, and it fell *inside* the redemption window. On-chain, the market price tracked the internal redemption rate to within **0.12%**.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://etherfi.gitbook.io/etherfi/security/security-and-risks/stress-testing.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
