Ethereum’s 16-Minute Settlement Wait Could Drop to Four
Ethereum researchers have filed a draft that would split validator voting into two tracks, aiming for at least fourfold faster finality as the first stage of a longer effort.
Key Takeaways
- Today’s expected finality time: about 16 minutes
- Head-vote committee: about 512 validators per slot
- EIP number 8453 proposed; draft still unmerged
- 2027 upgrade slot floated as stretch goal
Ben Edgington, who describes his role as coordinating Ethereum’s fast-finality work, opened the Decoupled Consensus pull request on October 21. He co-wrote the draft with Francesco D’Amato, Roberto Saltini, Yann Vonlanthen and Mikhail Kalinin.
His note on the pull request says “many aspects remain TBD” and that the immediate aim is an EIP number. A reviewer in the EIPs repository proposed 8453 the same day and asked the authors to open a discussion thread on Ethereum Magicians, the forum where proposals are debated. The pull request remains open and unmerged.
Why finality still takes about 16 minutes
Finality marks the point before which Ethereum’s validators will not reverse blocks. Reaching it takes two voting rounds, one to justify a checkpoint and one to finalise it, and each round lasts an epoch of 32 twelve-second slots. In a May 11 post on the Ethereum Foundation’s protocol consensus blog, Edgington put the minimum at 768 seconds and the expected time for a transaction at about 960, with 63 to 95 of the latest blocks unfinalised under normal conditions.
Those recent blocks can still be reorganised: nodes may switch to a competing sequence of blocks, sending transactions from the dropped ones back to the mempool to be included again. Finalised blocks are far harder to touch. Reversing one would require attackers holding more than a third of all stake, and it would cost them at least one-third of all staked ETH through slashing.
The same post describes a fast confirmation rule designed to give an earlier signal. When the network runs smoothly and no attacker is too powerful, it should show within about 13 seconds that a block will not be reorganised. It carries no economic penalty for attackers and does not tolerate network delays, so during network trouble it falls back to full finality, when services need certainty most.
Services that act on Ethereum transactions therefore choose how much of the finality wait to accept. The post lists several examples, including Circle’s Cross-Chain Transfer Protocol (CCTP) for USDC:
| Service | What it waits for | Trade-off |
|---|---|---|
| CCTP, standard route | Ethereum finality, about 15 minutes | Slowest option, with full settlement |
| CCTP, fast route | Two block confirmations, about 20 seconds | Caps on USDC in transit and a fee |
| Arbitrum chains | Unrealised justification, an early finality stage about 8.5 minutes sooner | Lacks finality’s full guarantees |
| OP Stack chains | A few slots | An Ethereum reorg could reorganise the layer 2 |
| Centralised exchanges | A set number of block confirmations | Some deposit risk to credit funds sooner |
Source: Ben Edgington, Ethereum Foundation protocol consensus blog, May 2026
Faster finality would narrow the gap between those routes, both for stablecoin bridges and for newer tokenised products such as the bank deposits JPMorgan is bringing to Ethereum. Edgington expects cross-chain bridging to show the most visible gains.
One attestation becomes two messages
Ethereum’s current consensus design, Gasper, packs two votes into each validator attestation. One feeds LMD GHOST, the fork-choice rule that tells the next proposer which block to build on. The other feeds Casper FFG, the slower process that finalises checkpoints. Because the two travel together, fork choice draws on attestations from about 30,000 validators per slot, though the researchers behind the draft say far fewer would do.
The draft EIP turns those votes into separate messages that travel across the network and are processed independently:
Head votes
Who votes: a committee of about 512 validators per slot, drawn with odds proportional to each validator’s effective balance, the stake the protocol credits to it.
What it decides: which block is the head of the chain and which recent blocks are confirmed.
Finality attestations
Who votes: the entire validator set.
What it decides: which blocks are justified and finalised, in rounds on their own schedule, with each step requiring at least two-thirds of active stake.
With its own schedule, the finality round can use bandwidth across the whole voting period and be shortened later without redesigning how slots work. The authors’ initial target is at least a fourfold reduction in time to finality, subject to parameters they have yet to specify. Applied to today’s 16-minute expectation, a fourfold cut would mean roughly four minutes, although the draft itself gives no figure.
Where the fourfold cut fits in a longer plan
In the same May post, Edgington set out the longer-term ambition: bringing time to finality down from about 1,000 seconds to about 10. He presented it as his personal view rather than an official roadmap.
He wrote that earlier designs such as single-slot and three-slot finality foundered because they required solving every problem at once. The new approach stages the work. “Decoupled finality is the big unlock,” he wrote, expecting that step alone to bring a low single-digit speedup, in line with the draft’s fourfold target. Further gains would come from separate upgrades:
- Validator consolidation: since the Electra upgrade, large operators can merge up to 64 validators into one, cutting the number of finality votes. Edgington called progress slow.
- Batching votes at the source: operators running many validators behind one node would combine their votes before broadcasting them.
- Rotating the validator set: only a subset of validators would take part in finality at any time, without excluding or capping anyone.
- Faster networking and aggregation: peer-to-peer upgrades and SNARK-based aggregation would move votes more efficiently.
- Single-round finality: one voting round instead of two would nearly halve the wait, at the cost of lowering fault tolerance from a third of stake to perhaps 20% or 17%.
The draft itself includes none of these steps. By Edgington’s arithmetic, four improvements that each deliver a threefold gain would come close to the 100-fold ambition. He also noted that the Strawmap roadmap listed decoupled consensus as a headliner candidate for the upgrade provisionally labelled I*, likely in 2027, as a stretch goal.
Why Ethereum won’t halt to go faster
Classic Byzantine fault-tolerant protocols such as Tendermint finalise blocks quickly but stop producing them when too many validators go offline. Researcher Luca Zanolini argued in a March post on the Ethereum Research forum that halting is incompatible with Ethereum’s design. He pointed to a proven limit known as the availability-finality dilemma: no single protocol can keep growing while participation rises and falls and also stay safe through a network split. Ethereum’s answer is one layer that keeps building blocks with whichever validators are online and a second that finalises behind it.
Zanolini cited the network’s record. In May 2023, bugs in the Prysm and Teku clients, which together ran more than half of validators, disrupted finality and set off Ethereum’s first mainnet inactivity leak. Block proposals never dropped below roughly 90% of slots and transactions kept processing. By contrast, Solana produced no blocks for five hours during its February 2024 halt, leaving DeFi protocols on the network unable to operate.
Decoupled Consensus keeps that arrangement. Finality still needs the two-thirds quorum, so a large enough outage can stall it while the remaining validators keep building blocks. Most applications can keep running, but anything requiring final settlement has to wait. If participation does not recover, the inactivity leak gradually reduces offline validators’ stake until finality can resume. How the leak would work under the new design is still to be written.
The post-quantum reason comes first
Faster finality draws the attention, yet it is third on the authors’ list. The pull request names a foundation for a later post-quantum transition first and fork-choice security second, and the draft’s motivation follows the same order.
The connection is signature aggregation. Validators sign with BLS, a scheme that lets many signatures be merged into one compact signature. Zanolini wrote that no post-quantum scheme offers comparable aggregation at practical sizes. A head-vote committee of a few hundred validators avoids the problem because its signatures can be sent side by side. He argued this could allow a post-quantum version of the block-producing layer before anyone solves aggregation for finality votes from the full validator set. The draft prepares for that path but does not select a post-quantum signature scheme.
New defences come with a smaller target
Today’s fork choice keeps each validator’s latest vote with no age limit. According to the draft, that lets attackers withhold votes and release them at strategic moments to tip nodes toward a chosen branch. Under the proposal, fork choice counts only votes from a recent slot, with specified cutoffs for when they must arrive.
Locks protect blocks the chain has confirmed. A block becomes fast-locked when at least half of that slot’s committee sends timely head votes for it, with no validator voting both ways. Locks expire, and recent votes for a competing block can move a lock back to an earlier block, letting the chain recover as conditions change. Proposers would also carry recent votes in their blocks to bring validators’ views into line. This technique, called view-merge, replaces proposer boost, the extra fork-choice weight currently given to a timely block, and targets balancing and reorg attacks.
The smaller committee is the trade-off. Fewer voters means less signature work in each slot, but it raises the chance that a random draw hands an attacker an outsized share of a committee and gives attackers a smaller group to knock offline with denial-of-service attacks. Choosing committees privately through a verifiable random function is one option under study. The size is not settled either: earlier research posts sketched about 256 validators, and the draft leaves both its 512 figure and the selection method open.
What must happen before any upgrade
Activating Decoupled Consensus would take a consensus-layer hard fork, with consensus and validator clients supporting new voting duties, block and state formats and fork-choice rules. Rewards and penalties, slashing conditions, timing and lock parameters, fork-transition rules, executable test cases and a full safety and liveness analysis are all still to be written. A work-in-progress specification sits in a feature branch of Ethereum’s consensus specifications. The draft keeps the total validator rewards budget unchanged, though payments could shift between head voting and finality duties.
The bigger trade-off lies beyond this draft. Edgington has written that he wants fast-enough finality without excluding home stakers, solo stakers or those in remote locations, and that the community may at some point have to weigh even faster finality against staking diversity.
What to watch next
- EIP status: whether the pull request merges as a Draft under number 8453 and a discussion thread opens on Ethereum Magicians.
- Specification work: progress on the rewards, slashing and inactivity-leak sections still marked TBD.
- Upgrade scoping: whether core developers pick decoupled consensus as a headliner for I*. Missing that list would push the 2027 stretch goal back.
Kosta has reported on cryptocurrency markets and blockchain infrastructure since 2020, bringing over six years of hands-on experience in the crypto industry built through daily tracking of markets, trends, and emerging blockchain developments. Specializing in Bitcoin on-chain analysis, institutional ETF flows, and digital asset price action, his work at Coindoo has been cited by other news agencies and consistently covers market developments with a focus on data-driven reporting across Bitcoin, Ethereum, Solana, and XRP. Over the years, Kosta has contributed to multiple crypto media outlets in different regions, authoring over 6,000 articles across the sector. His reporting spans cryptocurrency markets and the broader fintech industry, tracking not only price action but also the technological and regulatory forces shaping the ecosystem. To support his analysis, Kosta actively leverages on-chain data and metrics from leading platforms such as Santiment, Glassnode, and CryptoQuant, enabling deeper, evidence-based market insights. He believes in the power of transparency and the data that underpins the blockchain ecosystem. His academic background in Marketing Management from Denmark further complements his analytical approach, adding a strong understanding of communication strategy and content positioning to his work.
