Summary

The Fast Confirmation Rule (FCR) is a proposal that provides high-confidence transaction confirmation within approximately 13 seconds (one slot), reducing exchange deposit wait times by 80–98%. It operates above the existing consensus layer, requiring no protocol changes, by identifying conditions under which a block is effectively irreversible without waiting for epoch finality (~12.8 minutes). The main limitation is a <25% adversarial stake assumption.

Problem

Ethereum’s full finality takes ~12.8 minutes (2 epochs). Exchanges and bridges that want strong security must wait this long before crediting deposits or releases. In practice:

  • Most exchanges wait 30–65 blocks (~6–13 minutes).
  • Gnosis Bridge: 8 blocks, Circle CCTP: 65 blocks, LayerZero: 15 blocks.
  • L1→L2 bridges: deposit times of 10–20 minutes are common.

This creates a terrible user experience for time-sensitive applications.

FCR Mechanism

The FCR fires when two conditions are both satisfied:

1. Dominance Check

The block’s attestation weight must dominate relative to competing blocks at the same height. Specifically:

weight(block) / total_attesting_stake > dominance_threshold

The block must have received attestations from a supermajority of the active validator set, with no competing fork having meaningful attestation weight. This ensures no honest validator could later switch to a competing block without equivocating.

2. Robustness Check

The network must be in a “robust” state — recent slots must not have shown evidence of high reorg risk (missed slots, equivocations, anomalous attestation patterns). This is a liveness-safety tradeoff parameter.

Timing

When both checks pass, the FCR typically fires within one slot (~12 seconds). Under normal network conditions, this is nearly always the case for recent blocks.

Security Assumptions

  • Adversarial stake < 25%: if an adversary controls ≥25% of stake, they can potentially cause the FCR to fire on a block that later gets reorged.
  • The 2025 paper providing formal analysis shows the FCR provides 99.9%+ confidence under <25% adversarial stake on real Ethereum networks.
  • The assumption is weaker than the full finality guarantee (<33%), but much stronger than the probabilistic security of N-block confirmation rules.

Quantitative Impact

Current approachWait timeFCR approach
Exchange: 30 blocks~6 min~13 seconds
Exchange: 65 blocks~13 min~13 seconds
Full epoch finality~12.8 min~13 seconds
L1→L2 bridge deposit~10-20 min~13 seconds

Reduction: 80–98% depending on current confirmation practice.

Adoption Path

FCR is opt-in: exchanges and bridges adopt it client-side without any protocol change. The validator set provides FCR signal through attestation weights already published on-chain; the exchange just applies a different confirmation algorithm.

Proposed adoption sequence:

  1. Research publication + formal analysis
  2. Client libraries implement FCR detection
  3. Exchanges and L2 bridges adopt FCR as primary confirmation
  4. Protocol may later enshrine FCR natively (e.g., as a new safe head in the Engine API)

Relationship to Finality

FCR is NOT finality:

  • Full finality = block cannot be reverted without ≥33% of stake being slashed
  • FCR = block is extremely unlikely to be reverted given current attestation patterns, under the <25% adversarial assumption

FCR is a stronger confirmation rule than N-blocks but weaker than finality. Think of it as “probabilistic instant finality” that works for most use cases.

A separate but related finding: validators can economically profit by deliberately delaying finality without reverting blocks. A coalition can stall finality (by not attesting) when the bribery profit exceeds the inactivity leak penalty.

Key parameters:

  • Estimated cost of a finality stall attack: ~4.61 ETH in bribery (very low)
  • Duration before inactivity leak becomes prohibitive: variable
  • Bridges acting pre-finality (i.e., using FCR) are not affected by finality stalls, since FCR does not depend on full finality.
  • Bridges that wait for full epoch finality ARE vulnerable to finality stall-based griefing.

Implication: FCR adoption actually reduces bridge exposure to finality stall attacks, because finality stalls cannot prevent individual block confirmations from accumulating sufficient attestation weight.

Current Confirmation Practices (Reference)

ProtocolBlocks waitedApproximate time
Gnosis Bridge8~1.6 min
LayerZero15~3 min
Exchanges (typical)30–65~6–13 min
Circle CCTP65~13 min
Full finality~64 (2 epochs)~12.8 min

Open Questions

  • Should FCR be standardized in the Engine API (new safe head type, alongside the existing safe = last finalized)?
  • How does FCR interact with sub-slot execution (TOOL/NuConstruct) proposals that change the attestation timing model?
  • Can FCR thresholds be formally verified under the new Goldfish/Majorum consensus designs planned for future upgrades?

Key Sources

  • The Fast Confirmation Rule (2026) — FCR mechanism, formal analysis, adoption path
  • Rational Finality Stalls (2026) — economic analysis of finality stall attacks; bridge vulnerability data