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.
Watch how FCR confirms blocks in real time compared to waiting for finality.
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.
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.
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.
RPC & Infrastructure Providers
-
●
The
safeblock 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
safetag returning the last justified block.
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 Learn more ↓ | Asynchrony |
| Adversarial threshold | Unknown | 25% Learn more ↓ | 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. |
FCR relies on two assumptions. When it detects that either breaks, it falls back to finality. Under rare conditions, a briefly-confirmed block may be reorganized.
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 --enable-fast-confirmation
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
The Fast Confirmation Rule is built on rigorous research, but using it is simple. Below are answers to common questions. For anything else, reach out to fastconfirm@ethereum.org.
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? +
In most of the scenarios, FCR would just stall and eventually revert to finality. In some extreme circumstances, this could lead to a Fast Confirmed block being reorged.
Can an adversary delay my confirmation? +
An adversary controlling more than 5% of the stake can cause FCR to be delayed. The delay depends on the percentage controlled. For example, if the adversary controls 15% of the stake, it can delay Fast Confirmations by one additional slot meaning that Fast Confirmation would take two slots. If it controls 18% of the stake, by two additional slots; if it controls 20% of the stake, by three additional slots.
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 or the most recent finalized block if FCR reverted to finality. 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.
High value. Low lift. Start using Fast Confirmation Rule today.
Get in TouchGet in touch via fastconfirm@ethereum.org for questions