ethereum · eth-bot · May 14, 2026 · May 5, 2026 · May 7, 2026 · May 7, 2026
@@ -0,0 +1,69 @@
+---
+eip: 8252
+title: Execution-Layer Reorg State Retention Window
+description: Require EL clients to retain enough state to re-execute across any reorg within the inactivity-leak-bounded non-finality window
+author: Toni Wahrstätter (@nerolation), Kevaundray Wedderburn (@kevaundray), Jacek Sieka (@arnetheduck)
+discussions-to: https://ethereum-magicians.org/t/eip-8252-execution-layer-reorg-state-retention-window/28463
+status: Draft
+type: Informational
+created: 2026-04-24
+---
+
+## Abstract
+
+Define `REORG_RETENTION_WINDOW = 262_144` blocks (8192 epochs × 32 slots, ~36.4 days) and require EL clients to keep recent state reconstructible (via snapshots, reverse state diffs, or any equivalent representation, in memory or on disk) for every canonical block within this window, so any reorg up to the inactivity-leak-bounded non-finality window can be processed locally.
+
+## Motivation
+
+EL clients have no protocol-defined floor on how far back recent state must remain reconstructible. History-expiry rules govern long-term block-history retention; state-pruning policy is left entirely to clients.
+
+To validate a post-reorg branch handed in via the engine API, an EL must execute its first block against the state of the common ancestor with the local chain. That ancestor cannot lie deeper than the chain's last finalized block, and the distance to last finalization is bounded by the CL's inactivity leak: once finality stalls, the leak quadratically penalizes non-participating validators until their share of active stake falls below `1/3` and finality resumes. A single retention floor aligned to that bound closes this gap.
+
+## Specification
+
+The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119) and [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174).
+
+`REORG_RETENTION_WINDOW = 262144` blocks.
+
+For every canonical block with number `n` in the range `head - REORG_RETENTION_WINDOW ≤ n ≤ head`, EL clients MUST be able to reconstruct that block's post-state without sync. The representation (full snapshots, reverse state diffs, or any equivalent) and its location (memory or disk) are unspecified. State older than the window MAY be discarded.
+
+This EIP does not constrain retention of block headers, bodies, or receipts; those are governed by history-expiry rules.
+
+## Rationale
+
+### Choice of constant
+
+Under post-merge inactivity-leak parameters (`INACTIVITY_SCORE_BIAS = 4`, `INACTIVITY_PENALTY_QUOTIENT_BELLATRIX = 2^24`), a continuously offline validator's effective balance evolves as `balance(N)/balance(0) ≈ exp(-N²/(2Q))`. For finality to resume from an initial offline-stake fraction `f`, the offline share must fall below `1/3`, giving `N > sqrt(2 · Q · ln(2f/(1-f)))` epochs (at 225 epochs/day):
+
+| Offline fraction `f` | Epochs to recover finality | Days  |
+| -------------------- | -------------------------- | ----- |
+| 0.50                 | ~4,822                     | ~21.4 |
+| 0.60                 | ~6,072                     | ~27.0 |
+| 2/3                  | ~6,820                     | ~30.3 |
+| 0.75                 | ~7,754                     | ~34.5 |
+
+Recovery time grows with `f` because the leak only drains offline stake while online stake is unchanged: a larger initial offline share must be shrunk by a larger factor before the online side regains a `2/3` supermajority. Since balances decay as `exp(-N²/(2Q))`, achieving a larger shrink factor requires a longer leak; the `ln(2f/(1-f))` term inside the bound diverges as `f → 1`.
+
+`8,192` epochs (`2^13`, ~36.4 days) corresponds to `ln(2f/(1-f)) = 2`, i.e. it covers leak-driven non-finality up to `f ≈ 0.787` (~79% initial offline stake); above that fraction, recovery is expected to rely on external sync rather than local state. Encoding it as `8192 × 32 = 262,144` blocks (`2^18`) gives EL clients a single block-denominated value with no dependency on finalized beacon state.
+
+### State, not block data
+
+A deep reorg is processed by rolling state back to the common ancestor with the incoming branch and re-executing forward. The new branch's blocks arrive via the engine API or P2P; the local node does not need to have stored the displaced branch's headers, bodies, or receipts. What it strictly needs is the ability to reconstruct state at the ancestor, which makes state retention the load-bearing requirement for reorg recovery. Block-data retention is a separate, network-serving concern addressed by history-expiry rules.
+
+### Reorg coverage
+
+Reorgs shallower than `REORG_RETENTION_WINDOW` can be resolved locally. Reorgs deeper than the window are out of scope for this EIP; recovery may require fresh sync from a trusted checkpoint.
+
+## Backwards Compatibility
+
+EL clients with state-pruning policies more aggressive than `REORG_RETENTION_WINDOW` must retain additional state (typically as reverse diffs) to comply.
+
+## Security Considerations
+
+### State beyond the window
+
+Reconstruction of state older than `REORG_RETENTION_WINDOW` is out of scope and served by archive nodes.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).