Enabling FastConfirm can change every customer's safe read before they change a line of code. A deposit service may start accepting newer blocks while a settlement service still expects checkpoint-based confirmation.
Audit those callers before changing your consensus client. Then test the new behavior on an isolated node pair, measure block lag, and verify fallback. This checklist covers that rollout. The Fast Confirmation Rule overview explains the protocol and its security assumptions.
Decide which callers can use faster confirmation
The Fast Confirmation Rule, or FCR, lets a consensus client report a newer safe block through the execution client's existing JSON-RPC endpoint. It requires no new RPC method or hard fork.
FCR provides confirmation under network and participation assumptions. It does not provide the economic security of finalized blocks. The FastConfirm project describes confirmation around 13 seconds under normal conditions, with possible stalls or fallback during poor conditions.
Classify callers by what happens if their provisional block reorganizes:
| Caller | Rollout decision |
|---|---|
| Deposit display with a pending status | Test faster updates and preserve the finality distinction |
| Provisional credit with enforced withdrawal restrictions | Evaluate whether the application can reverse the credit |
| Indexer that can roll back provisional records | Test rollback and restart behavior before migration |
| Withdrawal or bridge release that cannot reverse | Retain the application's finality requirement |
| L2 deposit watcher | Check the rollup's derivation and reorg rules before changing its input |
A reversible database entry does not guarantee a reversible financial action. If a customer can withdraw provisional credit, your system may already have committed funds.
For each caller, record its current tag, confirmation policy, and rollback behavior. Notify owners who already use safe; they can inherit the change without an application deployment.
Check the installed consensus client
Verify support in your exact binary and release. Lighthouse documents --enable-fast-confirmation, which feeds its confirmed root into the execution layer's safe block hash. Its documentation describes confirmation within 1 to 2 slots of the head. See the Lighthouse flag reference.
Do not copy flags between clients or infer installed support from a project roadmap. Check the binary's help output, release notes, and configuration. Keep the first test pair outside the customer load-balancer pool.
Compare latest, safe, and finalized over RPC
Set ETH_EL_RPC to the test execution endpoint. Run this probe with curl and jq:
for TAG in latest safe finalized; do
curl --fail-with-body -sS "$ETH_EL_RPC" \
-H 'Content-Type: application/json' \
-d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"eth_getBlockByNumber\",\"params\":[\"$TAG\",false]}" \
| jq -e --arg tag "$TAG" '
if .error then error(.error.message)
elif .result == null then error("No block returned")
else {tag:$tag, number:.result.number,
hash:.result.hash, timestamp:.result.timestamp}
end'
done
Repeat the probe and save responses with local observation times. Convert hexadecimal numbers and timestamps before calculating differences.
Check these properties:
- The safe head advances more frequently when FCR operates under healthy conditions.
- Safe blocks remain ancestors of the latest chain you observe. Check hashes and ancestry; block-number ordering alone cannot establish this.
- The gap from
latesttosafedecreases. The gap fromsafetofinalizedcan increase because finality has not accelerated. - A stalled safe head triggers a freshness alert even when the RPC request succeeds.
The three requests are separate observations. A new block can arrive between them. Repeat inconsistent samples against known block hashes before declaring a fork or ordering failure.
A valid safe response does not identify the confirmation algorithm behind it. Check the consensus-client configuration before describing an endpoint as FastConfirm-enabled.
Do not use 13 seconds as a service guarantee. Establish a baseline from your client version and deployment. Track missed slots, participation, and consensus-client health alongside RPC results.
Test fallback and mixed client pools
A valid block response can still be too old for your application. Record both time since the last safe-head change and its lag behind latest.
| Observation | What to investigate | Application response |
|---|---|---|
safe stops advancing while latest advances | Consensus-client health, participation, and confirmation state | Pause actions that exceed their freshness limit |
safe repeatedly equals finalized | Disabled FCR, fallback, or insufficient observations | Show the longer confirmation delay |
| Nodes return different safe heads | Client versions, configuration, and observation timing | Keep incompatible configurations in separate pools |
| A previously accepted safe hash leaves the chain | A provisional reorg | Roll back dependent provisional records |
| Finalized head also stops advancing | A broader consensus or node problem | Keep the settlement policy intact |
Rehearse rollback with recorded or simulated responses. Test a stagnant safe head, a fallback to finality, and a changed provisional hash. Confirm that retries do not issue duplicate credits.
Check caches separately. A cache can continue serving an old safe response after the node advances. Record the upstream observation time so application monitors can distinguish cached data from a fresh read.
Roll out with an explicit rollback policy
Replay one representative customer workload against the test endpoint. Compare its accepted blocks, credits, and alerts with the existing configuration.
Before expanding the pool, confirm that:
- Each caller has an owner and a documented confirmation policy.
- Provisional writes can be reversed without duplicating later work.
- Monitoring detects stale
saferesponses and fallback. - Settlement callers retain their required finality checks.
- Operators can restore the previous configuration and reconcile provisional state.
Changing the flag back cannot reverse actions customers already took. Include that reconciliation step in the rollout plan.
Use the Ethereum RPC documentation for method details. Contact the Dwellir team to confirm the client behavior behind your endpoint before migrating callers.
