EIP-8333: Align Checkpoint with Epoch Boundary Block

EIPs
1

Discussion topic for EIP-8333

Update Log

  • 2026-07-06: initial draft

External Reviews

None as of 2026-07-13.

Outstanding Issues

None as of 2026-07-13.

2 Likes
2

Not against this, and it would be nice to clean this up. But two remarks:

  1. We are looking at implementing decoupled consensus (hopefully in I* subject to R&D, governance etc!) which would replace Casper FFG and make this moot. The work required should be considered in view of that.
  2. It marginally increases expected time to finality for a transaction at a time when we’re looking to reduce it. Granted not by a significant amount, but still a step the wrong way.
3 Likes
3

The problem with 2 is not the time to finality but which transactions are finalized. Part of the justification of the EIP is that the current checkpoint misleads finality. But actually after gloas, voting on the CL root for slot 64, epoch 2, finalizes every transaction included in epoch 1, and none from epoch 2.

However, with this change, the root that gets finalized is that of slot 63, and that cannot include the payload of 63, thus the transactions that are finalized are all during epoch 1 except those included in the last payload.

This may be weird for some users.

4

Thanks for engaging.

  1. […] decoupled consensus

Somehow I would expect the concept of a checkpoint (a chain at a point in time) to remain even after decoupled consensus. Interested to read more on this.

  1. […] marginally increases expected time to finality for a transaction

Yes, this should be conceded. Practically, we get one additional payload finalized in the current paradigm. The practical tradeoff with this EIP that it takes the expensive epoch transition and first-block timing off the path for voting correctly for target. And that the conceptual simplification / coherence helps with reasoning about the protocol.

the transactions that are finalized are all during epoch 1 except those included in the last payload.

I would say that this is reasonable considering payload 63 is only confirmed / processed in the next epoch, block 64. Which is to say, what you say is the final payload of an epoch is the first payload of the next epoch from a chain inclusion perspective.

5

payload 63 is only confirmed / processed in the next epoch,

To be able to finalize with 63 as target, the chain would be voting down the children. Except the attestations at 63, every other attestation will be supporting 63/full and the finalization could take this into account to finalize the full checkpoint and not just the blockroot. The change to the spec is actually minimal and we even considered adding this to 7732 originally.