Summary

Bridges and L2s that act before Ethereum finality (accepting deposits, releasing funds) are exposed to two risks: normal reorgs and rational finality stalls — attacks where a validator coalition deliberately delays finality without reverting blocks, to profit from applications relying on finality as a safety signal. The estimated cost of a finality stall attack is ~4.61 ETH in bribery, making it economically viable. The Fast Confirmation Rule (FCR) provides an alternative: strong confirmation without waiting for epoch finality, at the cost of a <25% adversarial stake assumption.

Current Bridge Confirmation Practices

ProtocolBlocks waitedApprox. timeFinality status
Gnosis Bridge8~1.6 minPre-finality
LayerZero15~3 minPre-finality
Uniswap / typical30–64~6–12 minPre-finality to full
Circle CCTP65~13 min~Full finality
Full finality~64 (2 epochs)~12.8 minFull finality

All bridges except those waiting the full 2 epochs are operating pre-finality. Even 65-block bridges are not fully safe against finality stalls if the stall is coordinated to last exactly the right duration.

Normal Reorg Risk

In Gasper, blocks that haven’t been finalized can be reorged. The probability of an n-block reorg decreases with n (bounded by honest attestation weight). For well-confirmed blocks:

  • 8 blocks: ~99%+ safe against network-originated reorgs
  • 32 blocks: near-zero probability of honest reorg
  • Finality: zero probability of reorg without ≥33% slash

But normal reorg risk (from network failures, competing forks) is different from deliberate attack reorg risk.

Rational Finality Stalls

A finality stall occurs when a validator coalition witholds attestations (or votes for old checkpoints), preventing Casper FFG from finalizing new blocks. This does NOT revert existing blocks — the chain continues producing blocks — but finality stops accumulating.

Attack Economics

Why would validators do this?

Consider a bridge that pays out when a block is finalized. A coalition can:

  1. Prevent finality until the bridge pays out (stall the signal the bridge is waiting for)
  2. Short the bridged asset during the period of uncertainty
  3. Profit from the price volatility created by apparent Ethereum instability

Estimated attack cost (from the 2026 analysis):

  • Bribery cost: ~4.61 ETH to coordinate a finality stall of meaningful duration
  • Penalty cost: inactivity leak accumulates over time; short stalls are cheap
  • For stalls lasting < ~1 hour: inactivity leak is small enough that attack may be profitable

What Gets Finalized (Gloas Nuance)

Under ePBS (Glamsterdam), “finalized” has two distinct meanings:

  1. Beacon block finalized: ≥⅔ of validators voted for the checkpoint containing this beacon block — this is permanent
  2. Execution payload available: the execution payload (the actual transactions) has been propagated and is accessible

A finalized beacon block does NOT guarantee the execution payload is available. In edge cases, a finalized beacon block’s payload may not be retrievable. The Engine API safe tag needs to be updated to reflect both conditions.

Bridges Should Use beacon_safe AND payload_safe

Bridges that check only block finality (beacon block) may credit deposits before the actual transaction data is confirmed available. The correct check is:

  • beacon_block.finalized == true AND payload.available == true
  • Under current Engine API: the safe tag should be interpreted as requiring both conditions

The Finality Stall Defense: Use FCR

The Fast Confirmation Rule (FCR) provides a path that is immune to finality stalls:

  • FCR is based on attestation weight on individual blocks, not on Casper FFG finalization
  • A finality stall (validators not voting for FFG checkpoints) does not prevent blocks from accumulating attestation weight
  • FCR fires within ~1 slot (~13 seconds) for normally-attested blocks
  • A finality stall attacker cannot prevent FCR from firing without also mounting a 25%+ stake attack

Implication: bridges that adopt FCR are NOT exposed to finality stall attacks. Bridges that wait for full epoch finality ARE.

Recommendations for Bridge Operators

  1. Use FCR for deposit confirmation (13 seconds, immune to finality stalls)
  2. Don’t use block count as a finality proxy — it conflates reorg risk and finality stall risk
  3. Update finality checks for Gloas/ePBS: check both beacon block finality AND payload availability
  4. Monitor for finality stalls: if Casper FFG stops finalizing but blocks continue, treat as potential attack (but continue operations using FCR)
  5. Plan for the inactivity leak: if finality stalls persist, the inactivity leak will eventually resume finality; bridge operations under the inactivity leak period need specific handling

L1→L2 Deposit Experience

Current L1→L2 deposit times (dominated by finality waits):

  • OP Stack (Optimism, Base): ~20 minutes (waits for finality)
  • Arbitrum: ~10 minutes
  • zkSync, StarkNet: seconds to minutes (validity proofs; different trust model)

With FCR adoption:

  • Optimistic rollups adopting FCR: ~13 seconds from L1 transaction to L2 credit

Open Questions

  • Should the Engine API be updated before Glamsterdam (ePBS activation) to expose payload_safe separately from beacon_safe?
  • What is the empirically observed frequency of finality stalls on mainnet? (There have been incidents in 2023; what’s the rate in 2025-2026?)
  • Can finality stall bribery be detected on-chain before the stall succeeds?
  • How do finality stalls interact with DVT (distributed validator technology)? Does DVT reduce or amplify coalition coordination costs?

Key Sources

  • Rational Finality Stalls and the Risks of Pre-Finality Actions (2026) — attack model; 4.61 ETH bribery cost; bridge confirmation table
  • The Fast Confirmation Rule (2026) — FCR as immunity to finality stalls
  • What is Finalized in Ethereum (Apr 2026) — Gloas nuances; beacon block vs. payload availability; Engine API implications