Ethereum's safe block tag and Fast Confirmation Rule: what RPC apps should change

If your app already calls eth_getBlockByNumber("safe"), the meaning of what it returns is about to change.

Many Ethereum nodes currently return the last justified checkpoint for safe. With the Fast Confirmation Rule, or FCR, the same tag can return the last fast-confirmed block instead.

FCR can confirm a block in about 13 seconds under normal network conditions. Casper FFG finality takes about 13 minutes. FCR depends on network and validator assumptions, so applications must decide whether it provides enough assurance for each operation.

The change requires support in the consensus client, but no hard fork or new JSON-RPC method. Applications that already use safe need to check how faster updates affect their confirmation policy, caches, and alerts.

What changes for safe

Ethereum JSON-RPC lets you select a block by its confirmation status:

FCR changes how soon safe can advance. It does not change finalized or the economic security that finality provides. The blockchain finality explainer explains that distinction.

The FCR project describes the client rollout. Its specification is being integrated through consensus-specs PR #4747. Lodestar is furthest along; Lighthouse, Prysm, and Teku support is in development. Check the release you run before enabling it.

For RPC providers, the main concern is existing customer code. A caller that expects safe to update at checkpoint intervals may behave differently when it updates every slot.

Confirmation time

Security trade-offs

Waiting for a fixed number of blocks, using FCR, and waiting for finality provide different guarantees. Choose based on whether your application can reverse an operation after a reorg.

Assumptions and failure behavior

FCR relies on two conditions:

1. Attestations reach honest validators by the end of the slot in which they are sent. This is the network synchrony assumption.
2. Less than 25% of stake is adversarial, with at least 75% honest and participating.

When these conditions fail, FCR can stall or fall back to the finalized block. In some extreme cases, a briefly confirmed block can still be reorganized. See what is a chain reorg for how applications are affected.

The FCR FAQ also explains delays and fallback behavior:

• An adversary controlling more than 5% of stake can delay confirmation by additional slots.
• L2s following safe can recognize deposits sooner. If FCR stalls, they can fall back to the finalized block.
• A stalled safe tag continues to return a valid block. It may stop advancing or return the finalized block; there is no special RPC error for this condition.

If your application already uses safe

Before enabling FCR on customer-facing nodes:

1. Find callers of eth_getBlockByNumber, getBlock("safe"), and SDK methods that accept a safe block tag. Include deposit services, bridge watchers, L2 readers, indexers, and alerts.
2. Check which operations must wait for finalized. Keep payouts, mints against escrow, and other irreversible operations on that policy unless you explicitly accept the FCR assumptions.
3. Review polling intervals, cache lifetimes, rate limits, and block-lag alerts. FCR can update safe more often than the justified checkpoint did.
4. Check whether your consensus-client release supports FCR and which flag enables it.
5. Enable it on a canary node pair. Compare block hashes and lag for safe, latest, and finalized before enabling it across the fleet.
6. Tell customers when the behavior will change. Explain that safe may update about every 13 seconds after FCR is enabled, subject to its assumptions.

If your application does not use safe yet

If you wait for a fixed number of blocks or full finality for every deposit, consider whether FCR meets your confirmation requirements. It may reduce the wait for provisional credit or L2 deposit recognition.

For an application on Ethereum, you can use:

• latest for display and non-critical reads.
• FCR-backed safe for provisional deposit credit when your application can tolerate its assumptions and possible reorgs.
• finalized for settlement you cannot reverse.

Document which tag each operation uses alongside your Ethereum RPC integration. Faster confirmation should not silently change your settlement policy.

Enable and query

The FCR site gives this Lighthouse example. Confirm that your installed release supports the flag before using it.

# Enable FCR on a supported consensus client.
lighthouse bn --enable-fast-confirmation

# Query the execution client's existing JSON-RPC endpoint.
curl -s -X POST "$ETH_EL_RPC" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_getBlockByNumber",
    "params": ["safe", false]
  }'

Query "finalized" on the same endpoint and compare the returned block numbers and hashes over time. If safe does not advance, check client support, configuration, and logs. An unchanged response can reflect either a configuration issue or stalled confirmation.

Create a free Dwellir account for Ethereum RPC, or contact the team for help with your deployment. Protocol questions can go to fastconfirm@ethereum.org.