Ethereum Tests What Happens When Finality Stops

Ethereum developers are preparing a Gloas devnet exercise that will reduce validator participation below the level required for finality, then test whether client software recovers.
Key Takeaways
- Devnet-9 pairs a fork with failure testing.
- Finality needs two-thirds of staked ETH.
- Blocks can continue during a finality stall.
- The inactivity leak can restore finality.
- The drill is confined to an isolated devnet.
The real test begins after Gloas activates
Ethereum’s published Glamsterdam devnet-9 specification gives developers two jobs in sequence. They must first complete a clean Gloas transition, then deliberately take validator participation below the threshold required to finalize checkpoints.
The Gloas fork was scheduled for September 2 at 15:00 UTC. The same specification describes non-finality as the devnet’s second testing objective, but does not confirm that this phase has started or finished.
The first stage matters because Gloas must apply to a large pre-fork state created at genesis, rather than one grown over days of block production. The second stage asks a harder question: after clients have accepted the new rules, do they still agree when Ethereum loses one of its most important safety guarantees?
That sequence gives the exercise its value. A client can handle a fork correctly under normal conditions yet expose a disagreement only when finality stalls and the network has to recover.
Finality can stop while blocks keep moving
Ethereum does not need finality to keep producing blocks. In simple terms, finality is the point at which Ethereum treats a block as permanent. Reversing a finalized block would require at least one-third of all staked ETH to be destroyed.
Validators can still propose blocks, transactions can still be included and the network can still select a chain head. Finality is the stronger settlement guarantee that comes after validators representing at least two-thirds of staked ETH agree on checkpoints.
Ethereum’s proof-of-stake documentation explains that a finalized checkpoint is economically difficult to reverse. Without that status, recent blocks remain more exposed to reorganization and applications that require finality may wait before treating activity as settled.
What changes when participation falls below two-thirds
What can continue
New blocks can still be proposed. Ethereum does not need finality to keep producing blocks.
Transactions can still enter those blocks. Users can submit activity while validators keep selecting a chain head.
The network can keep moving forward. A finality stall is not the same as a complete chain halt.
What must wait for finality
No new checkpoint becomes economically final. Validators need two-thirds of staked ETH to restore that guarantee.
Finality-dependent settlement must wait. Some bridges, exchanges and applications rely on finalized checkpoints.
Recent blocks carry more reorganization risk. They remain without Ethereum’s strongest settlement protection until finality returns.
The drill recreates the same one-third failure boundary explored in Coindoo’s analysis of Ethereum’s 33% finality threshold. More than one-third of stake failing to participate can stop finalization even while block production continues.
How Ethereum regains the missing supermajority
Ethereum’s recovery mechanism is called the inactivity leak. After more than four epochs without finality, or roughly 25 minutes under current network timing, the protocol begins gradually reducing the balances of validators that are not participating correctly.
As those inactive balances shrink, the share held by active validators rises. Once active validators again represent at least two-thirds of the remaining stake, they can finalize checkpoints and restore Ethereum’s full settlement guarantee.
The process is gradual and financially costly for validators that remain offline. Transactions may still appear in blocks during the stall, but applications that need finality must wait for the network to regain it. Ethereum details the mechanism in its validator rewards and penalties documentation.
Four answers developers need to publish
A useful report from the exercise would answer four practical questions:
- Did participating clients apply the Gloas rules identically?
- How long did the devnet remain without finality?
- Did clients retain one shared chain head?
- When did the first checkpoint finalize after recovery?
Those details would show whether the network recovered cleanly, rather than merely confirming that developers intentionally created a difficult condition.
Why this matters before Sepolia
A finality stall is not only a theoretical risk. Ethereum mainnet experienced two temporary finality stalls in 2023 after a Prysm client issue, although blocks continued to be produced. This devnet exercise is a controlled attempt to test that recovery path before Glamsterdam reaches a broader testing stage.
Glamsterdam remains in devnet testing. Ethereum lists the Sepolia fork as the next milestone on September 28, while a mainnet launch is expected in the fourth quarter of 2026 but has no confirmed date. The official Glamsterdam roadmap remains the reference point for its rollout.
When developers publish the outcome, the important details will be how long finality stalled, whether clients stayed aligned and which checkpoint first finalized after recovery.









