Lodestar

Fast Confirmation in Lodestar: Safer than Head, Faster than Finality

Ethereum operators usually choose between two familiar views of the chain: head, and finalized. Fast Confirmation fills the gap in between.

Nazar Hussain

Jul 6, 2026 • 6 min read

Ethereum operators usually choose between two familiar views of the chain:

head: the best block right now, but also the easiest to reorg.
finalized: the strongest settlement signal, but usually 12.8 minutes behind.

Fast Confirmation fills the gap in between, and gives participants a third view:

confirmed: a block that already has enough attestation support that, under normal network conditions, fork choice should stay on that branch.

This makes it useful for systems that prioritize safety and latency simultaneously, such as bridges, exchanges, custodians, and settlement systems.

It is not finality: it has no economic finality guarantee, and the signal can stall, move, or reset if its assumptions no longer hold. The value is that operators get a stronger-than-head signal much earlier than they get finality.

Diagram 1: The gap Fast Confirmation fills

Why Fast Confirmation matters

For many operational decisions, head is too optimistic and finalized is too slow.

That gap matters when you need to answer questions like:

Is this deposit safe enough to credit internally?
Is this message safe enough to relay across chains?
Is the node tracking a branch with strong enough support, or is the view still fragile?

Fast Confirmation is designed for exactly that gap.

In terms of latency, finality on Ethereum usually takes about two epochs, or roughly 12.8 minutes. Fast Confirmation is evaluated every slot, so under healthy network conditions, it can provide a stronger-than-head signal on the order of slots or minutes rather than waiting for full finality.

Diagram 2: Typical consumer policy

The core idea

The rule asks a narrow question:

Does this branch already have enough honest attestation support that, assuming bounded adversarial behaviour and a healthy network, fork choice should not move away from it?

If the answer is yes, the client marks a block on that branch as confirmed.

In practice, this means a node does not wait for full FFG finality before exposing a safer checkpoint. Instead, it uses the structure of the chain, observed justified checkpoints, unrealized justification snapshots, and attestation support to advance a confirmedRoot.

Fast Confirmation is based on the Ethereum consensus-specs work merged in consensus-specs PR #4747.

It is also not an isolated Lodestar-only experiment. Nimbus has released Fast Confirmation work, Lighthouse has an implementation PR in flight, and fastconfirm.it tracks the broader ecosystem rollout.

How it works

At a high level, Fast Confirmation runs at the start of each slot after past attestations have been applied. It checks whether the current confirmed root is still safe, falls back toward finalized if it is not, and otherwise tries to advance to the latest descendant that still satisfies the rule.

The exact algorithm is specified in the consensus specs, including the observed-justified restart, one-confirmed checks, and epoch-boundary guards. The important integration point is simpler: consumers should treat confirmed as a moving safety signal that can advance, stall, or reset depending on the chain view.

Diagram 3: Slot-start pipeline

What "safe under normal network conditions" means

This phrase is easy to over-analyze, so it is worth being precise.

"Normal network conditions" means:

The network is reasonably synchronous.
Honest validators see blocks and attestations on time.
There is no major partition or severe asymmetric propagation.

Separately, the safety calculation uses CONFIRMATION_BYZANTINE_THRESHOLD, which defaults to 25 in Lodestar.

In simple terms, that threshold budgets for adversarial stake in the rule's safety calculation. It should not be confused with network timing: delayed or missing attestations are part of the synchrony/liveness assumption, not the same thing as adversarial stake.

Fast Confirmation should only advance when the block still has enough support under the adversarial threshold, and the network is timely enough for honest attestations to be observed.

What can make the signal stall or reset

Fast Confirmation is intentionally conservative. When the assumptions behind the rule no longer hold, the signal may stop advancing, fall back toward finalized, or, in extreme cases, expose reorg risk.

Typical causes are:

A network partition.
Severe propagation delays.
Uneven or delayed honest attestations.
Adversarial equivocations or coordinated competing votes.
Epoch-boundary re-confirmation failure.

Diagram 4: When Fast Confirmation can stall or reset

The best public replay data so far is the EthPandaOps FCR simulator. In its v0.2.0 dataset, a 12-month replay across four consensus-layer implementations reported zero false confirmations across 5.15 million slot evaluations, while roughly 96 out of every 100 comparable mainnet slots would have been fast-confirmed within 13 seconds. That is useful evidence, not a replacement for understanding the assumptions.

Why epoch boundaries matter

Epoch boundaries are where the rule needs extra care. The implementation snapshots the strongest unrealized justified checkpoint at the last slot of an epoch, then rotates the observed justified view at the first slot of the next epoch.

The consumer-facing takeaway is stability: confirmation decisions use a frozen previous-epoch view instead of recomputing from a moving local fork-choice view at rotation time. That reduces the chance of confirmed-root decisions flapping just because the local view shifts around an epoch boundary.

Diagram 5: Snapshot now, rotate later

A note before enabling

Two caveats are worth pointing out before turning Fast Confirmation on in a real deployment.

It is a new feature. The spec has been thoroughly tested, but the implementation is young. Fast Confirmation is already good at predicting the canonical chain correctly, but there are still some kinks being worked out. Further performance and correctness improvements are on the way in upcoming releases. Apply rigour in testing before relying on the signal for any substantial economic security decision.

It is performance-intensive. In its current form, Fast Confirmation is a fairly heavy workload. If you enable it on a node that runs mainnet validators, keep a close eye on validator effectiveness and CPU headroom, and be ready to disable the flag if you see degradation. As Lodestar and other clients optimize for real network conditions, the overhead should shrink; the guidance is vigilance, not prohibition.

How to enable Fast Confirmation in Lodestar

Fast Confirmation is currently experimental and disabled by default.

To enable Fast Confirmation:

lodestar beacon --chain.fastConfirmation

Operational notes:

The rule uses the chain config value CONFIRMATION_BYZANTINE_THRESHOLD
The default threshold is 25
Custom deployments can override it with
--params.CONFIRMATION_BYZANTINE_THRESHOLD
The feature is intended as an operator-facing safety signal, not an application-level finality replacement.

The beacon node also exposes the current state through a Lodestar-namespaced REST endpoint. Note that Lodestar's non-standard routes are not enabled by default; operators need to opt in by adding lodestar to the enabled REST namespaces (for example --rest.namespace lodestar) alongside the default beacon namespaces.

GET /eth/v1/lodestar/fast_confirmation

That endpoint returns:

The current confirmed block
The current head
The current justifiedCheckpoint
The current finalizedCheckpoint

For downstream systems that prefer subscribing rather than polling, the beacon node also emits the standardized fast_confirmation SSE event on /eth/v1/events, matching beacon-APIs#598.

This is the cross-client integration path and is preferred over the Lodestar-namespaced polling endpoint when tracking confirmed-block changes over time.

In closing

Fast Confirmation does not change Ethereum finality rules. It also does not require any custom Lodestar API to consume: alongside the Lodestar-namespaced REST endpoint, Lodestar emits the standardized fast_confirmation SSE event (beacon-APIs#598), delivered via lodestar PR #9439, so downstream systems can track confirmed-block changes across clients without polling.

For bridges, exchanges, custodians, and settlement systems, the practical policy is simple: use confirmed as a faster internal safety signal, and keep finalized for the highest-value or highest-risk actions.