Fast Confirmation Rule

1slot

Single-slot confirmation
for Ethereum.

Confirm transactions in ~13 seconds — down from ~13 minutes. No hard fork required.

Get in Touch Use Cases
Scroll to learn more
~0%
Speed Improvement
~0s
Confirmation Time
0
Hard Forks Required

Fast and Secure confirmations for users.

FCR reduces L1 deposit time to a single slot — approximately 13 seconds. That's a ~98% reduction compared to waiting for finality.

FCR relies on counting attestations and is proven safe under normal network conditions. Waiting for a fixed number of blocks is not.

No hard fork. No devnet. FCR is a consensus client feature. Enable it with a configuration flag and query a single API endpoint.

See It in Action

Watch how FCR confirms blocks in real time compared to waiting for finality.

Use Cases

From exchanges to rollups, any application waiting on Ethereum confirmations can benefit from FCR. Here's how different players in the ecosystem can put single-slot confirmation to work.

Exchanges

  • ● Don't leave your users worrying. Credit deposits within seconds.
  • ● Deepen order book liquidity. Minimize time assets are idle while waiting to be confirmed.
  • ● Proven safe under normal conditions — stronger than waiting for a fixed number of blocks.
One pager info

Cross-Chain Bridges

  • ● Manage risk with provable security. Under normal network conditions, reorgs are no concern with FCR.
  • ● Reduce capital lockup for cross-chain transfers.
One pager info

L2s

  • ● Confirm deposits from L1 within seconds.
  • ● Tap into Ethereum's liquidity within seconds.
  • ● Automatically fall back to a safe head block if there are too few attestations.
One pager info

RPC & Infrastructure Providers

  • ● The safe block tag will return the last fast-confirmed block. RPCs automatically support FCR — no implementation required.
  • ● Be aware the change may impact customers currently relying on the safe tag returning the last justified block.
One pager info

Trade-offs

FCR sits between k-deep confirmation and full finality — offering deterministic guarantees at near-instant speed. The right choice depends on your security requirements and latency tolerance.

k-deep FCR Finality
Communication model Synchrony Synchrony See in action ↓ Asynchrony
Adversarial threshold Unknown 25% See in action ↓ 33%
Economic security ✗ ✗ ✓
Latency k × 12s ~13 seconds ~13 minutes
Deterministic guarantee ✗ ✓ ✓
Confidence model — Deterministic under network assumptions Unconditional permanence
Best suited for — L2 deposits, exchange deposits, bridge transfers High-value settlements, irreversible operations
Failure behavior — Falls back to finalized block Stalls until supermajority restored
Summary Waits for a fixed number of blocks with no formal safety guarantee. Deterministic confirmation in ~13 seconds under normal network conditions — falling back to finality if conditions deteriorate. Unconditional permanence backed by slashable stake, but takes ~13 minutes.

Assumptions

FCR relies on two assumptions. When either breaks, it falls back to finality. Under rare conditions, a briefly-confirmed block may be reorganized.

ASSUMPTION 01

Communication model (synchrony)

FCR requires attestations to arrive within the synchrony bound. If the network becomes asynchronous, FCR falls back to the finalized block. In rare cases, brief asynchrony may go undetected — a confirmed block could be reorganized before the fallback triggers.

ASSUMPTION 02

Adversarial threshold (<25%)

FCR requires that at least 75% of total stake is honest and participating. If adversarial stake exceeds 25%, FCR may lose liveness (stalling confirmations) or, in adversarial conditions combined with network issues, safety.

High value.
Low lift.

Enable a configuration flag on your consensus client. Query the safe block via JSON-RPC — no new endpoints needed. No hard fork. No devnet. No protocol change.

STEP 01

Enable the flag

Add the flag to your consensus client startup command.

Consensus Client
lighthouse bn --fast-confirmation-rule
STEP 02

Query status

Use the existing JSON-RPC API to get the most recent confirmed block. The safe tag will return the last fast-confirmed block.

JSON-RPC API
eth_getBlockByNumber("safe")

Frequently asked

How much faster is FCR? +
Under normal network conditions, FCR confirms a block in a single slot — approximately 13 seconds. That's a ~98% reduction compared to the ~13 minutes it currently takes for finality.
Does FCR require a hard fork? +
No. FCR is a client-side feature implemented in consensus clients. No protocol change, no devnet, and no hard fork are required. Nodes run the rule locally.
Is FCR as secure as finality? +
No — they offer different guarantees. Finality (Casper FFG) is backed by slashable stake: reverting a finalized block requires burning at least 33% of all staked ETH. FCR provides no economic security — there is nothing at stake if the rule is violated. Instead, FCR offers a deterministic guarantee: under network synchrony and with less than 25% adversarial stake, a confirmed block will be finalized. It is a complementary tool optimized for speed, not a replacement for finality.
What happens if network conditions are poor? +
There are two distinct failure modes. Liveness failure (most common): if attestations are delayed or too few validators participate, FCR simply stalls — it stops confirming new blocks and resets to the last finalized block. No incorrect confirmation is issued. Safety failure (extreme): if an adversary controls >50% of active validators, a confirmed block could theoretically be reorged. This requires exceptional circumstances far beyond normal network disruption.
Can an adversary delay my confirmation? +
An adversary controlling more than 25% of validators can cause FCR to stall — this is a liveness failure, not a safety failure. Your confirmation is delayed, but no incorrect confirmation is ever issued. To actually reorg a confirmed block would require >50% of active validators. There is no slashing penalty for liveness failures, since stalling does not violate any protocol rule.
Does FCR affect L2 security? +
FCR does not weaken L2 security. L2s that read the safe head will confirm L1 deposits faster, but they will never act on an invalid block. In the worst case — an adversary with >25% stake — FCR stalls and the L2 falls back to the finalized head. If an L1 reorg were to occur under extreme conditions, the L2 would reorg with it, consistent with its existing security model.
What are slots and epochs? +
A slot is a 12-second window in which a validator can propose a block. An epoch is a group of 32 slots (~6.4 minutes). Finality typically requires 2 epochs (~13 minutes). FCR confirms within a single slot (~13 seconds, including attestation propagation time).
How do I adopt FCR? +
Enable the fast confirmation flag on your consensus client, then query eth_getBlockByNumber("safe") via JSON-RPC. The safe tag will return the last fast-confirmed block. No new API endpoints are needed.
What does the API return if something goes wrong? +
The safe tag always returns the last fast-confirmed block. If FCR stalls (e.g., due to poor network conditions), it simply stops advancing — the tag continues to return the most recent block that was confirmed. There is no error state; the response is always a valid block.
Which clients support FCR? +
Standardized specifications are being integrated into the Ethereum consensus specs (PR #4747). Lodestar is furthest along in implementation. Support is also actively being developed in Lighthouse, Prysm, and Teku.

Ready to get started?

High value. Low lift. Start using Fast Confirmation Rule today.

Get in Touch

Get in touch via fastconfirm@ethereum.org for questions