Ben Edgington1
In my first post, I set out the broad plan for making Ethereum's finality fast: decouple finality from slot-by-slot fork choice, then improve it incrementally. This is a more deliverable roadmap than a single, all-at-once redesign.
To guide our work, I've spent some time with potential stakeholders: users and builders who are affected by Ethereum's finality. In total, I interviewed 19 individuals and organisations, and gathered asynchronous feedback from several more. They included layer 2 rollups, bridges, payment services, wallets, solvers, oracles, staking services, client developers, researchers, and teams working with institutional users. The aim was to understand who is most affected by Ethereum's current time to finality, what faster finality would unlock, and which trade-offs might be tolerable in getting there.
The full stakeholder research report contains the methodology, detailed breakdown, tables, caveats and a great many more quotations. You are reading the less encyclopaedic version.
Finality in a few tens of seconds appears to be a genuinely useful target. We do not need one-second finality for this work to make a meaningful difference.
Consumers and Providers
Three general stakeholder groups emerged from the conversations.
The first group is the finality consumers: bridges, interop systems, solvers, layer 2s and applications whose safety or operation depends directly on finalised Ethereum state. These are the people benefitting from faster finality.
The second group is the finality providers: staking operators, client teams and consensus researchers. They are less likely to benefit directly, but they have to implement, operate and defend whatever protocol we design. They are therefore the people setting the constraints.
A third group, covering commercial front ends such as payments, wallets and institutional adoption, sits somewhat to the side. For some of them Ethereum finality will remain much too slow: a non-custodial point-of-sale payment needs a response in one to three seconds, which is faster than an L1 transaction can usually be included, never mind finalised. For others, the current time to finality is already perfectly adequate. Traditional financial workflows are quite accustomed to settlement taking days.
Among the first group, the strongest demand came from cross-chain settlement and liquidity infrastructure. A bridge waiting for finality must either make its users wait, accept reorg risk, or pay someone else to take that risk. Solvers and relayers advance liquidity while they wait to be repaid, so every minute of finality delay ties up capital.
If finality [time] goes down, the relayer can charge cheaper fees. User fees would go down. The filler would be able to recycle capital more. It would just be more capital efficiency. — cross-chain infrastructure provider
Layer 2s typically raised three areas in which time to finality matters. The first was deposits: a chain can process an L1 deposit quickly while inheriting reorg risk, or it can wait for finality and give users a slower onboarding experience. The second was transaction pricing: slow finality leaves L2s pricing transactions from stale L1 blob-cost information. The third was cross-chain messaging, particularly private interop where introducing a third-party solver would break the privacy model.
A finality time of tens of seconds would be huge because those are onboarding transactions. — high-performance L2
In summary, faster finality can reduce risk, lower capital costs, improve pricing accuracy, and simplify application design.
How Fast Is Fast Enough?
There was no single answer to this question, but a clear and encouraging cluster emerged.
For bridges, interop and intent systems, 10 to 20 seconds was often described as a sweet spot. Up to around 30 seconds would still support many interactive flows. More broadly, finality in under a minute was commonly seen as a meaningful improvement, while one to three minutes would still be useful for L2 deposits, safe-head assumptions and blob pricing.
Ethereum doesn't need to get to one second. It just needs to not be 18 minutes; it just needs to be less than a minute. &mash; independent consensus researcher
At the very fast end, one to four seconds matters for point-of-sale payments, card authorisation and gaming responsiveness. Those are valid needs, but they are unlikely to be met by L1 finality itself. Preconfirmations, L2 sequencing and application-level risk management are better tools for this.
At the other end, some institutional workflows are fine with finality measured in minutes. That is useful context too: faster is not automatically better for every user, and we should optimise where the benefit curve is steepest.
The useful conclusion is that we do not need to win a one-second finality drag race. A small number of tens of seconds would already unlock substantial benefits for important Ethereum use cases, and that target looks very achievable.
Faster, Without Becoming Something Else
Stakeholders were remarkably consistent on one point: Ethereum should not try to compete with fast alt-L1s on their own terms.
There was strong agreement among stakeholders that Ethereum's value comes from its combination of censorship resistance, robustness, credible neutrality and non-capturability - all properties derived from its decentralised validator set. Several people would happily accept a much smaller nominal validator set if real-world diversity remained strong. Far fewer were willing to improve performance by pricing out home stakers, sidelining DVT, concentrating validators geographically, or forcing everyone through a few large operators.
This is an important distinction. A million validator indices is not the same thing as a million independent participants. Many large operators run fleets of 32 ETH validators behind the same infrastructure. Consolidating those virtual validators removes overhead without necessarily removing any real decentralisation, and was broadly viewed as benign.
Participation sampling or rotation may offer another route: retain a large and open validator population, while reducing how many validators sit on every fast-finality hot path. By contrast, a blunt hard cap on the number of validators worried people because large operators might game it or crowd out solo stakers.
One L2 put it nicely nicely:
You guys have spent a decade bootstrapping this highly decentralized set of validators, and we get to pay you to leverage that. — high-performance L2
The implication is that validator count alone is a poor policy target. We should care about entity diversity, geographic and jurisdictional spread, censorship resistance, solo and DVT viability, and correlated-failure risk. Reducing duplicate protocol overhead is good. Reducing the number of genuinely independent participants is much less desirable.
Faster finality is worth pursuing, but not by weakening the things that make Ethereum valuable.
Safety, Liveness and One-Round Finality
One possible route to faster finality is to use a single round of voting rather than the traditional two. That could roughly halve time to finality, but might reduce the adversarial tolerance from today's one-third to something like one-fifth or one-sixth, depending on the design.
Support for making that trade-off was weak at this stage.
People reasoned about it in several different ways. Some focused on the absolute value of stake that would still be slashable and felt that many billions of dollars ought to be enough. Others focused on real-world stake control and worried that a major exchange, staking pool, custodian, or even a client software bug could plausibly approach a 17 to 20 per cent threshold of stake.
A recurring problem was that economic finality is difficult to reason about. A very large dollar amount sounds reassuring, but it does not fully answer questions about who actually controls the stake, how correlated failures might occur, what happens during a network partition, or how the chain recovers from a bad finalisation event.
There was, however, an important nuance. Several protocol and staking stakeholders were more comfortable reducing finality liveness than reducing finality safety. In other words, under abnormal conditions it might be acceptable for finality to pause more readily, provided that the available chain keeps processing transactions - this helps the protocol to avoid finalising a wrong history.
My reading is that one-round finality remains an interesting option, but not the obvious first lever to pull. There is plenty to do through decoupling, networking, aggregation, consolidation and validator-set management while retaining the current two-round safety margin. We should see how far those take us before possibly weakening one of Ethereum's important guarantees for an extra factor of two speedup.
A Brief Word on the Available Chain
Although it was not the main focus of the research, Ethereum's ability to keep producing blocks when finality stalls came up repeatedly. Stakeholders value the fact that Ethereum does not simply stop during many classes of failure. Institutional and product teams use this reliability as part of Ethereum's story, and L2s depend on L1 availability for posting data, force-inclusion and censorship resistance.
Uptime is another thing that is very valuable to us. So we would rather you not do the "move fast and break things" thing. — high-performance L2
That said, an available but unfinalised chain is not a substitute for hard settlement. Conservative bridges and other high-value systems still need to know that state is final. The available chain is best understood as a useful degraded mode, it is not backed by any of the guarantees of finality.
This broadly supports the direction we are already taking: preserve an available chain for continuity, pair it with a separate and conservative finality gadget, and make the gap between the two as short as we reasonably can. We will also need to make degraded operation legible, so that downstream systems know what they should do while finality is absent.
See the full analysis for a much deeper dive on this.
What This Means for the Roadmap
The research does not point towards maximum speed at any cost. It points towards a useful target and a fairly clear set of guardrails.
First, finality in a few tens of seconds is a worthwhile goal. It would materially improve bridges, interop, solver economics, L2 deposits and transaction pricing. We do not need to reach one second for the work to pay off.
Second, the case for decoupling finality remains strong. Finality consumers want faster hard settlement, while finality providers want to preserve safety, operability and room for careful iteration. A properly decoupled finality gadget allows us to improve incrementally without repeatedly rebuilding the whole slot-by-slot consensus process.
Third, we should optimise for real decentralisation rather than raw validator count. Consolidating duplicate validators and exploring carefully designed participation schemes look more acceptable than excluding the long tail of small stakers.
Fourth, one-round finality should be treated cautiously. It may have a place later, particularly if the trade-off can be expressed clearly and degraded modes are well understood, but the present evidence does not suggest rushing it into the critical path.
Finally, it would be good to have better numbers. The most obvious missing piece is a set of cost curves for bridges and solvers: how much capital and how much user cost are tied up when finality takes 15 minutes, five minutes, one minute or 20 seconds? The qualitative signal is strong. Quantifying it would help us judge where the greatest returns can be found.
Closing Remarks
This was qualitative research rather than a full ecosystem survey, and the sample was neither random nor comprehensive. It should be treated as useful evidence, not necessarily the last word.
Still, the result is pleasingly uneventful. The broad assumptions behind the fast-finality roadmap survived contact with the stakeholders who build on, operate and depend on Ethereum.
Faster finality remains primarily a security upgrade: it shortens the vulnerable, reorg-vulnerable tail of the chain. But, happily, it also appears likely to make cross-chain systems cheaper, L2s simpler and onboarding less tedious. Finality in a few tens of seconds, achieved without compromising Ethereum's distinctive strengths, looks both useful and worth pursuing.
I am deeply grateful to all of the stakeholders who so generously shared their time and insights for this exercise.
Footnotes
-
The research described here was qualitative and should not be mistaken for an ecosystem-wide view. Everything to do with the roadmap is, of course, subject to Ethereum's governance process. ↩