TL;DR
Some Ethereum-anchored systems (e.g., L2s and cross-chain bridges) act before protocol finality, relying on heuristic signals such as confirmation depth. We describe a rational finality stall, where validators temporarily delay finality without breaking consensus. During this window, Ethereum-anchored systems may act on a non-finalized state that can later be reorganized.
Heuristic Confirmation Rules Used by Representative Cross-Chain Bridges
(i) Most systems trigger settlement after a fixed number of block confirmations rather than waiting for Ethereum finality (two epochs).
(ii) Delay is estimated using an average Ethereum block time of ≈12 s, i.e., Delay ≈ blocks × 12 s.
Confirmation thresholds are taken from official documentation.
| Project | Settlement Mechanism | Confirmation Rule | Blocks | Delay (min) |
|---|---|---|---|---|
| Gnosis Bridge | Multisig validator committee | Multisig approval after confirmations | 8 | 1.6 |
| Avalanche Bridge | Intel SGX enclave + wardens | Enclave attestation after confirmations | 96 | 19.2 |
| Circle CCTP | Native USDC burn/mint + attestation | Attested confirmation threshold | 65 | 13 |
| LayerZero | Oracle + relayer dual-path verification | Oracle-reported confirmation threshold | 15 | 3.0 |
| Stargate | Liquidity pools + LayerZero messaging | Soft confirmations via oracle/relayer | 15 | 3.0 |
| deBridge | Validator network + claim verification | Validator-observed confirmations | 12 | 2.4 |
| Celer cBridge | Liquidity pools / lock-and-release | Relayer-observed confirmations | – | 5–20 |
Motivation
Many Ethereum-anchored systems do not literally wait for Ethereum protocol finality before acting. Instead, they often rely on heuristic signals such as a fixed number of block confirmations or a fixed time delay. For example, many cross-chain bridges trigger settlement after a fixed number of block confirmations rather than waiting for Ethereum protocol finality (two epochs).
Under normal conditions, these signals tend to correlate with Ethereum finality, and applications may treat them as roughly interchangeable. However, these signals represent different security boundaries.
It is therefore useful to separate two questions:
- Has the chain continued to grow?
- Has the corresponding state reached Ethereum protocol finality?
Under ordinary network conditions, these signals may appear closely aligned, but they are not equivalent.
Ethereum protocol finality represents the strongest settlement guarantee available in the protocol. If an Ethereum-anchored system acts earlier, it is implicitly relying on a weaker settlement rule.
Rational Finality Stall
We define a rational finality stall as a scenario in which a coalition of validators intentionally delays Ethereum protocol finality for a limited period due to economic incentives.
In such a scenario:
- validators withhold attestations required for finalization,
- the chain continues to grow normally,
- and finality is temporarily delayed without reverting any finalized blocks.
An attacker does not aim to break Ethereum consensus itself, but rather to create a window during which Ethereum-anchored systems act on non-finalized state.
A simplified sequence could look like this:
- A coalition with sufficient stake to block finality withholds the votes required for finalization.
- The chain continues to extend normally.
- Ethereum-anchored systems relying on confirmation depth or time delay interpret the growing chain as sufficiently stable.
- These systems perform externally meaningful actions.
- Later it becomes clear that the action was taken on a prefix that never reached protocol finality.
Importantly, the attacker does not necessarily need to revert finalized history.
It may be sufficient to create a window during which downstream systems are willing to act before finality is reached.
Economic Perspective
This scenario can be viewed through a simple economic lens. Suppose an Ethereum-anchored system triggers action after k confirmations, or t minutes. A rational attacker only needs the finality stall to persist long enough for this trigger to fire.
The relevant comparison therefore, becomes:
Is the value extractable from inducing pre-finality actions larger than the attacker’s cost of sustaining the stall?
The attacker’s cost may include:
-
Foregone validator rewards: Validators withholding attestations lose normal attestation rewards and may incur penalties.
-
Inactivity leak losses: If finality fails for several epochs, the inactivity leak mechanism gradually reduces the stake of validators on the non-finalizing side.
-
Coordination and opportunity costs: A coalition large enough to stall finality must coordinate behavior and accept capital risk.
The attacker’s potential upside may come from actions triggered during that window, such as:
- asset releases
- token mints
- cross-chain message execution
- liquidity advancement
- accounting updates
The attacker does not need to break Ethereum finality itself. It may be sufficient to delay finality long enough for pre-finality triggers in Ethereum-anchored systems to fire.
From this perspective, the issue is best understood as a latency–settlement tradeoff under adversarial economics.
Latest data from Beaconcha.in indicates that Lido currently maintains a staking share of 21.14%. The total network stake is approximately 38,029,806.48 ETH.
To reach the 1/3 threshold necessary to initiate a finality stall, a gap of approximately 12.19% of total stake (4,635,833.41 ETH) must be filled.
Assuming that each validator has a stake of 32 ETH, 14,487 additional validators would be required to participate in the attack.
The attacker would need to provide a minimum bribe equivalent to the lost rewards of these additional validators to incentivize their participation in the stall.
Based on the Ethereum base reward calculation model, in the event of a 94-block reorganization caused by an attack, a rational validator can earn a base reward of approximately 30,846.69 Gwei.
Therefore:
- Total reward for 12.19% validators ≈ 4,468,752,870.41 Gwei
- Equivalent ≈ 4.47 ETH
Using the Ethereum staking annual interest rate of 2.778% (source: Ethereum staking: How does it work?), the total reward earned by these validators is approximately 4.61 ETH.
Therefore, in order to make the finality stall economically feasible (assuming Lido is the attacker), the value extracted from the target system must exceed the bribery cost of approximately 4.61 ETH, excluding additional coordination and capital risks.
Disclaimer. Lido is used here only as an illustrative example due to its large staking share.
This analysis does not imply that Lido would attempt such an attack.
The goal is simply to show that, given the current staking distribution, the economic barrier to coordinating a temporary finality stall may be lower than commonly assumed. The example therefore serves to illustrate the potential feasibility of the scenario under realistic network conditions.
Conclusion
Ethereum protocol finality exists to provide a strong settlement boundary. However, some Ethereum-anchored systems may choose to act earlier for latency or capital efficiency reasons. Doing so introduces additional reorganization risks.
From a protocol design perspective, the safest default is to align application settlement rules with Ethereum protocol finality whenever possible. We therefore strongly encourage Ethereum-anchored systems to explicitly account for these risks when designing settlement mechanisms, particularly when relying on heuristic confirmation rules such as block depth or time delays.