Faster Than Finality: Comparing Ethereum’s Emerging Confirmation Guarantees
Research Competition
Comparing Preconfirmations, the Fast Confirmation Rule, and Protocol Finality — and Why Faster Settlement Still Can’t Prove Human Intent
Ethereum usually includes a transaction in a block within seconds, while protocol finality takes roughly 13 to 15 minutes under normal conditions. That gap has created demand for mechanisms that provide usable assurance earlier. The most prominent are preconfirmations, the Fast Confirmation Rule (FCR), and research toward faster protocol finality. They are often discussed together even though they do not provide the same guarantee. This paper compares them across six dimensions: latency, type of assurance, security basis, trust dependencies, failure behavior, and deployment maturity. It finds that preconfirmations provide an economically or operationally backed promise before consensus settles; FCR derives a conditional confirmation from validator attestations; and protocol finality provides cryptoeconomic irreversibility through Ethereum consensus.
Confirmation speed therefore cannot be evaluated independently of what an application needs to be true. An exchange deposit, a rollup bridge, and a high-value settlement may rationally accept different guarantees. The paper also argues that faster settlement does not solve transaction authorization. Consensus can establish that Ethereum accepted a transaction, but not that a human understood or intended it. This creates a separate trust boundary between secure authorization and secure settlement.
Keywords: Ethereum, finality, preconfirmations, Fast Confirmation Rule, consensus, self-custody
1. Introduction
Ethereum separates transaction inclusion from finality. A transaction can be included in a block after one 12-second slot, while the block normally requires a much longer validator-voting process before it is finalized. Ethereum.org currently describes finality as taking about 15 minutes and defines it as the point at which altering or removing a block would require burning at least one-third of total staked ETH [1].
For many applications, that delay is operationally expensive. Exchanges must decide when deposits are safe to credit. Bridges must decide when an L1 event is reliable enough to trigger an action on another system. Rollups may want earlier certainty about deposits or state commitments. Trading and liquidation systems can operate on timescales where waiting for finality is not practical. These systems therefore rely on earlier signals of safety, including block depth, sequencer promises, local risk thresholds, or external commitments.
Three approaches now receive particular attention. Preconfirmations allow a proposer, sequencer, or committee to issue a signed promise about future inclusion or execution before Ethereum finality. FCR observes validator attestations and can mark a block as confirmed within roughly one slot when defined network and adversarial assumptions hold. Protocol-level faster finality changes the consensus process itself so that Ethereum can reach its strongest settlement guarantee in seconds rather than minutes. Single-slot finality (SSF) was the best-known version of that objective, but Ethereum’s current roadmap says research has moved through three-slot finality and now continues through Minimmit and the wider Lean Ethereum consensus program [2].
Treating these mechanisms as direct substitutes obscures the fact that they provide different guarantees. Lower latency can come with narrower assurance, while stronger guarantees may exceed what some applications require. A preconfirmation can arrive before consensus but depends on the credibility and enforceability of the party making the promise. FCR relies on Ethereum’s validator set but does not provide the same cryptoeconomic guarantee as finality. Faster protocol finality offers the strongest settlement assurance but requires deeper changes to Ethereum’s consensus architecture.
This paper asks: How do Ethereum’s emerging fast-confirmation mechanisms trade latency against security, trust assumptions, and failure risk, and when can an early confirmation reasonably substitute for protocol finality?
The central argument is that these mechanisms should be evaluated as distinct assurance models rather than as interchangeable ways to make confirmation faster. A preconfirmation relies on an enforceable commitment about future inclusion or execution. FCR derives a conditional canonicality guarantee from observed validator attestations. Protocol finality supplies Ethereum’s strongest cryptoeconomic settlement guarantee. The paper first defines the terms and comparison criteria, then analyzes each mechanism and applies the framework to different application risk profiles before separating settlement assurance from transaction authorization.
2. Analytical Framework and Definitions
This paper uses comparative protocol analysis to evaluate three approaches to reducing the waiting time before an Ethereum application can act with defined assurance: preconfirmations, FCR, and protocol-level faster finality. The unit of comparison is the proposition each mechanism allows an application to rely on at the time it acts, rather than latency alone.
Primary sources include Ethereum protocol documentation, consensus specifications, Ethereum Foundation roadmap material, Ethereum Research discussions, implementation documentation, and the July 2026 Fast Confirmation Rule paper by Saltini et al. Deployment and research status is assessed using material available as of August 2026. Where an approach remains experimental, theoretical protocol properties are separated from implementation or deployment claims.
Confirmation latency is the time required before the mechanism can supply its stated assurance. Assurance type identifies what is actually being claimed: future inclusion or execution, canonical-chain stability under stated conditions, or protocol finality. Security basis identifies the evidence supporting that claim, including operator incentives or collateral, observed validator attestations, or consensus-level slashable stake.
Trust dependency records which parties or systems must behave correctly or remain available beyond ordinary Ethereum consensus. Failure behavior records what occurs when those assumptions fail: a broken commitment, a confirmation rule that stops advancing or reorganizes under assumption-breaking conditions, or finality that stalls because a supermajority cannot be formed. Deployment maturity is treated separately so that a research result is not presented as a production guarantee.
For this paper, an early confirmation is sufficient only relative to a specified application action and its cost of error. The analysis is limited to Ethereum L1 and rollup systems that ultimately depend on Ethereum settlement. It does not independently benchmark clients, estimate the probability of adversarial conditions, or price the economic value of latency. Empirical FCR results are used only as observations from the published test period, not as estimates of future reliability.
3. Background: Ethereum Confirmation and Finality
Ethereum proof-of-stake consensus combines fork choice with finality. LMD-GHOST determines which chain head validators should build on, while Casper FFG finalizes checkpoints after sufficient validator attestations. A block can therefore become the canonical head before it becomes finalized.
For purposes of this comparison, inclusion means that a transaction appears in a proposed block; canonicality means that fork choice currently selects a chain containing that block; and finality means that Ethereum has reached the protocol state in which reverting the block would require slashable consensus failure. These states can occur at different times. Under normal operation, a proposer publishes one block in a 12-second slot, while finality requires the later supermajority voting process.
Most users do not notice this distinction because wallets often display a transaction as successful after inclusion. Infrastructure providers do notice it because they must decide when to take an irreversible action based on that transaction. The relevant threshold depends on both time and the consequence of acting on a signal that later proves unreliable. A small exchange deposit can tolerate a different risk threshold from a bridge releasing a large amount of collateral. A rollup may accept a short-lived reorganization if its own state can reorganize consistently. A custody system executing a large irreversible withdrawal may require finalized L1 state.
For applications, the practical problem is selecting an assurance threshold that matches the action at stake. The goal is to identify the earliest point at which the available evidence becomes strong enough to justify that action. Preconfirmations, FCR, and faster finality move that point forward in different ways.
4. Preconfirmations
A preconfirmation is a commitment made before the relevant block is finalized. In proposer-based designs, an upcoming proposer or delegated preconfer can promise transaction inclusion or execution before the completed block is published. Recent research distinguishes inclusion preconfirmations, which promise that a transaction will appear, from execution preconfirmations, which can also constrain ordering or execution conditions [6][8].
A signature alone does not make a preconfirmation credible. Its strength depends on the consequences of violating the commitment, which may come from collateral, reputation, future order flow, or another enforceable penalty. Early based-preconfirmation proposals therefore use additional enforcement or slashing conditions outside Ethereum base consensus. A proposer opts into the system, signs a commitment, and can be penalized if the commitment is provably violated [6][7].
This model can provide much lower latency than Ethereum consensus because it does not wait for the whole validator set. It asks a narrower question: will the actor with relevant sequencing or proposal authority honor this specific commitment? The user receives an assurance about future behavior, not a statement that Ethereum has already finalized the underlying state.
Security therefore depends on incentive alignment. If violating a commitment creates more profit than the penalty for violating it, the preconfirmation is economically weak. Committee-based approaches can distribute the commitment across multiple operators, reducing reliance on one preconfer but increasing coordination requirements and system complexity [9].
Preconfirmations also introduce dependencies that Ethereum finality does not have. Middleware can fail. The relevant proposer may not participate. A delegated preconfer can be unavailable. Different systems may use different penalties, collateral types, and dispute mechanisms. Applications must therefore evaluate both the promise and the mechanism enforcing it.
These limitations narrow the set of applications for which preconfirmations provide an appropriate assurance model. They are useful when an application needs a very fast credible commitment and can accept a guarantee that is narrower than finality. Examples include predictable inclusion, low-latency rollup sequencing, and applications where subsecond responsiveness has operational value.
Preconfirmations function as application- or sequencing-layer assurances that make the period before finality more useful without turning an unfinalized Ethereum block into a finalized one.
5. Fast Confirmation Rule
FCR does not rely on a separate operator making a promise. Instead, a consensus client observes Ethereum validator attestations and applies a local rule to determine when a block has enough support to be treated as fast-confirmed.
The formal FCR analysis treats the rule as complementary to FFG finalization rather than as a replacement for it. Under synchrony and the paper’s stated assumptions, including a Byzantine-weight bound below 25%, the rule can confirm a block in the best case after one 12-second slot [3][13]. Finalization remains the fallback guarantee for periods in which the stronger synchrony assumption cannot be relied on [13].
FCR is a client-side confirmation rule rather than a consensus fork. A node evaluates attestation support already present in its local view and exposes an earlier confirmed or safe block signal without requiring a separate middleware network [4][13]. This makes the mechanism deployable at the client layer while leaving FFG finalization unchanged.
This gives FCR a stronger connection to Ethereum consensus than proposer preconfirmations because its evidence comes from validator attestations rather than an external commitment. However, it is still not equivalent to finality. The Ethereum specification states that if the synchrony assumption is broken, a fast-confirmed block can be reorganized without adversarial behavior and without slashing [3]. FCR’s own documentation likewise says that the rule has no economic-security layer comparable to Casper FFG [4].
The distinction is important because protocol finality is protected by an economic penalty for conflicting validator behavior. FCR provides a deterministic guarantee only under its stated network and adversarial assumptions. It is therefore more formally grounded than an arbitrary “wait for k blocks” policy, but weaker than finality.
Saltini et al. also report an empirical evaluation over approximately 26 hours of Ethereum mainnet data. In that observation window, 94.67% of blocks satisfied the rule within one slot, 98.87% within two slots, and all observed blocks within eight slots [13]. The authors note that no adversary was actively trying to delay confirmation during the test, so the result should not be read as an adversarial reliability estimate [13]. As of August 2026, FCR also remains under active client integration and testing, with work continuing across Lodestar, Lighthouse, Prysm, and Teku [4][5].
FCR fits applications that already rely on Ethereum’s validator set and need a much earlier L1 signal, provided they can tolerate the rule’s assumptions. Exchange deposits, L2 deposits, and some bridge operations fit that profile better than high-value actions that require unconditional protocol finality.
6. Protocol-Level Faster Finality
The strongest way to reduce waiting time is to change finality itself. SSF proposed collapsing Ethereum’s multi-epoch process so that a block could be proposed and finalized in the same slot. SSF was intended to make the strongest protocol guarantee arrive sooner rather than create an intermediate confidence signal.
SSF also illustrates why this is difficult. Ethereum has a large validator set. Finalizing a block inside one slot requires enough validator messages to propagate, aggregate, and be processed quickly enough for a supermajority decision. Ethereum.org frames the problem as a tradeoff among finality time, computational overhead, and decentralization [1]. Faster finality is therefore not simply a matter of shortening a timer.
Ethereum’s research direction has moved beyond SSF as a single design target. The current security roadmap states that work progressed from single-slot finality to three-slot finality and now continues through Minimmit, a one-round consensus protocol in the Lean Ethereum program [2]. The long-term goal is finality in seconds. Ethereum Foundation funding in Q2 2026 included Lean Consensus client work such as Ream, described as targeting fast finality and four-second slots, together with related consensus-client and testing work [12].
This work remains research rather than a scheduled mainnet upgrade. Ethereum.org states that no faster-finality upgrade is currently assigned to a fork [2]. The direction is visible, but the eventual protocol, deployment sequence, and timing are not fixed.
Protocol-level faster finality has one decisive advantage over the other approaches. If successfully deployed, it changes the base-layer guarantee itself. Many applications would no longer need to decide whether a preconfirmation or fast-confirmation signal is “good enough” for transactions that can wait a few seconds because Ethereum’s strongest assurance would arrive much earlier.
Its weakness is implementation cost and timeline. A consensus redesign must preserve safety, liveness, decentralization, validator accessibility, and upgrade compatibility at Ethereum scale. That makes it slower to deploy than a client-side confirmation rule and less flexible than an opt-in preconfirmation service.
7. Comparative Results: Assurance, Failure, and Application Fit
Applying the framework produces an ordering of assurance strength, but not a universal ranking of mechanisms. The mechanisms differ because they reduce waiting time by changing different parts of the trust model.
Preconfirmations minimize latency by narrowing the claim to an enforceable commitment from a proposer, sequencer, or committee. FCR moves the evidence into Ethereum’s validator set and can establish canonical-chain stability under its synchrony and adversarial-weight assumptions. Protocol finality provides the strongest settlement assurance because its security is tied to Ethereum’s slashable consensus stake.
The practical result is that a faster signal is useful only when its failure model matches the action that follows. An application accepting a preconfirmation must evaluate the authority behind the promise and whether the penalty for violating it is credible. An application accepting FCR must be willing to rely on the rule’s network and Byzantine-weight assumptions. An application waiting for finality accepts more latency in exchange for Ethereum’s strongest cryptoeconomic guarantee.
The mechanisms also fail differently. A preconfirmation system can lose availability because the preconfer or middleware is offline, and it can become economically unsafe if the penalty for breaking a promise is too small. FCR can stop advancing when conditions are insufficient, and in assumption-breaking cases a fast-confirmed block can reorganize. Protocol finality can stall if the network cannot gather the required supermajority, but it does not silently replace the finality guarantee with a weaker one.
Latency alone is insufficient for choosing among the mechanisms. A more useful criterion is the cost of acting on a confirmation that later proves unreliable. A small exchange deposit may accept one-slot FCR confirmation to improve user experience while limiting exposure. A rollup that can safely reorganize with Ethereum may also use early confirmation for some deposit flows. A preconfirmation is attractive when the application needs subsecond responsiveness and can price or cap the risk of a broken commitment. A large bridge withdrawal or irreversible treasury operation may rationally continue to wait for protocol finality because the cost of a false positive is much larger.
The mechanisms can also coexist because they serve different latency requirements. Faster base-layer finality reduces the time window in which earlier mechanisms are needed, but it does not remove all demand for lower-latency commitments. Even if Ethereum eventually finalizes in several seconds, applications operating in hundreds of milliseconds may still value preconfirmations. FCR can remain useful during a transition or as a standardized safe-block signal.
Ethereum faces several confirmation problems at different layers. For an application, the decision point is the level of assurance required before it can safely act, not simply the fastest signal available.
Settlement Trust Is Not Authorization Trust
The comparison above concerns settlement. Ledger’s positions on self-custody and hardware-anchored trust raise a separate question: what proves that the transaction being settled was legitimately authorized?
A blockchain can prove that a valid signature was accepted according to protocol rules. It cannot prove that the person controlling the key understood the transaction, intended its full effects, or was not deceived into signing it. Consensus secures agreement among validators, not human intent.
The distinction can be represented as two trust boundaries. Authorization covers the path from human intent to a valid transaction; settlement covers the path from transaction acceptance through validator ordering and attestation to finality.
Preconfirmations, FCR, and faster finality mainly improve the second boundary. They reduce uncertainty about whether a valid transaction will be included or remain canonical. They do not establish that the transaction should have been signed in the first place.
Hardware-anchored signing can strengthen the first boundary because secret keys can remain isolated from a general-purpose computer and because a physical confirmation step can make remote compromise harder. This supports the broader self-custody principle that control of assets should depend on user-held authorization rather than an intermediary. Hardware does not, however, solve intent by itself. A user can securely sign a malicious approval, deceptive transaction, or contract call whose consequences are poorly understood.
The implication is that faster settlement increases the importance of authorization quality. If Ethereum moves from minutes of finality to seconds, the interval in which an unintended action can be detected before strong settlement becomes shorter. Strong authorization therefore needs more than key isolation. It also needs intelligible transaction display, transaction simulation, policy controls, clear delegation boundaries, and mechanisms that help a person distinguish the action they intend from the payload they are asked to sign.
Hardware-anchored trust and Ethereum finality address different parts of the system. Secure hardware protects the authority to sign, while consensus protects settlement integrity. A complete self-custody security model needs both, together with an interface layer that makes authorization understandable.
8. Limitations
This paper compares protocol guarantees rather than observed loss rates. The published FCR experiment provides useful mainnet observations, but its roughly 26-hour sample contained no adversary actively attempting to delay confirmation [13]. It therefore does not establish how often FCR assumptions will be stressed in production. The paper also does not estimate preconfirmation failure rates or the monetary value of reducing confirmation latency for a specific application.
Preconfirmation systems also vary materially. Some rely on individual proposers, some on committees, and some may use different collateral or enforcement models. The analysis treats them as a class and focuses on the common property of a pre-consensus commitment. Individual implementations require separate risk assessment.
Ethereum’s faster-finality roadmap remains active research. Minimmit, Lean Consensus, slot duration, validator aggregation, and fork sequencing may change. Claims about future protocol design should therefore be read as a description of the current research direction rather than a fixed deployment plan.
9. Conclusion
Ethereum’s confirmation problem cannot be reduced to one number. Inclusion, early confirmation, and finality answer different questions.
Preconfirmations can produce the earliest useful assurance because they rely on a narrower commitment from a proposer, sequencer, or committee. Their security depends on the authority of the preconfer and the credibility of the penalty for violating the promise. FCR moves the trust basis closer to Ethereum itself by using validator attestations. It can provide a formal single-slot confirmation under stated network and adversarial assumptions, but it does not provide the economic irreversibility of finality. Protocol-level faster finality changes the strongest guarantee and is therefore the most complete solution to settlement latency, but it is also the most difficult to deploy.
The comparison supports evaluating these mechanisms by assurance type rather than speed alone. Applications should identify the action they want to take, the value exposed if the confirmation proves unreliable, the failure mode they can recover from, and the trust dependencies they are willing to accept. Confirmation latency becomes a meaningful optimization target only after those requirements are defined.
The same reasoning applies to self-custody. Faster settlement can establish network agreement sooner, but it cannot establish human intent. Authorization and settlement remain separate security problems. Ethereum can make transactions final faster; a secure ownership system must still ensure that the right transaction was authorized in the first place.
- Ethereum.org. “Single-slot finality.” Updated July 23, 2026. ethereum.org/roadmap/single-slot-finality
- Ethereum.org. “A more secure Ethereum.” Updated July 12, 2026. ethereum.org/roadmap/security
- Ethereum Consensus Specifications. “Phase 0 — Fast Confirmation.” ethereum.github.io/consensus-specs
- Fast Confirmation Rule. “Single-slot confirmation for Ethereum.” fastconfirm.it
- Ethereum Protocol Meetings. “Fast Confirmation Rule (FCR) #12.” August 4, 2026. github.com/ethereum/pm (fcr-labeled issues)
- Justin Drake. “Based preconfirmations.” Ethereum Research, 2023. ethresear.ch/t/based-preconfirmations/17353
- Cairo et al. “Towards an implementation of based preconfirmations leveraging restaking.” Ethereum Research, 2024. ethresear.ch/t/…restaking/19211
- Aikaterini-Panagiota Stouka and Conor McMenamin. “Future-Proofing Preconfirmations.” Ethereum Research, 2025. ethresear.ch/t/future-proofing-preconfirmations/22618
- Espresso Systems researchers. “Analyzing BFT & Proposer-Promised Preconfirmations.” Ethereum Research, 2023. ethresear.ch/t/…preconfirmations/17963
- Ethereum Foundation. “Protocol Update 003 — Improve UX.” August 29, 2025. blog.ethereum.org/2025/08/29/protocol-update-003
- Justin Drake. “lean Ethereum.” Ethereum Foundation, 2025. blog.ethereum.org/2025/07/31/lean-ethereum
- Ethereum Foundation. “Allocation Update — Q2 2026.” August 18, 2026. blog.ethereum.org/2026/08/18/allocation-q2-26
- Saltini, R., Kalinin, M., Zanolini, L., D’Amato, F., Asgaonkar, A., and Zhang, C. Fast Confirmation Rule for Ethereum’s Consensus Protocol. arXiv:2405.00549v4, July 16, 2026. arxiv.org/abs/2405.00549
I declare that this submission is my own original work. I have cited the sources used in developing the analysis and have reviewed the final paper for accuracy, reasoning, and authorship. Any AI tools used during the research process were used only as working tools in accordance with the competition rules.
Kyrian Alex · August 31, 2026
