Summary

“Finalized” in Ethereum means something precise: a block has been voted on by ≥⅔ of the active validator set in two consecutive epochs, making it cryptographically irreversible without slashing ≥⅔ of all stake. But “finalized” has a subtle composition problem in the Gloas/ePBS world: the beacon block and its execution payload are separate objects, and a finalized beacon block does not guarantee the execution payload is available. This distinction matters enormously for bridges, L2s, and applications using the Engine API safe tag.

What Finality Means in Gasper

Casper FFG (the finality gadget in Gasper) achieves economic finality:

  1. Every epoch (~6.4 minutes), validators vote on a checkpoint (the last block in the epoch).
  2. If ≥⅔ of all validators vote for checkpoint B with checkpoint A as its parent in two consecutive epochs, B is justified.
  3. When the next checkpoint C justifies B, A is finalized.

Properties of finalized blocks:

  • Cannot be reverted without ≥⅔ of stake being slashed (the slashed validators lose their entire stake)
  • Reverting would require >$100B in coordinated slashing (at current stake values)
  • Effectively permanent

Timing:

  • 1 epoch = 32 slots = ~6.4 minutes
  • 2 epochs needed for finality = ~12.8 minutes from block production to finality
  • In practice: a block produced at slot N is finalized at approximately slot N+64 (2 epochs later)

LMD-GHOST and Probabilistic Confirmation

Before finality, blocks are “confirmed” probabilistically by LMD-GHOST (Latest Message-Driven GHOST):

  • Each validator’s latest attestation acts as a “vote” for the chain containing that block
  • The chain with the most stake-weighted attestations is the “head”
  • A block deep in the chain with many attestations is very likely to be canonical
  • But it’s not guaranteed until finalized

The Fast Confirmation Rule (FCR) formalizes this: a block with sufficient attestation dominance can be treated as “confirmed” with high confidence (>99.9%) within ~1 slot.

The Gloas Divergence Problem

Gloas (the upcoming consensus architecture for ePBS) separates beacon blocks from execution payloads. This creates a critical subtlety:

Before ePBS (Today)

Beacon block = “capsule” containing the execution payload.

  • A finalized beacon block → the execution payload is embedded and also finalized.
  • No divergence possible.

After ePBS / Gloas

Beacon block = commitment to a payload hash (payload_hash), but not the payload itself.

  • The builder reveals the payload separately (later in the slot, or potentially delayed).
  • A beacon block can be finalized (≥⅔ voted on the beacon block containing the payload hash) while the actual payload is not yet available (the builder hasn’t revealed it yet, or the reveal didn’t propagate).

Scenario:

  1. Block N’s beacon block is finalized at epoch N+2.
  2. Builder for block N went offline before revealing the payload.
  3. Applications see “block N is finalized” → credit user deposits.
  4. But the payload with those transactions is not actually available → state is inconsistent.

This is not a theoretical edge case — it’s a real risk in any system that:

  • Accepts user deposits based on “finalized” status
  • Uses the Engine API safe tag to determine when to credit transactions

Engine API: safe, finalized, and the Update Needed

The Engine API defines three chain heads the execution client exposes to the consensus client:

  • latest: most recent block (may be reorged)
  • safe: a block unlikely to be reorged (currently: last justified checkpoint)
  • finalized: a block that is economically finalized

Current problem: safe = last justified checkpoint. Under Gloas, this needs to be updated to mean “beacon block has sufficient attestation weight AND execution payload is available.”

Proposed update:

  • beacon_safe: beacon block is finalized/justified (existing)
  • payload_safe: beacon block is finalized AND execution payload is available (new)
  • Applications should use payload_safe for anything that depends on transaction content

Who needs to update:

  • Bridge operators relying on safe for deposit crediting
  • L2 sequencers using safe for L1→L2 message confirmation
  • DeFi protocols checking finality for oracle updates
  • Wallets displaying “confirmed” status

Variable Payload Deadline Analysis

A related question: if the payload reveal deadline is flexible (EIP-7976: “reserved execution”), how much does it help?

Analysis: only ~6% improvement in worst-case slot timing from a variable payload deadline.

Why so small:

  • The bottleneck is the attestation phase, not the payload reveal deadline
  • Most of the 12 seconds are already used for attestation collection and aggregation
  • Flexible payload deadline helps only in edge cases where the deadline is the binding constraint
  • The compressed vs. uncompressed payload size issue further limits gains

This analysis informed the decision not to prioritize EIP-7976, instead focusing on BALs (parallel execution) and ePBS for performance improvements.

Finality Edge Cases

Inactivity Leak

If finality is interrupted (e.g., >⅓ of validators go offline), Casper FFG stops finalizing. The inactivity leak activates:

  • Non-participating validators lose stake gradually (~0.005 ETH/day initially, growing)
  • As their stake decreases, their share of total stake falls
  • Eventually, the remaining active validators have ≥⅔ of total stake and finality resumes
  • Self-healing: the network recovers without human intervention

Finality Stalls (Rational Attack)

Unlike the above (accidental outage), a rational finality stall is a deliberate attack:

  • A coalition deliberately withholds FFG votes
  • The chain keeps producing blocks (LMD-GHOST continues)
  • But no new checkpoints are finalized
  • Applications waiting for finality are indefinitely delayed
  • Estimated cost: ~4.61 ETH in bribery for a short stall

Applications that depend on finality timing are vulnerable. Applications using FCR (attestation-weight-based confirmation) are immune.

Beacon Block vs. Payload Availability (Detailed Gloas Case)

From Potuz’s Gloas Range Sync analysis (Apr 2026):

Scenario: Node offline for 5 days, restarts during inactivity leak
- Last synced block: slot S
- Finalized checkpoint: slot F (4 days after S)
- Current slot: C

Question: Can the node sync the finalized range S→F 
without downloading execution payloads?

Answer: Unclear under Gloas.
- CL state transition can be done from beacon blocks alone (no payloads)
- But if node doesn't download payloads from S→F, and then receives a 
  new payload at C, the EL returns SYNCING (missing parent chain)
- EL must then independently sync payloads from S to F
- Double bandwidth (CL requests payloads, then EL requests them again)?
- Or trust that EL will sync correctly on its own?

This low-level question — can an honest node be tricked into thinking an invalid finalized block is valid? — is unresolved for the Gloas architecture.

Key Sources

  • What is Finalized in Ethereum (Potuz, Apr 2026) — Gloas syncing; beacon block vs. payload availability; Engine API implications
  • Rational Finality Stalls (2026) — finality stall attacks; 4.61 ETH bribery cost
  • Why a Variable Payload Deadline Only Helps by ~6% (2026) — EIP-7976 analysis; reserved execution math