A reorganization occurs when consensus fork choice selects a head that is not a descendant of the prior head.
Transition process
- The consensus client finds the common ancestor under fork-choice rules.
- It ensures that the new branch has valid consensus blocks, required data, and an acceptable execution status.
- It sends the new head, safe block, and finalized block through
engine_forkchoiceUpdated. - The execution client applies the new fork-choice state and switches its canonical execution state and derived indexes to the new branch.
- Transactions removed from the old branch may return to the local pool if they remain valid and are absent from the new branch.
- Consensus networking gossips the new beacon head. After The Merge, the
execution
ethprotocol does not gossip proof-of-stake heads; execution peers obtain block data through their normal request and sync paths.
Safety boundaries
The new head cannot conflict with the finalized checkpoint. An execution
client returns -38002 for an inconsistent fork-choice state and may return
-38006 when the reorganization exceeds its local depth limit. This is an
operational failure, not permission to choose an execution head apart from
consensus.
Failure and recovery
Missing new-branch blocks trigger root or chain-data requests.
Missing blob sidecars trigger data recovery.
Missing data columns trigger custody-aware data recovery.
An execution-invalid payload makes that branch ineligible. If the Engine API update times out, the consensus client retries in event order and confirms the execution head before it starts a dependent payload build.
Design rationale
Consensus fork choice owns canonical selection. The execution client applies that selection to execution state and reports whether the chosen payload chain is valid.