Finality Stakeholder Research

Ben Edgington¹

---

A blog post is available that more succinctly discusses the results below.

• Introduction
• Headlines
• Stakeholder Groups
• Time to Finality
• Trade-offs
  • Validator Set Restrictions
  • Adversarial Tolerance and Economic Security
• The Available Chain
• Closing Remarks

Introduction

Faster finality is primarily a security upgrade for Ethereum. The time interval between the head of the chain and the last finalised checkpoint is a period of vulnerability - reducing this vulnerable period is good for the security of the chain and for the security of the platforms and applications that build on it.

But, more than that, faster finality can also benefit applications built on Ethereum and, in turn, their users. With this in mind, I have taken the opportunity to talk to a range of stakeholders to help us shape the design for maximum benefit. In all, I conducted 19 interviews with individuals and organisations about finality on Ethereum, and gathered async feedback from several more. Participants include layer 2 rollups (both optimistic and ZK), payment services, wallet developers, bridges, solvers, oracles, those dealing with institutional users, staking services, client developers, and researchers. Some are small operations; some are huge and systemically important.

This was all in the context of the big changes we want to make to the protocol that will allow us to reduce Ethereum's time to finality.

The primary goal was simply to identify the stakeholders: who are the people most heavily affected by Ethereum's time to finality, and how can faster finality benefit them?

A secondary goal was to explore the kinds of trade-offs Ethereum should be prepared to consider in order to achieve much faster finality. How would we feel about drastically pruning the validator set? Would it be acceptable to lower the protocol's safety and liveness thresholds? Things like that. The answers should be treated cautiously as they are definitely not a broad sampling of the whole ecosystem, but hopefully they give some signal as to what significant stakeholders most value about Ethereum.

Methodology

This exercise is qualitative research. The interviews were somewhat structured, but conversation was often organic as well. About half of the interviewees were people I contacted (outbound), and half were inbound, either responding to my public invitation or by referral from others. In an attempt to reduce the influence of my own biases I have leaned heavily on Codex/ChatGPT 5.5 for the analysis, through a process of normalisation, summarisation, coding, then interrogation. Many of the words that follow are my own, but the results are as analysed by Codex. I have mostly anonymised the results, reporting only generic categories, but where the information shared is already public elsewhere I have named names when it's more convenient to do so.

This report is by no means comprehensive, and quotes cited from interviewees are selective and intended to be illustrative rather than covering all aspects and angles discussed. Nevertheless, I have aimed to surface the most important feedback. In most cases I have cleaned up quotations and added context where needed in square brackets. Codex assures me that I have not materially changed the meaning or intent of any of them.

Conventions:

• text copied and pasted from Codex has a grey background, or a blue background when it's a section heading;
• quotations from interviewees appear in italics with a side bar.

Headlines

While stakeholders presented a wide range of views on many topics, the most durable cross-cutting conclusions were as follows.

1. Available-chain liveness is a core Ethereum asset

   It was very commonly stated that one of Ethereum's most critical properties is that it never stops. This is a strong endorsement of our design direction that couples an available chain with a finality gadget.

   This is explored further in the Available Chain section.

2. Finality in under a minute provides a meaningful improvement for many applications.

   For many (but not quite all) applications, reducing the time to finality from its current ~1000 seconds to a few tens of seconds would provide a worthwhile improvement. This is encouraging as it seems achievable, whereas a finality time of a few seconds is a much harder goal.

   This is explored in detail in the Time to Finality section.

3. Ethereum should not try to compete with fast alt-L1 chains on their own terms.

   It is widely agreed that Ethereum's radical commitment to properties like censorship resistance, robustness, and non-capturability via decentralisation are what make it valuable. Stakeholders urged us not to compromise on these for the sake of extreme performance. Notwithstanding this, several stakeholders would like to see Ethereum become much faster, both in slot length and time to finality.

4. Stakeholders reason differently about economic finality, adversarial tolerance, real stake-control concentration, value-at-risk, liveness failure, and recovery

   Economic finality in particular was found to be hard to reason about, or thought to be unconvincing as a security property. Absolute adversarial tolerance was more highly prized.

5. Demand is strongest from L2s, bridges, interop, solvers, and product teams; constraint-setting comes from staking, client, research, and institutional stakeholders.

   The former group I call "finality consumers", the latter "finality providers".

   See the Stakeholder Groups section.

6. There is only weak support for one-round finality at this time.

   See the Adversarial Tolerance and Economic Security for more on this.

By and large there are few surprises here, and the interviews essentially supported our assumptions and direction of travel with the fast finality design.

Stakeholder Groups

Codex identified the stakeholders I interviewed as sitting in four general groups based on how they relate to Ethereum finality. I think of the first two groups as consumers of finality, and the last group as providers of finality. Finality is not particularly relevant to the third group.

Stakeholder group	Stakeholder type
Cross-chain settlement and liquidity infrastructure	Finality Consumers
L2 and application platforms that inherit L1 finality	Finality Consumers
Commercial front-end and adoption	-
Protocol, staking, client, and research stewards	Finality Providers

Cross-chain settlement and liquidity infrastructure

The main themes raised by this group were risk management, capital efficiency, and user experience. This group is particularly significant in joining up our multi-chain reality, encompassing the whole L2 ecosystem.

Bridges that deal with tokens issued by third parties must be cautious:

[Our] security stance has been to always wait for finality on Ethereum L1. This also applies to L2-to-L2 transactions - transfers from Base or Arbitrum still take 15-18 minutes. The long time to finality limits the use cases that [we] can support and is bad for user experience. [We are] not a token issuer, so, unlike Circleʼs CCTP fast transfers, we cannot take on transfer risk.

The reference to CCTP concerns Circle's CCTP v2 bridge for USDC. As the token issuer, Circle is able to tolerate more risk, so they now offer a fast transfer option that does not wait for finality, although it charges a fee for this and limits the total amount of USDC in-flight at any time.

Regarding solvers (capital efficiency),

They're really loaning over the amount of time they're waiting to get the funds back. That's mostly based on finality. So if that 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.

Relayers are really competing to see who can take on the most amount of finality risk to fill the user faster because there's some fee attached to it. So what the relayers might do is they might define for example a waterfall structure of risk. So depending on the size of the transfer, they might be willing to take on more finality risks. So for a $100 transfer, they might only wait one slot before filling versus a $10,000 transfer, they might wait for finality.

Solvers are always at risk from non-finality.

Unfortunately, I didn't manage to speak with any actual solvers/relayers whose capital is committed - they seem to operate in the shadows away from public gaze. It would be excellent to get some quantification of bridge capital costs and to sketch out some finality–benefit curves.

L2 and application platforms that inherit L1 finality

I conducted interviews with six rollups: four optimistic (two of which are explicitly high performance) and two ZK (one offering private chains for institutional clients, the other gaming-oriented).

Three main pain points were frequently raised in relation to finality: deposit transactions, transaction pricing, and cross-chain messaging/interop.

Deposit transactions

A deposit transaction moves assets from L1 to L2. This matters, because if the L2 were to ingest an L1 deposit transaction that is later reorged out of the L1 chain, then the L2 would have to reorg as well to avoid a double-spend, but most L2s are committed to never having to reorg.

Currently only some chains wait for finality before processing a deposit transaction, which is the gold standard for avoiding sequencer reorgs. Some use a \(\kappa\)-deep heuristic of waiting for a certain number of slots, for example, Base uses 14 slots, which is 2.8 minutes. And some use other metrics such as unrealised justification, which is faster than finality, and almost as safe, but still takes several minutes.

One high-performance L2 said that a finality time of tens of seconds "would be huge because those are onboarding transactions".

Transaction pricing

Layer 2 chains want to price user transactions accurately: undercharging is a cost to them, and overcharging is a user experience problem. At least for the Optimistic L2s interviewed, the actual cost of a transaction is set by the price of the blob that gets committed to the L1 chain containing that transaction. The problem is that there are two latencies at play during which the blob price can change. First, for auditability reasons, the block the blob pricing is taken from is tied to the deposit transaction workflow. The gold standard is for this to be a finalised block, making it around 15 minutes old, during which time prices can change considerably. The second latency is that between the L2 including the transaction and posting the blob to L1 - for high-throughput chains this might be only a few slots.

So, transaction pricing risk is dominated by slow finality, and reducing time to finality to tens of seconds would significantly improve the accuracy of transaction pricing for all L2s.

Faster finality helps because layer two learns the layer one blob data price faster. That helps tremendously because you want you want the price to be as close to in-sync as possible between layer two to layer one.

Crosschain messaging

A couple of rollups raised the role of finality in crosschain messaging (interop).

In particular, one ZK L2 offers private chains for institutional users. When these users want to interoperate with other private chains they can't use third-party providers such as solvers and intents as that breaks privacy by introducing an intermediary. Instead, the private chain posts a ZK proof of the transaction to the Ethereum L1, and the receiving chain processes it once it has been finalised. So time to finality is a hard limit for this use case.

The actual biggest thing that [users] want where I think fast finality is really interesting is interop... if we were to solve that it means that we stop everyone looking into Canton or the LayerZero chain because they're offering instant private interop.

Commercial front-end and adoption stakeholders

This group covers both those for whom Ethereum's finality will always be too slow, and those for whom finality time is already fast enough. As such they are not strong stakeholders in our faster finality work.

For example, in the first category, non-custodial point-of-sale payments need to achieve onchain finality within 1-3 seconds (unless they are prepared to absorb reorg losses). Given that Ethereum's block inclusion time is on average six seconds, this seems out of reach at Layer 1. This group might be better served by something like preconfirmations.

From one payment card operator:

For non-custodial wallet flow, where you're basically using a smart contract as the ledgering system, you need faster finality in order to fit into the visa authorization window, which is approximately two or three seconds because there's a few other steps that need to happen.

From another:

The cashier is waiting for the payment to go through and so are 10 typically other people waiting in line... One to three seconds is what people think is normal for a payment, to at least see something happening in the in the terminal... Once it's past three seconds, they really start looking at you and thinking you're a scammer. And eventually they also even remember you that you're the guy with slow payment app.

An example of the second category, where Ethereum finality is already plenty fast enough, is those working towards institutional adoption. TradFi settlement times are often measured in days; onchain finality times measured in minutes are perfectly fine for these users.

In a lot of these markets the time scales are days or weeks for actions to occur rather than minutes, seconds or or even hours or sub-day... If I'm looking at the syndicated loan market, settlement times right now are like 10 to 30 days.

Protocol, staking, client, and research stewards

I consulted this group mainly for their input as effective stewards of the Ethereum protocol. Although they are not particularly affected by time to finality, they have important views on what trade-offs we might consider as we aim to achieve faster finality.

We are consulting directly with client teams in a separate exercise to explore the challenges of implementing faster finality - this will help us avoid pitfalls in the design. However, those interviews are not included here.

Time to finality

This is the big one: how fast is "fast enough"? Codex summarised stakeholder feedback on that question into intervals as follows. The "Stakeholder?" column indicates whether the interviewees in that row are considered significant stakeholders in Ethereum finality, based on the groupings above.

Time to finality	Use cases	Stakeholder?
0.3-1s	Blob confirmation, competitive L2 UX, fast alt-L1 parity	✗
1-4s	Point-of-sale payments, card authorization, gaming responsiveness	✗
10-20s	Cross-chain swaps, bridge transfers, intent routing	✓
Up to ~30s	Deposits, bridging, interactive app flows	✓
<1 min	Research/product minimum for Ethereum to stop feeling obviously slow	✓
1-3 min	L2 deposits, safe-head assumptions, blob pricing, L1 data consumption	✓
~5 min	Light-client / canonical bridge systems where full-node/on-chain verifiability matters	✓
Longer	Current institutional workflows, manual approvals, legacy finance	✗

The good news that we can draw from this is that a time to finality of a small number of tens of seconds will have a meaningful impact on use cases represented in this stakeholder corpus. This seems to be achievable.

Stakeholder comments on time to finality

10 to 15 or 20 seconds I think is the sweet spot for any bridge transfers. — crosschain bridge operator

A finality time of tens of seconds would be huge because those are onboarding transactions. — high-performance L2

If it's more than say 30 seconds, then it might as well be 20 minutes. — gaming-oriented L2

Realistically it can be a few a few minutes maybe; obviously tens of seconds is great. — L2 specialised in provisioning private chains

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. — independent consensus researcher

I would not do this unless it gives us at least an [order of] magnitude degree of improvement. I'm fine with with having an intermediate step, not going all the way to one minute or below in one go, but I think the target should be better than six minutes. — staking service provider

There are people on the team that would like to make it 12 seconds, but I think that's probably not what we need. I think if we get to three minutes that would be good because then we get to simplify our assumptions. If we get it to a minute, amazing. Anything better than three [minutes] feels like gravy. — high-performance L2

Any decrease is good. We don't need to go down to seconds, even one minute is good, two minutes is good, three minutes is okay. — another L2

I think something within five minutes is unnoticeable, but anything more is problematic... A small number of minutes is is tolerable is what I would say. — non-custodial bridge and intents platform (a slight outlier from the general preference of bridges for finality in tens of seconds)

Trade-offs

Validator set restrictions

The context for this part of the discussion was that the easiest route to much faster finality is to drastically cut the number of validators that are participating in coming to consensus.

There are various ways to reduce participation. Consolidation of existing 32 ETH validators onto fewer larger validators is quite benign and uncontroversial.

However, there are more aggressive suggestions. Some view the long tail of small stakers as a problem: they don't objectively add much economic security but disproportionally slow the network by being geographically distributed and having low-bandwidth connections. So we explored "cutting off the long tail". Another proposal has been to impose a cap on the number of validators, say at 128,000, forcing validators to consolidate or be kicked out.

Finally, there are sampling protocols such as Orbit that might be able to finesse the situation, keeping a large validator set, but limiting how many participate at any one time.

The goal was to explore stakeholders' views on Ethereum's validator set size and distribution, and where the felt compromise was reasonable.

Summary

Analysis and stakeholder comments

If it helps to make the network more efficient then it would make sense to incentivize consolidation. — staking services provider

You don't want incentives that favor big big fishes. — independent consensus researcher

It seems that [proposals to force consolidation via a validator set cap] is just an attempt to apply some pressure and the end state will be our good old validator set, but just trying to fix a mistake, or what could be considered a mistake, from the original design of of the beacon chain. — consensus client dev team

I would love to see [the threat of a validator hard cap] used to put the fear of God into people: basically say, well you can consolidate now or you can just be exited. — staking service provider

Ethereum has to be competitive as a payments network... I think the mistake from the beginning was rejecting delegated proof of stake... I think it's fine to concentrate stake in the hands of a thousand to two thousand nodes or thereabouts... If validators become malicious, then they can have their stake redelegated to someone else. — crosschain bridge

Having each validator set geographically close would be something you could do but would be a really bad idea. Having geographic dispersal brings a degree of safety because in some countries maybe all the validators might have been coerced to do something. [Discussion of the Multichain incident as an extreme example]... I think having fewer stakers who've got more skin in the game is ok... [Supporting a long tail of small stakers] is just overly complicating the protocol. Like, if we had a thousand validators I would have thought that could be it. — gaming oriented L2

My biggest worry for Ethereum is that it's this decentralized thing that doesn't get used. I don't think there's a slippery slope [towards extreme centralisation]. I think that the decentralization coalition is sufficiently strong that I don't think that there's a slippery slope risk. I'm comfortable to having a smaller validator set [with a few thousand participants]. — developer of crosschain bridges

I do think Ethereum's big value and moat is that it feels like the most secure, the most censorship resistant. It's not going to get taken down. It feels very safe having your funds on there, and I do think the validator set at 100,000 would still feel very safe. — crosschain bridge

Avalanche was a good example. They had a validator set of 2,000 while achieving one second and for me that was fully good enough. — point of sale payments operator

[Recommending Algorand's model] Rather than traditional BFT it uses round-by-round BFT. A VRF is used to elect committees from the full validator set that choose between multiple proposals per round. I believe this very elegant and allows you to go much faster on the finality side. At the time we had 2 seconds finalization. And you can scale the validator set infinitely. — independent consensus researcher

You can cap active validators and rotate validators out and things like that, but it's very complex. — crosschain bridge operator

If I had to choose between Orbit and just reducing the the set of validators that participates in the head votes, I would go with the latter, even though finality would take longer in this scenario, I would just have the full validator set participate in finality so as not to limit the set of small stakers participating in finality. — staking services provider

Orbit is harder I think from an implementation perspective and it's not clear to me why we would do Orbit instead of just capping [the validator set]. It's not clear to me why orbit is better in that case. — consensus client developer

Orbit with DVT is a possible way to keep smaller stakers involved. — distributed validator developer

Quality of stake - staker diversity, geographical diversity, home stakers scattered around the globe - I think if we compromise on that we're going to lose one of the key distinctives of the Ethereum network. So for sure we need to make life easy for those kind of long tail of validators and we should not try to make things harder for them. — consensus client dev team

I would propose to increase the slashing correlation penalty. That way it would be extremely risky to stake with big staking service providers. Anyone over one or two percent of the network would get all their ETH slashed in any slashing event. — staking service operator

The the home staker matters. Ideally, you will find a way to exploit the trade-offs in more favorable terms [for the home validator]. — independent consensus researcher

I'm a strong believer [in decentralization] because I think blockchain technology is for disaster prevention, like really humanitarian disasters, and preserving the possibility of home staking actually matters. So basically decentralization or just very low barrier of entry I think to me that's the first priority. — high performance L2

I don't think that just removing [small stakers] would be a good answer. I think they do greatly add to the let's say legitimacy of Ethereum, and also from a censorship resistance etc. perspective... These are the things we get from those long-tail, small-stake validators... I think it would not be worthwhile to just cut them off. — cross chain bridge (personal view of one of the participants)

Don't try and compete with Solana or Tempo, right? Because I don't think you're going to win at that... We are buying the decentralization... Obviously we have discussions like, "Hey should we go and be an L1?"... [But] there is no way that we are going to be able to build a blockchain that is sufficiently decentralized... You guys have spent a decade bootstrapping this highly decentralized set of validators, and we get to pay you to leverage that, and we would probably pay more. — high performance L2

I feel like the thing that I value most and am excited about for Ethereum is decentralization and what decentralization gives you. Particularly resiliency and censorship resistance and things like that. Of course, decentralization is also not binary, it's like a scale. — wallet developer

A staking cap would disproportionally affect small stakers and undermine the whole staking landscape. Smaller stakers are already shutting down, leading to more centralization. — staking software developer

Home stakers are important! But we could potentially raise the hardware requirements a little. AI is raising the bar for hardware at home. — solver for crosschain intents

If we put in a hard cap, we risk killing the long tail [of small stakers], we really do. It could be gamed by operators who are like "we don't want these little guys there". It's still a concern that they just crowd out solo stakers right and solo and home stakers feel nervous about this. One comment [I've seen] is if you have a stick, would you please swing it at the people where it matters and not indiscriminately at everyone? — staking services provider

Speculation

Adversarial Tolerance and Economic Security

The context of this part of the discussion was that one potential route to faster finality is to introduce a protocol that has a single voting round, rather than the traditional two rounds, roughly halving the time to finality. A consequence of this might be to reduce the adversarial safety tolerance of finality from the current 33% to maybe 20% or 17%, while also reducing the liveness threshold of finality from 33% to 20% or 17%.

There are different potential designs, and it might be possible to trade finality liveness for safety, or to have a fallback to two voting rounds for those who require higher adversarial tolerance. There are also quite technical nuances around safety levels under synchrony vs partial synchrony that only a couple of stakeholders felt equipped to discuss.

In any case, the goal was to explore stakeholders' views on changing adversarial tolerance thresholds and economic finality (aka accountable safety, that is, mass slashing).

Summary

Analysis and stakeholder comments

My intuition is 15 billion [dollars of economic security] is probably enough. But I would defer to the EF's best judgment. My intuition is like 15 to 30 [percent adversarial tolerance]. I don't know, maybe there's some very complex math here. — high performance L2

Let's look at how much is in layer two bridges. I'm pretty sure it's not even close to that, right? I think that [half of today's economic security] is more than enough. — layer 2 chain

I feel like I'm slightly out of my depth and don't have a strong view, but it doesn't feel like [halving economic security is] a massive change in security properties for a reasonably large gain. — developer for crosschain bridges

I don't really know how to reason about economic finality to be honest. It feels like a finger in the air sort of thing... I don't think [reducing economic safety] would be the end of the world because in practice like the validators have some economic stake in the success of the network, and because of that I am less worried about validators acting maliciously. It just becomes very theoretical around what your threat model is. — layer 2 chain

[Reducing economic safety] feels more palatable than [removing solo stakers] but it I think it's highly use case dependent. I think as the security budget goes down then there are different use cases that you can use Ethereum for. — wallet developer

As a supporter of Ethereum, you're like, "Oh, the number is going down", right? So like I feel I'm like uneasy with that. But if I were starting a network from scratch, I would feel like a fifth, 20%, seems okay. — crosschain bridge operator

One round voting reduces security in the case of a partition [of the network, which is hard to do] but increases tolerance to no-partition coalition attacks... If your threshold is 16% then it will be 84% - that's a huge amount of security. — independent consensus researcher

Sure, if you have [available chain] liveness then I think that's fine... We must have [available chain] liveness no matter what, but we can increase the finality liveness threshold to much higher and make it much faster with one round. — Layer 2 chain

Maybe the network can protect itself from itself by just raising that threshold where things melt down... [On the Holeski testnet] three clients had a correlated bug and that justified the wrong chain which then strands the validators. — staking services provider

If we had those thresholds on [the Holeski testnet], we wouldn't have had that issue because things will be like, okay we we are not finalizing everyone, fix the client and then we are back. I even like 10% - you lose finality if you lose 10% [of attesters]. — consensus client dev team

I believe as you go and talk to people very few people actually understand what you actually mean by economic security... I don't really think the act the actual amount of money matters but I do worry about systematic risks which are bugs coming from staking pools. So decreasing that fraction I think is worrisome because I think there were periods of time when Lido surpassed 33%. — high performance L2

I'm kind of afraid of the further trend if it continues and we now have these asset treasury companies. I think it could be realistic that they reach something like [17% of stake] at some point. Or maybe just Coinbase as a custodian. I think it's a realistic danger that they reach 17%. — staking services provider

I would frame it in terms of the number of parties that actually control that stake. And my understanding is that if we look at major exchanges and staking pools and whatnot, they might well control with very few parties in excess of 20%. So I think that would be potentially concerning. — crosschain bridge operator

One-sixth adversarial is way too tight. [A staking protocol] runs 15% of validators - they could be subject to an accidental or malicious key leak. — staking software developer

Ultimately safety is more important than than liveness, I would claim, for most applications in our site. — crosschain bridge operator

I would first do all the other improvements with current 2-round approaches and security guarantees and once reaching the "finality in seconds" magnitude, would consider the improvement of factor of 2 (e.g., 24 vs 12 seconds) at the expense of security assumptions. Adding [one round finality] as an intermediate step is a bit risky and with not so clear benefits. — staking services provider

[Institutions] care about security. They don't necessarily have the terminology or the framework to know what economic or cryptoeconomic security is, but they do have enough of a lens to parse something that looks and feels like a consortium or company run infrastructure versus something that in their minds feels more distributed, decentralized, resilient, global, not controlled by anyone. — organisation bringing institutions onchain

Not all finality is equal, but then it's like going to like these enterprises and somebody be like, "oh you know I have 500 millisecond finality", and then that gets stuck in their head and they're like, "oh they have really fast finality", and they don't, and then it's like really hard to explain all the nuance. — layer 2 chain

Most exchanges are not using Casper finality... I just really wish that people actually understand what the merge means. — high performance L2

I don't have a good feel for how dangerous [changing the economic safety threshold] would be. I would need to spend a fair bit of time understanding it to get a good feel. — gaming-oriented L2

Speculation

The Available Chain

Although not directly in scope for the faster finality study, the topic of Ethereum's liveness was frequently raised by stakeholders. So consider this a kind of (largely AI curated) appendix that summarises the range of views on this.

There are consensus designs that favour finality over liveness. In fact most proof of stake chains do this: if finality is not achievable, the chain will halt entirely. Ethereum has historically taken a different path, coupling together an available chain that keeps producing blocks with a finality gadget that makes best-efforts to finalise them - a so-called Ebb and Flow protocol.

This available chain/finality gadget distinction is quite fundamental to our consensus design, so it was useful to get some feedback on it. None of the following was specifically prompted, but arose organically in discussion of Ethereum's properties.

Summary

Part 1: Uptime And Reliability As A Product Or Adoption Value

Direct Evidence

The fact that it is infrastructure that's "never gone down", [institutional clients] eat it up. It's really nice value proposition, the resiliency of how both availability and consensus have been architected and are multiclient. — institutional adoption

If they put $100 million workflows and trillion dollar markets on Ethereum and their transactions stop going through as they expected them to, even if they were paying market rates, that would be very bad. That is not what they expect; they expect much more in terms of the quality of service and guarantees of the infrastructure for their transactions. — institutional adoption

There was a period when [other chains] were halting and we were trying to hand wave over the the problems of crypto in general. We're like, well, it happens once in a blue moon and you kind of like accept that this can happen. But you know, it's much rarer on [Ethereum] mainnet. — wallet developer

It's a good marketing story that you can say, Ethereum is that thing that never goes down. I can pack that up and say, hey guys your credit card systems they're not that reliable as you always keep telling us, they're actually down quite a lot. — payments platform

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

I feel like the the thing that I value most and I am excited about Ethereum foremost is decentralization and what decentralization gives you particularly resiliency and censorship resistance and things like that. — wallet developer

I actually have strong opinions here. I really think Ethereum is unique in the sense that it's decentralized really... I really think it's a public good. And the more decentralized, the more resilient it is, the the better really. — high performance L2

[Quality of of stake means] diversity in terms of resilience of the network. This is essentially the definition of resilience. Uptime technical resilience, but also not being under the same jurisdiction. — consensus client team

Speculation

Part 2: Finality Liveness, Available-Chain Liveness, And Safety Nets

Direct Evidence

The way I see is that we must have [available chain] liveness no matter, but we can increase the finality threshold to be much higher and then make the finality much faster so that it's one round because I think it's a spectrum and we should optimize for the very happy case and then as long as it's not happy we should go to the worst case, something like that. We shouldn't do so much in the middle. — consensus client dev

Maybe the network can protect itself from itself by just raising that threshold where things melt down... [On the Holeski testnet] three clients had a correlated bug and that justified the wrong chain which then strands the validators. — staking services provider

My personal prediction is if [an incident like the Holesky testnet bad finality] happens on Mainnet we have a civil and culture war on our hands and Ethereum just tanks. This is not a thing that should happen to the mainnet. — staking services provider

It seems like a sweet spot because we exchange faster finality for [lower finality] liveness and lowering down the the uptime of the finality a little bit... I'm more comfortable going in that direction because I'm pretty sure if for some reason we finalized the wrong thing on Mainnet we would need to decide what to do, and any outcome would be extremely expensive. — consensus client team

So you mean the available chain and the finality chain, right? Yeah, absolutely. For Ethereum, I think it makes sense and and I want Ethereum to win... The top of the hierarchy needs to be something that is very resilient and you need this finality separation I think for that. — independent consensus researcher

Speculation

Part 3: L2 And Application Reliability Dependencies

Direct Evidence

When [our chain] was launched, the promise was we will never reorg. We will halt the chain before we reorg. — high performance L2

Prolonged censorship on the layer one will force the layer two to stop... Basically liveness of the layer 2 requires the layer 1 to be live, as in being able to post transactions back to the layer one... Layer one liveness is actually extremely important to us. We worry a lot about it and for that reason we extended our sequencing window to multiple days just to cover the extreme case. — (different) high performance L2

A chain operator can greedily start including those deposits as soon as possible, but then they are basically exposing the chain to reorgs, and the chain will reorg with L1. But different chains operate with different latency. — optimistic layer 2

With the OP Stack you can set the use-finalized option then you are guaranteed that (unless you have a sequencer window level failure) you will not have any reorgs on L2. So having tighter finality on Ethereum would mean that when we're using finalized, rather than it being potentially 12 minutes or something like that, it might be seconds which would be absolutely awesome. — gaming-oriented L2

A lot of [enterprise/institutional users] have told us that the L2 finality is actually legally okay, which was a surprise because that's not how we usually talk about it as crypto natives. [But we have] single slot finality on the L2: it can get down to 1 second block time. And they said, "Great, we'll take that as legal finality." So like they're happy to take that, but also they're trying to understand if L1 finality is better from a risk perspective. — ZK layer 2

We provide a venue for third party people who can take on finality risk and essentially loan to users the funds up-front... Depending on the size of the transfer, they might be willing to take on more finality risks. — crosschain bridge

Solvers are always at risk from non-finality to some degree, not a dramatic amount. — solver infrastructure

[There's an impact of finality] for intents and solvers, people who are providing like liquidity up-front, who are then having to lock capital either side of a bridge, then you get out of balance and you're rebalancing and you're waiting for finality. — crosschain bridge developer

Speculation

Part 4: Limits, Dissent, And Conservative Settlement Views

Direct Evidence

I'm not super fan of dynamic availability because I cannot see the value of having a chain that is not finalized even though it's still producing blocks... [re tokenized bonds] If people are happy to take this risk then it's fine, but from a real world perspective it's really the value of a dynamically available chain is limited in my opinion. It's cool to say that, yeah the chain is still up and running and is working, but it's not finalized. I don't see any additional value there. — independent consensus researcher

Today [our] protocol does wait for full finality... This is a security stance that we've taken many years back and have continued to do so until this point... [We are] working on a release that allows for some customization of the finality configurations by a token issuer, meaning that they can define the number of block confirmations that they would want to wait for, while the default is still full finality. — crosschain bridge operator

Ultimately safety is more important than than liveness, I would claim, for most applications in our site. — crosschain bridge operator

Speculation

Closing Remarks

This has not been a perfect exercise, and there are things that I'd do differently if I ran it again. But it has definitely been fascinating to gather a broad range of input from people who are building on Ethereum. I recommend it!

I am aware of some gaps I would like to have covered (for example, the importance or otherwise of validator anonymity) and good ol' ChatGPT has chided me about a dozen more.

But one of the biggest outstanding questions for me is for bridges and solvers: what would the cost curves for liquidity look like with finality at 15 minutes, 5 minutes, 1 minute, 20 seconds?²

Anyway, this process has already shaped our fast finality roadmap, and I believe that it provides strong support for our current design and direction of travel. We expect that we will be able to deliver a time to finality measured in a few tens of seconds, and the key result of this study is that finality on that timescale would benefit a good range of important stakeholders.

I am deeply grateful to all of the stakeholders who so generously shared their time and insights for this exercise. Many thanks to Roberto Saltini for review and helpful feedback.

Footnotes

1. Any opinions and conclusions represent my personal view as cat-herder for fast finality rather than any "official" plan or roadmap. Everything is, of course, subject to Ethereum's governance process. ↩

2. It's not too late! If you have this info or similar models, please contact me. ↩