Finality is a Lie (That We All Agree On)

By Alejandro Ranchal-Pedrosa

Abstract

Finality in blockchains is often presented as an objective milestone, but in practice it is a spectrum of trust assumptions that vary by protocol, observer, and economic context. This article contextualizes finality as credible commitments made by some credible commitment machine, and surveys how different systems instantiate finality with distinct guarantees and trade-offs. We argue that the only honest question about finality is: under which assumptions, and at what cost to break?

TL;DR: Finality FAQ

As a TLDR, we start by answering common questions and misconceptions about finality and how users must deal with it, since it is by now an overloaded word. Feel free to skip this section and continue with the Intro to the article.

Q: Can the Fast Confirmation Rule fast-confirm something different from what gets finalized by the Gasper finality gadget?

Yes. FCR provides deterministic confirmation in ~13 seconds under synchrony with at most 25% Byzantine stake, a different and weaker set of assumptions than the finality gadget's ~18-minute guarantee, which holds under asynchrony with up to 33% Byzantine stake (and up to ~66% in the best-case synchronous path). If synchrony breaks for just 13 seconds (via a network partition or an eclipse attack on a subset of nodes) or if more than 25% of stake misbehaves, a fast-confirmed block can be reorged. FCR is best understood as a strong preconfirmation with proven safety properties, not as a replacement for finality.

There is also a subtler concern: Ethereum has never been completely asynchronous precisely because nothing consequential was staked on a 13-second window, so there was no incentive to induce one. Now that there is, the incentive to induce such events exists for the first time. A 13-second eclipse attack — where an adversary controls all of a node's peer connections, cutting it off from the honest network — is a concrete example: safety shifts from the protocol layer to the networking layer, and the synchrony assumption FCR depends on is only as strong as each node's peer connectivity. The assumption that the network "has never been asynchronous" should therefore be read carefully. The guarantees are reasonable; they are just not the same as the assumptions backing the finality gadget, and calling FCR "finality" risks obscuring that difference.

Q: Can finality be reverted even after it's "deterministic"?

Yes. Deterministic finality means reversal requires violating the protocol's assumptions, not that reversal is physically impossible. Social forks (such as the DAO), correlated validator failures, or bugs can all revert "deterministic" finality. The word "deterministic" describes the protocol's logic, not reality.

Q: Does more stake always mean more security?

Not if the stake is concentrated or other assumptions/products make the protocol less secure. A chain with $50B staked across 3 entities is easier to corrupt than one with $10B across 50 independent operators. Economic security and decentralization measures like the Nakamoto coefficient or network assumptions are both needed, the former measures the cost, the latter measures the coordination difficulty. A chain that tolerates 20% of the stake misbehaving may be less safe than one that tolerates 33% even if it has more stake. Restaking or network assumptions can also challenge this idea.

Q: Is restaked ETH securing my transaction as strongly as native-staked ETH?

No. Restaked collateral is pledged to multiple obligations simultaneously. If the aggregate profit from attacking all co-secured services exceeds the validator's stake, the collateral is effectively diluted. As of early 2026, ~13% of Ethereum's staked ETH is already restaked through EigenLayer alone.

Q: My chain claims "instant finality." Is that real?

It means the protocol commits in one round with no separate confirmation period. But "instant" still depends on the fault model, the stake backing it, and the network assumptions. A 200ms commitment from 1 validator is instant and weak; a 400ms commitment from 40 validators with 2 rounds of voting per commitment is slightly slower and far stronger.

Q: Isn't finality just about speed?

No. Speed is latency to commitment; finality is credibility of that commitment. More latency usually implies more credibility though. The interesting question is always: what does it cost to break, and under what assumptions?

Q: A rollup of Ethereum says my transaction is final after 5 seconds. Does this mean the economic security of my transaction is equal to a transaction that is final on Ethereum?

No. At the 5-second mark, your transaction has been included by the rollup's sequencer and perhaps sent to L1, but Ethereum's finality gadget has not yet certified it (that takes ~18 minutes), and if the rollup is not Stage 2 (none are so far), the security council (about a dozen entities) could potentially push invalid state or revert. Your transaction inherits the trust of the rollup's sequencer and security council, not the full economic security of Ethereum's validator set.

Q: Do rollups inherit Ethereum's security?

Eventually, partially. Before proof verification and L1 finalization, a rollup inherits its own trust assumptions (sequencer, security council). Even after, Stage 0–1 rollups have upgrade mechanisms that bypass Ethereum's security. Only a Stage 2 rollup with a verified and finalized proof on L1 fully inherits Ethereum's economic security (except for negligible assumptions like code bugs).

Q: What are preconfirmations, and are they "final"?

Preconfirmations are early commitments issued before a protocol's full finality pipeline completes, typically by a single validator, a committee, or a sequencer. Their security depends entirely on what backs them: a preconf from a single validator with small stake is weaker than a preconf from a decentralized sequencer with reputation at stake. The word "preconfirmation" at least honestly signals that something stronger is coming; the danger is when systems market preconfs as finality without qualifying the difference (as most rollups do).

Q: What does a Stage 2 rollup's finality actually inherit from Ethereum?

A Stage 2 rollup with a validity proof verified and finalized on L1 inherits Ethereum's full economic security: reverting the rollup transaction requires reverting the L1 block that contains the verified proof, which requires corrupting ≥1/3 of Ethereum's validators. Before that point (Stage 0–1, or before proof verification), the rollup's finality depends on its own trust assumptions (sequencer, security council, proof generation latency), which are strictly weaker.

Q: Does faster finality mean better finality?

Not necessarily. Faster finality is better only if the security model behind it stays the same or improves. A system that achieves 150ms finality by relaxing fault tolerance from 33% to 20% has made finality faster and weaker. A system that achieves 400ms finality under classical 3f+1 BFT has made finality fast and kept the same security model the field has studied for decades.

Q: Is the n = 5f+1 model a breakthrough where economic security stays the same but latency decreases?

No. The n=5f+1 maximizes Byzantine fault tolerance in one round of voting without synchrony for safety, whereas the n=3f+1 maximizes Byzantine fault tolerance without synchrony for safety. For the same total stake S, a 3f+1 protocol tolerates up to S/3 Byzantine stake (≈33%), while a 5f+1 protocol tolerates only S/5 (≈20%). That is roughly a 40% reduction in the economic cost required to break safety. The latency improvement (two consensus steps instead of three) comes at the price of narrowing the adversarial region the system can withstand.

Q: Are there any security advantages to the 5f+1 model?

Yes. There are two ways to revert BFT finality: exploit network delays to trick honest validators into signing conflicting blocks (partition-based), or corrupt enough validators outright (direct corruption). The 5f+1 model is cheaper to attack via partitions (~20% vs ~33% of stake) but far more expensive via direct corruption (~80% vs ~67%).

Critically, partition-based attacks require sustained network control — each additional block the observer waits makes them less and less likely. Direct corruption does not depend on network control. Assuming probabilistic synchrony, direct corruption becomes the more likely attack after enough time, at which point 5f+1 is 20% more secure than 3f+1. The lower fault tolerance is a transient vulnerability that waiting washes out; the higher corruption barrier is permanent. This is the BFT analogue of Bitcoin confirmations.

Q: If finality is broken (two conflicting blocks are finalized), what happens?

It depends on the protocol. Most deployed BFT chains have no built-in recovery mechanism — they rely on social coordination to resolve the fork. It is however possible for the protocol to heal itself without immediately relying on social coordination [34], thanks to accountability proofs to identify and exclude guilty validators, then reconciling the conflicting transaction sets so that no honest user loses funds. Dynamically available chains also prescribe a fork-choice rule to automatically resolve conflicting branches, as they do not have deterministic finality.

Intro

"Bitcoin transactions can be sufficiently irreversible in an hour or two"
— Satoshi Nakamoto

From the beginning of blockchains, finality has been a contentious topic for which different people have different views. The problem also predates blockchains and goes at the core of what something secure means. In general, security does not mean something is unbreakable, but rather that, under the assumptions that we are dealing with, something will not break. There is no unbreakable system, only a system in which the cost to break it is too high (Byzantine model), or higher than the assumed benefit of it under the given assumptions (rational model).

Finality is not always the same event for everyone. It is a ladder of increasing credibility in a commitment, where different actors stop worrying about reversal at different rungs, sometimes long before or after the protocol's strongest notion of "finalized".

Consider Ethereum. Almost no one (application or user) waits for formal finality of L1 (~18 minutes). Users and applications behave as if transactions are "final" long before cryptoeconomic finality is achieved, and they do this as if the transaction was already ensured by Ethereum. Even if everyone waited for the same event, what does "final" even mean when every protocol makes distinct assumptions to assert its commitments? Is it the same meaning if Ethereum switches their finality gadget to tolerate 20% faults instead of 33% (as many are doing currently)?

Even in traditional finance, settlement finality is explicitly defined as a legal and procedural property (an irrevocable and unconditional discharge of obligations) because the world recognizes that "final" is ultimately an institutional boundary, not a metaphysical fact [1]. Blockchains try to push that boundary closer to absolute truths (like laws of physics) by reducing trust, but they cannot eliminate it. The "lie" is pretending finality is a Boolean.

In the following, we detail the different levels of finality that a user in web3 experiences, the implications of different trade-offs to the meaning of finality, and Sei's finality definition and rationale.

Finality in the Wild

The Finalities of a Transaction

Imagine Alice is using a non-custodial card by Neobank "Neo", whose payments are placed in zk-rollup "Zktrum". Consider the journey of a payment and the distinct stages of finality that it reaches. There are many steps at which the payment could be considered "final" by Visa/Merchant:

1. Pure trust: Alice says not to worry, she will pay (e.g. credit cards).

2. Web2 level: Neobank's server approves and forwards payment to the rollup, confirming sufficient balance.

3. Rollup preconf: Rollup's sequencer says the transaction was included in the rollup. If the rollup is decentralized and runs a consensus subprotocol, one could speak here of rollup finality.

4. Probabilistic off-chain finality: The rollup state containing the transaction is included in a transaction on Ethereum's L1 available chain as more blocks are appended, burying the transaction in blockdepths (12 seconds to 18 minutes depending on depth). Anyone can locally verify the state of the rollup by running a full node, getting Ethereum-level probabilistic finality. The Ethereum Foundation's Fast Confirmation Rule (FCR) can reduce this wait to ~13 seconds, but under stricter assumptions: synchrony must hold and no more than 25% of stake may misbehave (versus the 33% threshold of the finality gadget). A fast-confirmed block that meets these conditions will be finalized with certainty; if they fail, it may be reorged.

5. Off-chain finality: Ethereum's finality gadget certifies finality of the commitment (~18 minutes from commitment), requiring no synchrony assumption and tolerating up to 33% Byzantine stake. This is what FCR fast-confirms toward, not replaces.

6. Probabilistic on-chain finality: The rollup sequencer generates and submits a validity proof for the rollup state containing the transaction (~1 hour + 12 seconds to 18 minutes). FCR similarly applies here, compressing the probabilistic window to ~13 seconds under synchrony. This is the point where Ethereum-level probabilistic finality is obtained for those not running a full node of the rollup.

7. On-chain finality: The generated proof is finalized on L1 (1 hour + 18 minutes from inclusion in L1). At this point, only an Ethereum fork can remove this transaction.

A note on FCR's assumptions. The Ethereum Foundation presents FCR as safe for large asset transfers because Ethereum has never been completely asynchronous, and a 25% stake adversary would cost ~$22B at today's prices. This is reasonable — but there is a subtlety worth flagging: Ethereum has never been vulnerable to 13-second windows of full asynchrony precisely because no meaningful commitment depended on that window. Now that one does, the incentive to induce such events exists for the first time. The assumptions backing FCR are sound in expectation; they are not the same as the assumptions backing the finality gadget, and labeling FCR as "finality" risks overloading a term that already carries a precise meaning.

The above is for a Stage 2 rollup. As of the most recent L2BEAT data, no general-purpose rollup has reached Stage 2; major rollups like Arbitrum One, Base, and OP Mainnet are listed as Stage 1 [12]. For Stage 1 and below, 75% of the security council (comprised of about a dozen entities per rollup) could potentially push invalid messages or revert state. This means that off-chain and on-chain finality are not fully inheriting the guarantees of Ethereum finality. Rollup upgrades pushed by the security council do have to go through the delay window (e.g. 7 days) in Stage 1 rollups. Stage 0 does not require any security council or delay window, a single entity can be in control of everything.

At each of the steps it is possible to revert the payment, but each step requires a stronger adversary to do so. Greater steps take more latency to finalize as well. Observers (neobanks, users, Visa) decide which step is credible enough to treat as "final." In practice, neobanks live on rollups and their cards perform at the same speed as regular bank cards without any limit on users or total volume, meaning that step 2–3 is the level of trust Visa (as the recipient that takes the risk) plays with. It seems reasonable for a merchant to accept steps (1-2) if Alice is paying for a Coca-Cola, steps (2-3) in most cases except large payments, but require (5-7) for purchases of a yacht or a multi-million dollar acquisition. Finality depends on the volume of the transaction, and yet no rollup explicitly mentions this.

Formalizing Credible Finality

"Ideally, the commitment is a device that leaves the victim no loop-hole... If the commitment is 'automatic', or if it is delegated to a machine or a fanatic... the threat is made credible."
— Arms and Influence, Thomas Schelling, 1966

At its core, finality is the belief in a commitment (a point where an observer assigns sufficiently high confidence that a commitment), made by a committer, is credible (irrevocable). Blockchains are, in essence, credible commitment machines:

A credible commitment is a strategy or announcement that an agent makes, where deviation from the commitment is costly or infeasible, and so others can reliably predict and depend on it [2].

But perfectly fair and tamper-proof, democratic commitment machines are provably impossible without idealized primitives. We would need untamperable, verifiable perfect broadcast and untamperable, verifiable biometrics. The former to bypass a result from Halpern and Vilaça on fair consensus [3]: no fair consensus protocol can be an ex post Nash equilibrium if even a single crash failure is possible, even in synchrony. The latter to bypass Sybil resistance mechanisms that can be gamed with more power or money [4]. The best available human-made construction to reduce trust that we know of are called blockchains:

A blockchain state transition is final relative to an observer when reverting it would require violating the observer's assumed model of the world (protocol assumptions, economic assumptions, and social recovery assumptions), or paying a cost the observer considers implausible.

This definition is intentionally observer-relative. As brilliantly put by Ittai Abraham, Vitalik Buterin, and Luca Zanolini, finality is in the eye of the beholder [15]. The strongest version of "final" would require something close to common knowledge ("everyone knows, everyone knows that everyone knows, …") that a commitment cannot change. But results from Halpern and Moses show that true common knowledge is not attainable in realistic settings with imperfect communication and timing [16], and that coordination often relies on approximations of it.

Finality is the level of confidence you can justify, not the level of confidence you can market.

Check back for Part 2