What Blockchain Finality Actually Guarantees

Finality is the property that matters at the moment you release goods, credit an account, or treat a payment as settled, and it is also the property most often described in language that cannot survive contact with an incident. A blockchain does not make a transaction permanent. It makes reversal expensive, and it makes the cost of reversal calculable under a stated set of assumptions. This article writes those assumptions down: what proof of work actually promises, what a Byzantine fault tolerant finality gadget promises instead, how deep reorganisations have gone on live networks, and what the exchanges crediting your deposit have decided is close enough. Every number below was checked against the protocol specification, the original paper, or the operator's own published policy, and where the evidence is thin the article says so. This is a technical reference on mechanism and it does not constitute investment or financial advice.

What does a finality guarantee actually claim?

Every finality guarantee has the same shape: this transaction will not be reversed unless condition X holds, and condition X costs Y to bring about. The engineering differences between chains are entirely differences in what X is and how Y is measured. Nothing in any consensus design produces an unconditional claim.

Two properties are being traded against each other. Safety is the promise that two honest participants never end up accepting conflicting histories. Liveness is the promise that the chain keeps making progress. A chain can hold safety perfectly while losing liveness, which is what happens when Ethereum stops finalising but never reverts anything, and the reverse trade is also available. Reading a finality incident correctly almost always means working out which of the two properties actually broke, because the reporting rarely distinguishes them and the consequences for a settlement system are entirely different.

The Casper paper that defines Ethereum's finality gadget is explicit that its subject is bounded. Vitalik Buterin and Virgil Griffith, in the arXiv paper first submitted on 25 October 2017 and last revised on 22 January 2019, describe Casper as a system that shows "defenses against long range revisions and catastrophic crashes" and that "provides almost any proof of work chain with additional protections against block reversions". Additional protections is the accurate register. Not permanence.

What is the difference between probabilistic and deterministic finality?

Probabilistic finality gives you a risk that shrinks with every block and never reaches zero, while deterministic finality gives you zero risk inside an assumption and no bound at all outside it. That distinction is usually presented as a ranking, with deterministic finality the stronger of the two. It is not a ranking, it is a change in the shape of the failure, and a chain whose risk never quite reaches zero can still be the harder one to attack.

Nakamoto consensus is the probabilistic case. Section 11 of the Bitcoin whitepaper models an attacker with a fraction q of hashpower trying to catch up from z blocks behind, using a Poisson distribution with lambda equal to z multiplied by q over p. The published results for an attacker holding ten per cent of hashpower are below. The numbers are not a policy recommendation, they are the output of one specific model.

Attacker success probability from the Bitcoin whitepaper, Section 11, for an attacker holding ten per cent of hashpower

Blocks deep (z)	Probability attacker still catches up	Expressed as odds
1	0.2045873	about 1 in 5
2	0.0509779	about 1 in 20
3	0.0131722	about 1 in 76
4	0.0034552	about 1 in 289
5	0.0009137	about 1 in 1,094
6	0.0002428	about 1 in 4,119
10	0.0000012	about 1 in 833,000

That model has a known error. Cyril Grunspan and Ricardo Perez-Marco published a correction in the International Journal of Theoretical and Applied Finance, volume 21, issue 8, 2018, first posted to arXiv on 6 February 2017 and last revised on 6 May 2020. They give a closed form for the attack probability using the regularised incomplete beta function, prove the exponential decay in confirmations that the literature had been asserting, and state the direction of the correction plainly: "Larger number of confirmations are necessary compared to those given by Nakamoto." The canonical table in the whitepaper is optimistic, and the peer-reviewed correction has been available for eight years without displacing it from common practice.

Byzantine fault tolerant finality is the deterministic case. The CometBFT consensus specification, which underpins the Cosmos family, assumes at most one third of validator voting power is Byzantine and commits a block after more than two thirds of precommits. Inside that assumption there are no forks at all. Outside it the specification offers accountability rather than prevention, noting that if two conflicting commits ever exist then more than one third of validators are immediately punishable for double signing. Punishable is not the same as prevented.

Where did six confirmations come from, and is it a protocol rule?

It is not a protocol rule, and no Bitcoin specification contains it. The Bitcoin Wiki page on confirmations, which is a community-maintained document rather than a primary source, states that "There is nothing special about the default, often-cited figure of 6 blocks" and explains the origin: "It was chosen based on the assumption that an attacker is unlikely to amass more than 10% of the hashrate, and that a negligible risk of less than 0.1% is acceptable."

That reasoning is internally consistent with the table above. At ten per cent hashpower, five confirmations leaves 0.09 per cent risk and six leaves 0.024 per cent, so six is the first value comfortably inside a 0.1 per cent tolerance. The number everyone quotes is therefore a 2009-era risk appetite plus a model its own authors' successors have since shown to be too generous, not a property of Bitcoin. The same wiki page says merchants and exchanges "can and should set their own threshold", which is exactly what they have done, in every direction.

One further point about zero-confirmation transactions. Bitcoin Core 28.0, released on 2 October 2024, changed the default value of the mempoolfullrbf configuration option from 0 to 1. Unconfirmed transactions can now be replaced by default across the reference implementation's relay policy, which removes whatever residual comfort a zero-confirmation payment offered. Treating an unconfirmed Bitcoin transaction as settled is no longer a calculated risk, it is a category error.

How deep have reorganisations actually gone on live chains?

Deeper than the conventions, on several chains, and the deepest events were caused by software bugs and rentable hashpower rather than by anything the consensus theory predicted. The table below lists incidents whose depth was reported by the sources listed at the end of this article. Where a figure comes from trade press rather than a post-mortem by the chain's own developers, the table says so, because the difference matters.

Reported deep chain reorganisations, with the evidence class of each figure

Chain and date	Reported depth	Reported cause	Evidence class
Bitcoin, 15 August 2010	53 blocks, from 74,638 to 74,691	Integer overflow in output-sum checking, CVE-2010-5139	Community wiki, corroborated by the CVE record
Bitcoin, March 2013	Not stated in BIP 50	Berkeley DB lock limit split 0.8 from earlier nodes, the 0.8 side holding around 60 per cent of hashpower	Primary, BIP 50, which documents at least one large double spend by an experimenter
Ethereum Classic, 29 July to 1 August 2020	3,693 blocks	Rented hashpower, around 800,000 ETC double spent for roughly 17.5 BTC of hashrate	Trade press
Ethereum Classic, 6 August 2020	4,000 blocks	Second rented-hashpower attack in a week	Trade press
Bitcoin Gold, 23 to 24 January 2020	Up to 16 blocks	Rented hashpower, two double spends of 1,900 BTG and 5,267 BTG	Trade press quoting a named researcher
Monero, 14 September 2025	18 blocks, from 3,499,659	A withheld chain from the Qubic pool released into the network	Independent researcher analysis
Ethereum beacon chain, 25 May 2022	7 blocks	Partial rollout of the proposer boost fork choice change	Trade press quoting core developers
Bitcoin, 24 March 2026	2 blocks, at 941,880	Ordinary mining race won by Foundry USA against AntPool and ViaBTC	Trade press citing researcher b10c

The Monero incident is the most instructive because it broke a live safety parameter rather than a convention. Monero enforces a ten-block lock before outputs can be spent, and as the researcher Rucknium's analysis puts it, the reorganisation "violated the assumption that reorg depths would not exceed 9 blocks". Around seventy minutes of history was replaced and 115 transactions from the honest chain were invalidated. Rucknium is careful about attribution of capability rather than intent, noting that a pool holding forty per cent of hashpower would have a five per cent chance of producing twenty blocks in sixty-six minutes or less by luck alone, so depth on its own does not prove majority control.

The Bitcoin Gold numbers show what happens when an exchange's threshold and an attacker's reach are compared directly. At the time, deposits were credited after six confirmations and withdrawals released after twelve, which meant that a reorganisation of fourteen or fifteen blocks would clear both windows. The attackers reorganised up to sixteen. Developer James Lovejoy estimated the cost at about 1,200 US dollars per attack based on hashrate marketplace pricing, against roughly 72,000 dollars double spent. That estimate is a single researcher's calculation from spot rental prices rather than an audited figure, and it should be read as an order of magnitude, but even three orders of magnitude of error would leave the attack profitable.

What does Ethereum's finality gadget actually guarantee?

It guarantees that reverting a finalised checkpoint requires destroying at least one third of all staked ether, and it guarantees nothing about how quickly the chain reaches the next finalised checkpoint. The first half is enforced by arithmetic in the specification. The second half is where every real incident has happened.

How the two-epoch clock works

The mainnet preset for phase 0 in the consensus specifications sets SLOTS_PER_EPOCH to 32, and the mainnet config sets SLOT_DURATION_MS to 12000. An epoch is therefore 384 seconds. The justification rule in the beacon chain specification checks whether the previous epoch's target balance multiplied by three is at least the total active balance multiplied by two, which is the two-thirds supermajority test. A checkpoint is justified in one epoch and finalised when the next checkpoint is justified, so the cycle is two epochs, 64 slots, 768 seconds, or 12.8 minutes.

A specific transaction does not get 12.8 minutes. It gets that cycle plus however much of its own epoch remained when it was included, which is why the ethereum.org roadmap page on single slot finality says "It takes about 15 minutes for an Ethereum block to finalize" rather than quoting the cleaner figure. Both numbers are correct and they answer different questions, which is worth knowing before quoting either at an auditor. The execution layer JSON-RPC interface exposes the distinction directly through its block tags, of which latest, safe and finalized carry progressively stronger claims, and only the last of the three carries the Casper guarantee.

What it costs to revert a finalised block

The cost comes from the correlated slashing penalty, not from the base penalty for misbehaving. The Bellatrix preset sets PROPORTIONAL_SLASHING_MULTIPLIER_BELLATRIX to 3, and the slashing routine in the beacon chain specification computes an adjusted total slashing balance as the sum of recent slashings multiplied by that figure, capped at the total active balance, then scales each offender's penalty by the ratio of that adjusted total to the total balance. When one third of the stake is slashed in the same window, three multiplied by one third reaches the cap, the ratio becomes one, and each participant loses their entire effective balance. That is the mechanism behind the familiar claim that reverting finality destroys a third of the stake.

The base penalty has moved in the opposite direction. Phase 0 set MIN_SLASHING_PENALTY_QUOTIENT to 128, Bellatrix lowered the divisor's aggression by setting its variant to 32, and the Electra preset sets MIN_SLASHING_PENALTY_QUOTIENT_ELECTRA to 4096. A lone validator slashed today loses roughly one four-thousandth of its effective balance up front. Ethereum's finality guarantee therefore rests almost entirely on the correlation penalty, and the deterrent against isolated misbehaviour has been deliberately reduced by more than two orders of magnitude since the Merge. That is a defensible design choice aimed at solo stakers and operator error, but it means the security argument cannot be restated as "validators lose money if they misbehave" without qualification.

Where the guarantee stops

Three limits are written into the specification itself. First, the inactivity leak: the ethereum.org proof of stake documentation states that it activates "whenever the chain fails to finalize for more than four epochs", matching MIN_EPOCHS_TO_INACTIVITY_PENALTY of 4 in the preset. The leak exists precisely because prolonged non-finality is an expected state, and it works by draining the stake of validators on the minority side until the majority regains a supermajority. Liveness is restored by destroying capital, not by consensus.

Second, weak subjectivity. The phase 0 weak subjectivity specification defines a weak subjectivity period as the window "within which there must be a Weak Subjectivity Checkpoint to ensure that an attacker who takes control of the validator set at the beginning of the period is slashed", and sets SAFETY_DECAY to 10, described as the maximum tolerable percentage loss in the one-third safety margin. The practical consequence is blunt: a node syncing with no recent trusted checkpoint cannot determine which finalised chain is the real one from protocol rules alone. Finality is a guarantee to participants who were already watching, not a property a newcomer can verify from genesis.

Third, the one-third assumption is an assumption. Below it, safety is absolute. Above it, the protocol provides attribution and penalties, and the decision about which chain is canonical moves to the social layer.

What do exchanges actually wait for?

They wait for whatever their own risk committee decided, and the published numbers for the same chain disagree with each other by a factor of four. The table below reports only figures from each operator's own published material, with the date of that material, because staleness is the main hazard in this data.

Published deposit confirmation requirements by venue, with the date and status of each source

Venue	Bitcoin	Ethereum and ERC-20	Source and date
Kraken	4 confirmations, stated as roughly 40 minutes	Not stated in the fetched text	Support article, page last updated 11 May 2026
Binance	1 for deposit credit, 2 to unlock for withdrawal	12 for both deposit and withdrawal	Announcement dated 9 July 2019, likely stale
Bitstamp	3 confirmations	12 confirmations	Educational page, no publication date shown
Gemini	3 confirmations, stated as about 30 minutes, reduced from 6	Not verifiable in this session	Company blog dated 6 February 2016, very stale
OKX	Not stated in the fetched text	32 confirmations, reduced from 64	Support announcement dated 15 November 2023

Two observations follow from putting these side by side, and both are uncomfortable. The first concerns OKX. Reducing the Ethereum requirement from 64 to 32 confirmations moves the threshold from exactly the two-epoch finality cycle down to exactly one epoch. An Ethereum deposit credited at 32 confirmations has not been finalised under Casper FFG, because one epoch is at most half of the justify-then-finalise cycle, so the venue is knowingly accepting pre-finality risk to shorten deposit-to-trade time. The announcement gives the reason as improving the deposit-to-trade experience and contains no risk statement, which is the honest reading of the trade-off even if it is not the reassuring one.

The second concerns the reasoning published alongside the numbers. Bitstamp's page explains its twelve-confirmation Ethereum requirement on the grounds that Ethereum blocks arrive faster, so more of them are needed to accumulate assurance equivalent to three Bitcoin blocks. That is a proof of work argument, and Ethereum's consensus layer has not used proof of work since the Bellatrix fork recorded in the mainnet config at epoch 144,896. Twelve confirmations on Ethereum is 144 seconds, which is a fraction of an epoch and carries no Casper claim whatsoever. Whether the page is simply unmaintained or the policy is deliberate cannot be determined from the published text, and the page carries no date, which is itself the finding.

The broader point is that confirmation thresholds are commercial risk policy calibrated against expected loss, not statements about protocol truth. Bitcoin Gold demonstrated what happens when the calibration is wrong in a rentable-hashpower environment, and Binance's response was to raise the BTG withdrawal requirement to 20 confirmations after the fact. The same logic governs how custodians and banks think about settlement risk, which is why the question surfaces in the FDIC custody approval framework for banks holding bitcoin and in the capital treatment fights covered in the Basel III crypto capital requirements. It also shapes how brokers credit client balances, a mechanic visible across the venues discussed in social trading platforms in 2026.

Why does a chain with deterministic finality still fail?

Because the code that implements the rule is not the rule, and every threat to Ethereum's finality so far has come from client software rather than from consensus theory. The record is short and it points in one direction.

On 11 and 12 May 2023 the network stopped finalising twice. The analysis by Thomas Thiery, published on 26 May 2023, dates the first incident from 20:13:11 to 20:38:35 UTC across epochs 200552 to 200555, about 25 minutes, and the second from 17:20:23 to 18:24:11 UTC across epochs 200750 to 200759, about 64 minutes. Participation fell to 40.9 per cent in the first and 30.7 per cent in the second, well below the two-thirds threshold. The cause in both cases was the handling of valid but old attestations in the Prysm and Teku clients, which forced expensive repeated state recomputation. Nimbus and Lighthouse were more resilient. Crucially, the chain delayed finalisation and never reverted a finalised block. Safety held. Liveness did not.

The pattern repeated after the Fusaka upgrade, which the mainnet config records as FULU_FORK_EPOCH 411392. Cointelegraph, reporting on 5 December 2025, states that voting participation fell to 74.7 per cent at epoch 411,448, within about nine percentage points of the 66.7 per cent supermajority requirement, with the shortfall tracking Prysm's client share as it fell from 22.71 per cent to 18 per cent. Participation had recovered to roughly 99 per cent by epoch 411,712. The most useful line in that coverage is Anthony Sassano's observation that "if Lighthouse had had the bug instead, then the network would've lost finalization." Ethereum's finality guarantee survived that day because of client diversity, which is a social and market property with no representation in the protocol and no slashing condition attached to it.

What each finality model guarantees, under what assumption, and how it fails

Model	Stated guarantee	Assumption it rests on	Failure shape
Nakamoto proof of work	Reversal probability decays exponentially in confirmations, never to zero	Honest majority of hashpower, and that hashpower is not cheaply rentable	Gradual. Risk is always non-zero and rises smoothly as attacker share rises
Casper FFG on Ethereum	Finalised checkpoints cannot be reverted without one third of staked ether being destroyed	Fewer than one third of stake defects, plus a recent trusted checkpoint for syncing nodes	Discontinuous for safety, gradual for liveness. In practice liveness degrades first, from client bugs
CometBFT and the Cosmos family	No forks at all once more than two thirds precommit	At most one third of voting power is Byzantine	Discontinuous. Above the threshold the protocol offers attribution and slashing, not prevention
Solana under Tower BFT	Finalised after 31 or more confirmed blocks on top, roughly 12.8 seconds at 0.4 second slots	Two thirds of stake honest, and validators keep up with the slot schedule	Discontinuous for safety, with liveness historically the observed weak point
Solana under Alpenglow, proposed	Fast finalisation at 80 per cent notarise votes, slow path at two rounds of 60 per cent	A 20 plus 20 model, meaning 20 per cent Byzantine tolerance and 20 per cent crash tolerance	Discontinuous, and the Byzantine threshold is explicitly lower than the 33 per cent of two-round protocols
Optimistic rollups	State roots confirm once the dispute window closes unchallenged	At least one honest challenger is watching and can transact on the parent chain	Delay rather than reversal. Adversaries buy time rather than rewriting state

The Alpenglow row deserves emphasis because it is the clearest published example of the trade-off being priced. SIMD-0326, authored by Quentin Kniep, Kobi Sliwinski and Roger Wattenhofer and currently carrying a status of Review, specifies a 20 plus 20 security model that its own text contrasts against the 33 per cent Byzantine security available from two-round protocols. Validators approved it by 98.27 per cent of participating stake, against 1.05 per cent no and 0.69 per cent abstaining, on 52 per cent stake participation, as reported on 3 September 2025. Solana's community voted, with near unanimity among those who voted, to lower the Byzantine fault tolerance threshold from roughly a third to a fifth in exchange for sub-second finality, and that is a defensible engineering decision only if it is described accurately. The proposal also notes that it covers the Votor voting protocol only, with the Rotor data dissemination change deferred to a separate document, and no mainnet activation date has been published.

What does finality mean when your transaction is on a rollup?

It means three different things at three different times, and conflating them is the most common practical error in the space. A transaction has soft confirmation from the sequencer within seconds, inherits the parent chain's finality once its batch is posted and that parent block finalises, and becomes withdrawable only after the dispute window closes.

The third figure is the one that matters for moving value out. Arbitrum's documentation on the economics of disputes in BoLD states that "The assertion has a seven-day dispute window in which anyone can dispute it" and that BoLD "guarantees a resolution to a dispute within seven days", with the explicit consequence that "a last-second dispute would delay assertion confirmation by up to 14 days". In the uncontested case there is a built-in seven-day delay. Optimism's fault proof explainer describes an approximately one week challenge period and adds a further airgap window before withdrawals execute, during which a Guardian role can reject the root.

Two things follow. An optimistic rollup's worst case is delay, not loss, which is a genuinely strong safety property and is often undersold. But the presence of a Guardian role capable of rejecting an otherwise valid root means the guarantee in production is partly governed by a privileged party rather than purely by the dispute game, and any honest description has to say so. This is the same class of question that sits under the Treasury guidelines on stablecoin regulation, where settlement finality and the identity of whoever can intervene in it are the regulatory substance.

What is changing, and what should be treated as speculation?

Faster finality is coming to both major ecosystems, and neither timeline should be relied on. Ethereum's roadmap page for single slot finality states that "SSF is in the research phase. It is not expected to ship for several years, likely after other substantial upgrades such as Verkle trees and Danksharding." Separately, EIP-7782 proposes halving the slot from 12 seconds to 6, which the document says shrinks the epoch from 384 to 192 seconds and accelerates Casper FFG finality. That EIP carries a status of Draft, and the mainnet config's SLOT_DURATION_SCHEDULE currently lists only 12000 milliseconds from epoch 0, so nothing is scheduled.

On Solana, SIMD-0326 has passed a stake vote but sits at Review status with no activation date. The prudent operating assumption for anyone building settlement logic is that today's parameters hold until a fork epoch appears in a client release, and that the published research targets are directions rather than dates. The temptation to design around announced improvements is strong and it has a poor record, in much the way that the funding-cycle assumptions examined in the late-stage fintech funding stall aged badly.

How strong is the evidence for each claim in this article?

Unevenly, and the weakest material is concentrated in exactly the places readers most want a firm number. The table below scores each substantive claim made above against the class of evidence actually behind it.

Evidence strength of each claim in this article, scored against its source class

Claim	Evidence type	Strength
Ethereum epoch is 32 slots of 12 seconds, finality cycle is two epochs	Protocol specification files, read directly	Strong
One third of stake slashed in one window destroys the full balance of each offender	Arithmetic in the beacon chain specification plus the Bellatrix preset constant	Strong
Electra cut the base slashing penalty by more than two orders of magnitude	Preset constants, 128 then 32 then 4096, read directly	Strong on the constants, interpretive on the word deliberately
The Nakamoto z table understates required confirmations	Peer-reviewed correction in a finance journal	Strong on the direction, not independently reproduced here
Six confirmations reflects a 2009 risk appetite, not a protocol rule	Community wiki for the rationale, whitepaper for the arithmetic	Medium. The rationale rests on a tier-four source that cites nothing
Reorg depths for Ethereum Classic and Bitcoin Gold	Trade press, no developer post-mortem verified in this session	Weak to medium. Figures differ between outlets
Bitcoin Gold attack cost around 1,200 dollars	One named researcher's estimate from spot hashrate rental pricing	Weak. Order of magnitude at best, not audited
Monero's 18-block reorg exceeded its 10-block lock assumption	Independent researcher analysis with explicit probabilistic caveats	Medium to strong on the facts, deliberately weak on intent
Client bugs, not consensus design, are the observed threat to Ethereum finality	Two documented episodes, May 2023 and December 2025	Medium. Two events is a small sample and absence of a consensus-level failure is not proof of impossibility
Cost of attack, not the consensus label, is what has actually bound in practice	Inference across the incident table above	Weak to medium. The sample is only chains that were attacked, which is a survivorship-biased set
Exchange confirmation thresholds are risk policy, not protocol truth	The venues' own published numbers, which contradict each other on the same chain	Strong. The contradiction is the proof
Bitstamp's stated Ethereum rationale is a proof of work argument	The page's own wording plus the Bellatrix fork epoch in the config	Medium. The reasoning is verifiable, the page's currency is not, as it carries no date
Alpenglow lowers Byzantine tolerance to 20 per cent	The proposal's own text, status Review	Strong as a description of the proposal, no weight as a prediction of mainnet behaviour
Arbitrum's worst case is 14 days, Optimism adds a Guardian-controlled airgap	Each project's own documentation	Medium. Tier-four vendor docs, but authoritative for their own parameters
Total staked ether, and therefore the dollar cost of reverting Ethereum finality	No figure verifiable in this session	Omitted. The guarantee is stated as a fraction only

The single most important row is the second from the bottom of the reasoning, not the data. Every chain that suffered a deep reorganisation in the record above was one where hashpower or stake was cheap to acquire relative to the value being settled, and none of them failed because its consensus model was labelled probabilistic rather than deterministic. The label describes the shape of the failure. The cost of attack determines whether the failure happens. Any comparison that ranks chains by consensus family while ignoring the cost of acquiring a threshold share is measuring the wrong variable, which is also why hashrate economics and the energy market behind them, discussed in the context of sustainable digital asset funds, are a security question and not only an environmental one.

Frequently asked questions

How many confirmations should I actually wait for?

There is no protocol answer, only a risk calculation specific to the value at stake and the cost of acquiring hashpower or stake on that chain. For Bitcoin, the venues surveyed above land between one and four for crediting deposits. For Ethereum, the only threshold that carries the protocol's own guarantee is the finalised tag exposed by the execution layer API, and every confirmation count below roughly 64 slots sits short of it.

Does deterministic finality mean my transaction can never be reversed?

No. It means reversal is impossible while fewer than one third of the validator set defects, and that above that threshold the protocol provides penalties and attribution rather than prevention. The claim is conditional in exactly the same way a probabilistic guarantee is, with the conditionality relocated from the arithmetic into the assumption.

Has Ethereum ever reverted a finalised block?

Not according to any source checked for this article. Ethereum has twice stopped finalising for tens of minutes, in May 2023, and came within about nine percentage points of the threshold in December 2025. In all three episodes the chain lost liveness and retained safety, which is the failure mode the design intends.

Why do withdrawals from an optimistic rollup take a week?

Because the dispute window has to stay open long enough for an honest challenger to notice an invalid state root and get a transaction onto the parent chain even under adverse conditions. Arbitrum documents a seven-day window with up to fourteen days if a dispute is filed at the last moment. Optimism documents approximately one week plus a further airgap delay.

Is a chain with 150 millisecond finality safer than one with 15 minute finality?

Not on the basis of speed alone, and the Alpenglow proposal is the cleanest demonstration of why. It targets sub-second finality while explicitly adopting a 20 per cent Byzantine tolerance in place of the 33 per cent that two-round protocols achieve. Faster finality with a lower fault threshold is a different risk profile, not a strictly better one.

What is weak subjectivity and why should a non-validator care?

It is the property that a node joining the network with no recent trusted checkpoint cannot determine from protocol rules alone which finalised chain is genuine. It matters to anyone relying on a freshly synced node, or on an infrastructure provider whose nodes were rebuilt from scratch, because the finality guarantee at that moment depends on the checkpoint that operator chose to trust rather than on consensus.

Sources

• Satoshi Nakamoto, Bitcoin whitepaper, Section 11 Calculations: nakamotoinstitute.org/library/bitcoin
• Cyril Grunspan and Ricardo Perez-Marco, Double Spend Races, International Journal of Theoretical and Applied Finance 21(8), 2018: arxiv.org/abs/1702.02867
• Vitalik Buterin and Virgil Griffith, Casper the Friendly Finality Gadget: arxiv.org/abs/1710.09437
• Ethereum consensus specifications, mainnet phase 0 preset: presets/mainnet/phase0.yaml
• Ethereum consensus specifications, mainnet config: configs/mainnet.yaml
• Ethereum consensus specifications, Bellatrix preset: presets/mainnet/bellatrix.yaml
• Ethereum consensus specifications, Electra preset: presets/mainnet/electra.yaml
• Ethereum consensus specifications, phase 0 beacon chain: specs/phase0/beacon-chain.md
• Ethereum consensus specifications, weak subjectivity: specs/phase0/weak-subjectivity.md
• ethereum.org, Proof of stake developer documentation: ethereum.org proof of stake
• ethereum.org, Single slot finality roadmap page: ethereum.org single slot finality
• EIP-7782, Reduce block latency, status Draft: eips.ethereum.org/EIPS/eip-7782
• BIP 50, March 2013 chain fork post-mortem: bip-0050.mediawiki
• Bitcoin Core 28.0 release notes, 2 October 2024: bitcoincore.org/en/releases/28.0
• Bitcoin Wiki, Value overflow incident, community wiki and not a primary source: en.bitcoin.it Value overflow incident
• Bitcoin Wiki, Confirmation, community wiki and not a primary source: en.bitcoin.it Confirmation
• CometBFT Byzantine consensus algorithm specification: spec/consensus/consensus.md
• Anza, Solana commitment levels for Tower BFT and Alpenglow: docs.anza.xyz/consensus/commitments
• SIMD-0326 Alpenglow, status Review: proposals/0326-alpenglow.md
• Blockhead, Solana validators approve Alpenglow, 3 September 2025: blockhead.co
• Arbitrum documentation, Economics of disputes in BoLD: docs.arbitrum.io BoLD economics of disputes
• Optimism documentation, Fault proofs explainer: docs.optimism.io fault proofs explainer
• Kraken, Cryptocurrency deposit processing times, page last updated 11 May 2026: support.kraken.com
• Binance, Reduction in confirmations required for BTC and ETH, 9 July 2019: binance.com announcement
• Bitstamp, Confirmed and unconfirmed blockchain transactions, undated: bitstamp.net learn
• OKX, Reduction in confirmations required for ETH network deposits, 15 November 2023: okx.com help
• Gemini, Funding your Gemini account just got a lot faster, 6 February 2016: gemini.com blog
• Rucknium, Monero's 18-block reorg, independent researcher analysis: rucknium.me
• Thomas Thiery, Cascading network effects on Ethereum's finality, 26 May 2023: hackmd.io
• Cointelegraph, Ethereum sees 25 per cent validation drop post-Fusaka, 5 December 2025: cointelegraph.com
• CoinDesk, Ethereum Classic suffers second 51 per cent attack in a week, 6 August 2020: coindesk.com
• The Next Web, Bitcoin Gold hit by 51 per cent attacks, 27 January 2020: thenextweb.com
• The Cryptonomist, Bitcoin two-block reorg at height 941,880, 24 March 2026: en.cryptonomist.ch