EIP-8252 Execution Layer Reorg State Retention Period (Execution-Layer Reorg State Retention Window)
No call decision · Networking & nodes · EIP status Draft · created 2026-04-24
An informational proposal that requires execution layer clients to keep enough data to rebuild the state of every block from the last 262,144 blocks (about 36.4 days). The goal is to handle a deep chain reorg without syncing from scratch.
Why it is needed
An Ethereum node is split into an execution layer (EL) and a consensus layer (CL). The execution layer actually executes transactions and holds state such as account balances. Today, however, there is no protocol-level minimum for how long the execution layer must keep past state. Old block data is covered by the history expiry rules, but when to delete state is left to each client. A problem arises when a reorg occurs, in which the chain a node was following switches to a different branch. To validate the new branch, the node must re-execute from the state at the point where the two branches diverged. If that state has already been deleted, the node has to sync again from the beginning. The divergence point cannot be deeper than the last finalized block. The length of time finality can stall is capped by the consensus layer's inactivity leak. This proposal closes the gap by setting a single retention period matched to that cap.
What changes
Today
- There is no protocol standard for how long execution layer clients keep past state
- State pruning policy differs between clients
- On a deep reorg, the state at the divergence point may be missing and the node may have to sync from scratch
After EIP-8252
- Every client must be able to restore the state of the most recent 262,144 blocks (about 36.4 days)
- Clients choose the storage method (snapshots, reverse diffs, memory, disk)
- A node handles a reorg within this period on its own
- A reorg deeper than the period is out of scope, and the node may sync again from a trusted checkpoint
Who is affected
- Client teams: A client that prunes state more aggressively than this period must keep additional state, for example as reverse diffs.
- Node operators: Clients that previously pruned aggressively will store more state. In return, they recover from deep reorgs within the period without resyncing.
- Validators: When finality is restored after a long stall, a node can validate the new branch using only its local state.
- Archive nodes: State older than the period continues to be served by archive nodes, as it is today.
In depth
Retention period constant and requirements
REORG_RETENTION_WINDOW = 262144 blocks. This is 8192 epochs × 32 slots, which corresponds to about 36.4 days. For every canonical block whose block number n is in the range head - REORG_RETENTION_WINDOW ≤ n ≤ head, an EL client MUST be able to reconstruct that block's post-state without syncing. Full snapshots, reverse state diffs and any other equivalent representation are all allowed, and it does not matter whether they are kept in memory or on disk. State older than the period MAY be discarded. Retention of block headers, bodies and receipts is not covered by this proposal and follows the history expiry rules.
Why state and not block data
A deep reorg is handled by rolling the state back to the common ancestor and then re-executing the new branch forward. The blocks of the new branch arrive through the Engine API or P2P, so the local node does not need to store the headers, bodies or receipts of the branch that was displaced. The ability to reconstruct the state at the ancestor is essential. That is why state retention is the core requirement for reorg recovery. Retention of block data is a separate problem, that of serving data to the network, and it is covered by the history expiry rules.
Basis for the constant: the inactivity leak formula
After the Merge, the inactivity leak parameters are INACTIVITY_SCORE_BIAS = 4 and INACTIVITY_PENALTY_QUOTIENT_BELLATRIX = 2^24. The effective balance of a validator that stays offline shrinks as balance(N)/balance(0) ≈ exp(-N²/(2Q)). If the initially offline stake fraction is f, finality returns only when the offline share falls below 1/3. The number of epochs required is N > sqrt(2 · Q · ln(2f/(1-f))) (based on 225 epochs per day). According to the source table, f = 0.50 takes about 4,822 epochs (about 21.4 days), 0.60 takes about 6,072 epochs (about 27.0 days), 2/3 takes about 6,820 epochs (about 30.3 days), and 0.75 takes about 7,754 epochs (about 34.5 days). The leak cuts only the offline stake and leaves the online stake untouched, so the larger the initial offline share, the more the offline side must shrink and the longer it takes for the online side to regain a 2/3 supermajority. The ln(2f/(1-f)) term diverges as f approaches 1.
What 8192 epochs covers
8192 epochs (2^13, about 36.4 days) corresponds to ln(2f/(1-f)) = 2 and covers the non-finality period caused by the leak up to an initially offline stake of f ≈ 0.787 (about 79%). At larger fractions, clients are expected to rely on external sync instead of local state. Expressing this value as 8192 × 32 = 262,144 blocks (2^18) means an EL client only needs to look at a single per-block value, without depending on the finalized beacon state.
Reorg coverage and state outside the period
Reorgs shallower than REORG_RETENTION_WINDOW are resolved locally. A reorg deeper than the period is outside the scope of this proposal, and recovery may require syncing again from a trusted checkpoint. The Security Considerations section also states that reconstructing state older than the period is out of scope and is served by archive nodes. In other words, this proposal sets only the minimum state needed for reorg recovery and leaves the existing division of roles for serving other past state unchanged.
Backward compatibility
An EL client that pruned state more aggressively than REORG_RETENTION_WINDOW must keep additional state to follow this proposal. The source says this will usually take the form of reverse diffs. The retention policy for block headers, bodies and receipts is not affected by this proposal and continues to follow the history expiry rules. The proposal type was submitted as Informational.
Current status and call discussion
The source status is Draft. The constant value, the requirement level (MUST) and the scope can all still change. The authors are Toni Wahrstätter, Kevaundray Wedderburn and Jacek Sieka, it was created on 2026-04-24, and discussion continues on the Ethereum Magicians forum. In the core developer calls it was discussed at 09.07 ACDT #95 and 10.19 ACDT #101, but no decision was made either time. No decision has been made yet to include it in any particular fork.