Chain reorganizations: when is a confirmed transaction actually final?

Two things are true about a blockchain transaction that most explanations manage to keep apart only by accident. The first is that once a transaction is included in a block, the network has a shared record of it. The second is that the network's agreement on which chain of blocks is the real one can change, and when it changes, some blocks that were previously part of the record stop being part of it. That second event is a chain reorganization, usually shortened to reorg.

The word sounds catastrophic and is usually mundane. On a proof-of-work network, brief competition between two valid blocks found at nearly the same moment is a normal consequence of physics: block propagation across a global network is not instantaneous, so two miners can extend the same parent before either hears about the other. One of those blocks becomes part of the accepted chain and the other becomes a stale block. Any transaction that was only in the stale block returns to the pool of pending transactions and is normally mined again within minutes.

The destructive version is the same mechanism operated deliberately and much deeper. In August 2020 the Ethereum Classic network was reorganized by 3,594 blocks in a single event and by 4,446 blocks four days later, and the two attacks together were associated with roughly 8.9 million US dollars of double-spent value at two exchanges. Nothing about the mechanism changed between the harmless case and that one. Only the depth changed, and depth is what the rest of this guide is about.

Do not ask, “Is this chain safe from reorgs?” Ask, “How deep would a reorg have to be to undo this specific transaction, and what would that depth cost?”

The vocabulary that decides what a notice means

Confirmation

A confirmation is a count, not a certificate. When your transaction is included in a block, it has one confirmation. Each block built on top of that block adds one more. The count is a proxy for how much work or stake now sits behind your transaction, and therefore how much an adversary would need to spend to build a competing chain that excludes it.

This is why confirmation counts differ wildly between assets and between venues. Six confirmations on Bitcoin represents roughly an hour of the largest proof-of-work budget in the industry. Six confirmations on a small proof-of-work coin can represent an amount of hashrate rentable for a few hundred dollars. The number alone is meaningless without the network it refers to.

Stale block and orphan block

A stale block is a validly constructed block that did not end up on the accepted chain. In casual usage it is often called an orphan block, though strictly an orphan is a block whose parent the node has not yet seen. The distinction matters mainly when reading node logs and explorer pages, which use the terms with different precision.

A stale block is not evidence of an attack. Networks that produce blocks quickly produce more stale blocks, because the window in which two producers can collide is a larger fraction of the block interval. A block explorer showing stale blocks on a fast chain is showing you normal operation.

Reorganization and reorg depth

A reorganization is what a node does when it learns of a chain it considers better than the one it currently holds: it rolls back the blocks that are not shared with the new chain and applies the new chain's blocks instead. The depth is the number of blocks rolled back. A depth-one reorg discards a single block. A depth-3,594 reorg discards half a day of history.

Depth is the number every serious record should carry. “Network X experienced a reorg” conveys almost nothing. “Network X experienced a 15-block reorg that removed 15 blocks and added 16” is a fact that can be compared against a confirmation policy and against the venue's exposure.

Fork

Fork is used for at least three different things and readers pay for the ambiguity. A temporary fork is the momentary two-chain state before a reorg resolves it. A consensus fork or chain split is a persistent divergence caused by nodes enforcing different rules. A protocol fork — hard fork or soft fork — is a planned upgrade to those rules, which is a scheduling and software matter rather than an accident. Our network upgrade guide covers the planned kind.

An accident can produce the persistent kind. In March 2013, Bitcoin nodes running version 0.8.0 accepted a block that older versions rejected, so the network briefly ran two chains that disagreed about validity rather than merely about ordering. That is a software-compatibility failure expressed as a fork, and it is repaired differently from a mining attack.

Double spend

A double spend is the outcome an attacker is usually buying with a deep reorg, not the reorg itself. The pattern is: send coins to a venue, wait for the venue to credit the deposit and allow a withdrawal or trade out, then publish a longer competing chain in which the original deposit transaction never happened. The attacker keeps the coins and keeps whatever was withdrawn.

Notice what this requires. The attacker needs a counterparty who acts on a confirmation count, and the reorg must be deeper than that counterparty's threshold. This is why exchanges, not ordinary wallet users, are the standard target, and why documented attacks so often have reorg depths that sit just above a specific venue's published confirmation requirement.

Majority attack

Commonly called a 51% attack, this is control of enough block-production capacity to reliably build a competing chain faster than the honest network. On proof of work it means hashrate; the threshold is not a magic 51 per cent but a probabilistic advantage that grows with share. The relevant question for a reader is whether the required capacity is cheaply rentable, which for smaller networks it frequently has been.

Finality

Finality is the property that a block cannot be reverted without an explicitly defined, extremely expensive event. Proof-of-work chains do not offer it; they offer probabilistic settlement that strengthens with depth and never formally reaches one. Proof-of-stake designs such as Ethereum's do offer it, with a defined cost, and that changes the shape of the question entirely.

Why shallow reorgs are routine and not a warning

Consider what has to happen for two competing blocks to exist. A miner or validator finds or is assigned a block and broadcasts it. That block travels between nodes across ordinary internet infrastructure, which takes a measurable amount of time. If a second producer completes a block on the same parent inside that propagation window, both blocks are valid, both are broadcast, and different parts of the network temporarily hold different tips.

The situation resolves as soon as one branch gets extended. Nodes that were holding the losing branch reorganize onto the winner, the losing block becomes stale, and any transaction that existed only in the loser goes back to the pending pool. From the perspective of anyone who was not watching a node's logs, nothing happened.

The frequency of this depends on the block interval relative to propagation time. A chain producing blocks every ten minutes will see it rarely. A chain producing blocks every two seconds will see it constantly, because a two-second window is short compared with how long global propagation can take. Neither pattern is a defect; they are different points on the same trade-off between latency and the amount of settlement a single confirmation represents.

This is also the reason a fast chain is not automatically a faster settlement venue. If a network produces a block every 0.75 seconds but a venue requires 15 confirmations before crediting a deposit, the wait is about eleven seconds of block time — but the venue may also be waiting on its own internal batching, risk checks and reconciliation, and those are policy delays, not network delays. Fast blocks shorten one component of the wait, not the whole of it.

The practical consequence for a reader: seeing “reorg” in an explorer, a node log or a monitoring dashboard is not by itself news. What makes it news is depth beyond the ordinary range for that chain, or a reorg that coincides with a venue suspending deposits.

Depth is the whole story

It is worth stating the arithmetic plainly, because it is the reason confirmation counts exist at all. To reverse a transaction with n confirmations, an adversary has to produce a chain that beats the honest chain from at least n blocks back. While they are doing that, the honest network keeps extending its own chain. The adversary's probability of catching up falls sharply as n grows, unless the adversary controls a very large share of production capacity, in which case catching up eventually becomes near-certain and only the elapsed time is in question.

That last clause is the entire security model of a small chain, and the documented record shows what it means in practice. The January 2020 attacks on Bitcoin Gold produced reorgs of 14 and 15 blocks. The technical report on them estimated the cost of each reorg at roughly 0.2 BTC, about 1,700 US dollars at the time, against double spends of about 19,000 and 53,000 US dollars. The attack was not exotic. It was arithmetic on rented hashrate.

The Vertcoin attack of 1 December 2019 is the cleanest illustration of depth as a targeting decision. It removed 603 blocks and replaced them with 553 attacker blocks. The double-spent value was about 125 VTC — around 29 US dollars. Why go 603 blocks deep for 29 dollars? Because a major exchange required roughly 600 confirmations for Vertcoin deposits. The depth was not chosen for the payoff; it was chosen to clear a specific threshold, and on the reported numbers the attempt was not profitable.

Depth also tells you what kind of event you are looking at. Single-digit depths on a healthy large chain are propagation artefacts. Depths in the tens on a small proof-of-work chain, aimed just past a published confirmation requirement, are almost always a deliberate double-spend attempt. Depths in the thousands mean an attacker held majority capacity for many hours — the 29 August 2020 Ethereum Classic event ran 26 hours and 20 minutes and reorganized 7,278 blocks.

What a confirmation policy actually buys you

Every venue that credits on-chain deposits has to pick a number. That number is a risk decision, and it is priced in customer patience on one side and potential loss on the other. Kraken, for example, publishes per-asset deposit confirmation requirements rather than a single global figure, because the appropriate number for one network is wrong for another.

The policy is not a promise about the network. It is a statement about the venue's own exposure. When a venue credits your deposit after six confirmations, it has decided that the probability of a six-block reorg on that chain, multiplied by the size of deposits it typically credits, is an acceptable cost of doing business. Nothing in that decision protects you from a deeper reorg; it protects the venue's balance sheet, and it does so by being roughly right most of the time.

Why the number goes up after an attack

The most reliable signal that a chain has been successfully attacked is not an announcement from the chain. It is exchanges quietly raising confirmation requirements. After the January 2020 Bitcoin Gold attacks, Binance raised its BTG withdrawal requirement to twenty confirmations, having previously used six confirmations for deposits and twelve for withdrawals — numbers the fourteen and fifteen block reorgs had cleared comfortably.

When you see a venue announce that deposits for a specific asset now require substantially more confirmations, read it as a security notice even if it is worded as a routine operational update. The venue has recalculated its exposure on that chain. That recalculation is information about the chain.

Why the number is sometimes suspended entirely

During an active attack, the correct confirmation count may not exist. If an adversary is producing hours-long reorgs, there is no threshold that both protects the venue and lets customers transact. The venue's options are to suspend deposits and withdrawals for that asset or to accept losses, and most choose suspension. A deposit suspension during a reorg event is therefore the venue behaving correctly, not evidence that the venue is failing.

This overlaps with the reading method in our guide on withdrawal pauses. The critical distinction: a pause caused by a chain-level attack affects one asset or one network and is announced with reference to network conditions. A pause caused by a venue's own problem affects the venue's systems and is announced with reference to maintenance, upgrades or investigations. Do not read one as the other.

Why your wallet's confirmation count is not a policy

A wallet shows confirmations as an observation. It does not know what depth of reorg is plausible on that chain today, and it does not know what you are relying on the transaction for. The same three confirmations can be entirely sufficient for receiving a small payment from a known counterparty on a large chain and entirely insufficient for an irreversible off-chain settlement on a small one.

If you are on the receiving side of a high-value transfer and there is no venue between you and the sender, you are the entity setting the confirmation policy. Set it deliberately: consider the chain's total production capacity, whether that capacity is rentable, the value at stake, and whether the counterparty is known. For assets with an established history of majority attacks, the honest answer is often that no confirmation count makes the transfer comfortable.

Proof of stake changes the question, not the vocabulary

On Ethereum's proof-of-stake consensus, blocks pass through defined states rather than accumulating an open-ended confirmation count. A proposed block can be reorganized in the short term much as a proof-of-work block can. But validators also vote on checkpoints, and once two consecutive checkpoints attract votes from a supermajority of staked ETH, the earlier one is finalized. Under normal conditions this takes two epochs, roughly 12.8 minutes.

The word finalized has a precise consequence here. Reverting a finalized block is not merely improbable; it requires an attacker to accept the destruction of at least one third of all staked ETH, because the conflicting votes required are a slashable offence. Ethereum's own documentation describes this as economic finality: the cost is defined in advance and it is enormous.

This is a genuinely different claim from “six confirmations on a proof-of-work chain.” The proof-of-work claim is that an attack becomes progressively less likely to succeed. The proof-of-stake claim is that a successful attack has a known, catastrophic price for the attacker. Neither is a guarantee of impossibility, and it is worth being precise rather than declaring one strictly superior.

Before finalization, ordinary reorgs still occur

The pre-finality window is where proof-of-stake reorgs live, and they behave much like their proof-of-work counterparts: they are usually one block deep and caused by timing. On 25 May 2022 the Ethereum beacon chain experienced a seven-block reorganization affecting blocks 3,887,075 to 3,887,081 within about seventy seconds. The cause was not an attack. Client software implementing a fork-choice change called proposer boost had rolled out to only part of the network, so validators running different versions evaluated a late-arriving block differently and briefly split their views.

That incident is a useful corrective in both directions. It shows that “proof of stake” does not mean “no reorgs before finality,” and it also shows that a multi-block reorg on a major chain is far more likely to be a client-diversity or rollout problem than an attack. The developers involved described it as an unhappy combination of factors rather than a fundamental flaw in the fork-choice rule.

What this means for a venue's policy on a proof-of-stake chain

A venue crediting deposits on Ethereum can, in principle, wait for finalization rather than for a block count, and some do. Waiting for finality is a stronger guarantee than any confirmation count, at the cost of roughly a quarter of an hour. A venue that credits after a handful of blocks has chosen speed and is exposed to exactly the pre-finality reorg window described above.

When you read a deposit-crediting policy on a proof-of-stake network, check which of the two it is expressed in. “Deposits credited after 64 confirmations” and “deposits credited after finalization” are close in elapsed time and different in what they promise.

When the chain does not reorganize but stops agreeing

There is a second failure mode that gets filed under the same headlines and needs to be separated: the chain keeps producing blocks but stops finalizing them, or stops producing blocks altogether. No history is rewritten. The problem is that no new history becomes settled.

Ethereum experienced this on 11 and 12 May 2023. The beacon chain failed to reach finality twice — for about 25 minutes, then for over an hour. Validator participation fell to 40.9 per cent in the first incident and 30.7 per cent in the second. The published post-mortem from the client teams involved traced it to a flood of attestations voting for old beacon blocks, which is standard behaviour for some consensus clients when their execution client is unresponsive. Validating those attestations required regenerating old beacon states, and a cache intended to prevent repeated regeneration filled up, forcing the same expensive work to be done over and over. Teku and Prysm shipped fixes.

Note what did and did not happen. Blocks were still produced. Transactions were still included. What lapsed was the guarantee that recent blocks could not be reverted — which is precisely the guarantee a venue waiting on finality depends on. A user watching a block explorer would have seen the chain working. A venue waiting for finalization would have seen its crediting pipeline stop.

Solana's outage of 6 February 2024 is the more extreme version. Block finalization halted at 09:53 UTC and consensus progress resumed at 14:55 UTC, an incident of roughly five hours, resolved by a coordinated cluster restart and a patched release. Again, no rewriting of settled history — but for five hours nothing new settled either, and every deposit and withdrawal route depending on that chain was inoperative.

For a reader, the distinction is operational. A reorg means “something you thought had happened may not have happened.” A stall means “nothing new is happening.” The first requires you to re-verify past transactions. The second requires you to wait and to not resubmit transactions in a panic, because resubmission during a stall commonly produces duplicates once the chain resumes.

Fourteen documented events and what each one demonstrates

The following events are drawn from first-party alerts, client-team post-mortems, protocol specifications and technical attack reports. They are selected to cover distinct causes rather than to be a complete history, and the accompanying tracker exposes the same records with filters for cause, network and depth band.

Bitcoin, 15 August 2010 — a client fault, repaired by a 53-block reorg

A transaction exploiting an integer overflow created outputs far exceeding any legitimate supply, and it was included in block 74638. A patched client was released within hours, and the corrected chain overtook the defective one roughly 53 blocks later. This is the earliest well-documented deep reorganization on a major network, and its cause was a validation bug rather than an attack. The repair used the same mechanism an attacker would use.

Bitcoin, 11–12 March 2013 — a version boundary split the network

A miner running version 0.8.0 produced block 225,430, which pre-0.8 nodes could not process because of an insufficient Berkeley DB lock configuration. The network briefly ran two chains that disagreed about validity. Large pools on 0.8.0 were asked to revert to 0.7 to restore a single chain compatible with all software; version 0.8.1 followed. The official alert told users their software would switch to the correct chain automatically. The post-mortem in BIP 50 records at least one large double spend during the split — performed by someone testing whether it was possible — and notes that deposits at major exchanges and payments via BitPay were suspended and then quickly restored.

Bitcoin, 4 July 2015 — SPV mining built on an invalid block

When the BIP66 enforcement threshold was reached — 950 of the last 1,000 blocks signalling version 3 — a non-upgraded miner produced an invalid block, and roughly half the network hashrate, mining without fully validating, built on top of it. The first fork ran six invalid blocks; a second, on 5 July, ran three more. The alert advised users of lightweight wallets, Bitcoin Core 0.9.4 or earlier, and web wallets to wait an additional 30 confirmations, and told pool operators to switch to a pool that properly validates. Large miners lost over 50,000 US dollars of income. No double spends were confirmed in the first incident.

Vertcoin, 1 December 2019 — depth chosen to clear a venue threshold

At 15:19:47 GMT, 603 blocks were removed and replaced with 553 attacker blocks. About 125 VTC across five outputs was double-spent, worth roughly 29 US dollars, while the attacker collected 13,825 VTC in block rewards. The reorg depth corresponded to a major exchange's confirmation requirement for the asset, which is the clearest available evidence that reorg depth is a targeting parameter rather than a measure of severity.

Bitcoin Gold, 23 January 2020 — 14 blocks, roughly 19,000 US dollars

At 18:01:32 GMT a reorg removed 14 blocks and added 13, double-spending about 1,900 BTG. The estimated cost of producing the reorg was approximately 0.2 BTC.

Bitcoin Gold, 24 January 2020 — 15 blocks, roughly 53,000 US dollars

At 00:24:08 GMT the same attacker address produced a second reorg removing 15 blocks and adding 16, double-spending about 5,267 BTG. Both depths exceeded the six-confirmation deposit and twelve-confirmation withdrawal escrow periods then in use at a major venue, which subsequently raised the BTG withdrawal requirement to twenty confirmations.

Ethereum Classic, 1 August 2020 — 3,594 blocks over 12 hours

Beginning at block 10,904,146, a reorganization 3,594 blocks deep ran for 12 hours and 12 minutes, associated with roughly 5.6 million US dollars — over 807,000 ETC — double-spent against OKX. At this depth the concept of a confirmation policy stops being useful; no realistic threshold survives a reorg measured in thousands of blocks.

Ethereum Classic, 5 August 2020 — 4,446 blocks over 15 hours

Four days later, beginning at block 10,935,622, a 4,446-block reorganization ran for 15 hours and 37 minutes, associated with roughly 3.3 million US dollars — 465,444 ETC — double-spent against Bitfinex. Two successful attacks within a week against different venues is the signature of a chain whose production capacity is cheaply available on the open market.

Ethereum Classic, 29 August 2020 — 7,278 blocks over 26 hours

The third attack of the month began at block 11,090,590, reorganized 7,278 blocks and ran for 26 hours and 20 minutes. No double-spend total is documented for this event, which is itself worth noting: by this point most venues had suspended or heavily restricted the asset, and an attacker without a crediting counterparty has nothing to collect.

Ethereum Classic, October 2020 — a protocol-level answer

ECIP-1100 specified MESS, or Modified Exponential Subjective Scoring, a fork-choice modification implementing the principle that small reorgs are normal and healthy while large reorgs are suspicious. It made a node increasingly reluctant to abandon a chain segment it already held, with a ceiling requiring an attacker to sustain roughly 31 times the competing chain's difficulty. Core-Geth proposed activation at block 11,380,000, estimated for October 2020. The ECIP is now marked as replaced by a successor proposal, so treat it as a documented response to the 2020 attacks rather than as current ETC consensus policy.

Bitcoin SV, 3 August 2021 — three competing chains at once

Beginning at 11:46, a block re-organisation attack produced three simultaneously mined versions of the chain, with an observed maximum reorg depth of 14 blocks. Bitcoin Association attributed it to the same actor behind attacks on 24 June and 1, 6 and 9 July 2021, recommended that honest node operators mark the attacker's chains invalid, and said it was working with law enforcement. Note the defence being used: human coordination to reject a chain, which is effective and is also a departure from purely mechanical consensus.

Ethereum, 25 May 2022 — seven blocks from a partial client rollout

Between 08:55:23 and 08:56:35 UTC, beacon chain blocks 3,887,075 to 3,887,081 were reorganized out. The proposer-boost fork-choice change had not fully propagated across client software, so validators evaluated a late block differently. Not an attack, and not a fork-choice design failure — a rollout gap. It remains the standard example of why client-version diversity is an operational risk in both directions.

Ethereum, 11–12 May 2023 — finality lost twice without a reorg

Two incidents, about 25 minutes and over an hour, in which the beacon chain produced blocks but did not finalize them. Participation fell to 40.9 per cent and then 30.7 per cent. The cause was attestation flooding for old blocks, triggering repeated beacon-state regeneration once a preventive cache overflowed. Fixes shipped in Teku and Prysm. No history was rewritten.

Solana, 6 February 2024 — five hours with nothing settling

Block finalization halted at 09:53 UTC and consensus resumed at 14:55 UTC after a coordinated restart, with a patch released as v1.17.20. Engineers traced it to a fault consistent with a bug identified while investigating an earlier devnet outage. Again: a liveness failure, not a reorganization.

Turning a reorg or delayed-deposit notice into a record

Start by identifying who issued the notice and what layer they control. A protocol foundation or client team is authoritative about the network's consensus state. An exchange is authoritative about whether it has credited your deposit and what it will do about a credit it now considers invalid. A block explorer is a useful third observer and is authoritative about nothing. When these three disagree, the disagreement itself is the finding.

Capture the depth and the affected height range. “A reorg occurred on chain X” cannot be compared to anything. “A reorg beginning at block 10,904,146 removed 3,594 blocks” can be checked against your own transaction's height, which tells you immediately whether you were inside the affected range. If a notice omits the depth, that is a gap worth noting rather than a detail to fill in from a social post.

Separate the three consequences that notices routinely blend. First, transactions that were reversed — these genuinely did not happen on the accepted chain. Second, deposits that were credited and are now being clawed back or frozen — this is a venue policy action against an account, and it has its own dispute process. Third, services that are suspended — this is forward-looking and says nothing about whether your past transaction survived.

Check whether the event is a reorg or a stall before deciding what to do. If the chain is not finalizing or has halted, your completed transactions are not in question and resubmitting is the main avoidable mistake. If a deep reorg occurred, the opposite applies: verify that your transaction still exists at a height on the accepted chain, using an explorer that has itself reorganized, which not all of them do promptly.

Record the confirmation policy in force at the time. This is the detail that ages worst and matters most. A venue that credited at six confirmations before an attack and at twenty after it has told you, through that change, how it assessed the risk on each side of the event. If you are reconstructing what happened to a deposit weeks later, the policy that applied on the day is what determines whether the credit was reasonable.

Finally, note the review time and keep the primary sources. Attack reports are revised as analysis improves; initial depth figures and double-spend totals in particular are often corrected within days. A screenshot of an explorer during an active reorg is a record of one node's view at one moment, which is exactly the thing a reorg changes. Preserve the client-team post-mortem or protocol alert instead, because those are versioned and attributable.

What an ordinary holder should actually do

For the overwhelming majority of reorg events, the correct action for a holder is nothing. A one- or two-block reorg on a major chain does not require you to check anything. If your transaction was in a stale block, it will almost certainly be included in the next one, and the wallet will show the confirmation count restart. Resending the same payment during that window is how people accidentally pay twice.

If a chain you hold is reported to have experienced a deep reorg, the checks are specific and short. Confirm whether your own transactions fall inside the affected height range. Check whether your venue has suspended deposits or withdrawals for that asset. Do not initiate new transfers on that chain while an attack is ongoing, because an attacker's whole business model depends on transfers being credited during the window they control.

If you are holding an asset on a small proof-of-work chain with a history of majority attacks, the honest framing is that you are exposed to a risk that has repeatedly materialised and that no confirmation count on your side controls. That is a position to hold knowingly, not a problem to solve with a higher confirmation setting in a wallet.

During a stall or halt, the discipline is patience. Do not resubmit. Do not increase fees on a pending transaction that a halted chain has not processed. Do not treat a venue's inability to process withdrawals on that specific network as evidence about the venue's solvency — read our withdrawal pause guide for the distinction between a network-scoped and a venue-scoped pause.

And for high-value receipts where you are the settlement point, decide the confirmation count before the transfer, in writing, based on the chain and the amount — not while watching a wallet and feeling impatient.

What networks and venues do about it

Networks have a small set of responses and each has a cost. Increasing the cost of block production raises the price of a majority attack but does not change the mechanism. Fork-choice modifications such as the MESS proposal make deep reorgs disproportionately expensive by making nodes reluctant to abandon a chain they already hold — at the cost of introducing a subjective element, since two nodes that saw the network in different orders can now reach different conclusions. Checkpointing, whether by clients or against an external anchor, is a stronger version of the same trade.

Proof-of-stake finality is a different answer: rather than making a deep reorg expensive in ongoing costs, it makes it expensive in destroyed capital, with the price defined in the protocol. It also introduces the liveness failure mode described above, which proof-of-work chains largely do not have — a proof-of-work chain with low participation gets slow, not unfinalized.

Venues have three tools and use all of them. They set confirmation requirements per asset. They monitor for reorgs and suspend crediting when depth exceeds expectations. And they retain the contractual ability to reverse a credit that a reorg invalidated, which is why the terms governing deposits are worth reading before the event rather than after. The Bitcoin SV response of asking node operators to mark specific chains invalid is a fourth tool, and it is a reminder that at the extreme the defence is social coordination rather than protocol mechanics.

None of these make a chain reorg-proof, and a notice that claims otherwise is overstating. What they do is move the depth at which an attack becomes uneconomic. Reading a defence announcement well means asking what depth it protects against and at what cost — not whether it makes the problem go away.

Questions readers ask about reorganizations

Did my transaction disappear?

Almost never. A transaction in a stale block returns to the pending pool and is normally mined again. It disappears permanently only if a conflicting transaction spending the same inputs was confirmed on the accepted chain — which is what a double spend is, and which requires someone to have deliberately constructed it.

How many confirmations are enough?

There is no universal number. It depends on the chain's production capacity, whether that capacity is rentable, the value at stake and who your counterparty is. The venue you are using has already made this decision for deposits it credits; for a direct peer-to-peer receipt, you are making it yourself.

Can Bitcoin or Ethereum be reorganized deeply?

Both are far more expensive to attack than the networks in the documented record above, and neither has experienced an attack-driven deep reorg. Both have experienced multi-block reorgs from software faults — Bitcoin in 2010, 2013 and 2015, Ethereum in 2022 — which is a different cause with a different fix.

Is a reorg the same as a hard fork?

No. A reorg changes which chain of valid blocks is accepted under unchanged rules. A hard fork changes the rules. A software-compatibility accident can produce both at once, which is why the March 2013 Bitcoin incident is confusing to read about.

My exchange reversed a deposit after a reorg. Is that allowed?

Generally yes, under the venue's deposit terms, because the underlying transaction is no longer on the accepted chain — the venue credited something that, on the network's final record, did not happen. That is a contractual matter between you and the venue, and the deposit terms are where the answer lives. It is not an issue the blockchain can arbitrate.

Does a finality delay mean my ETH is at risk?

No. During the May 2023 incidents the chain kept producing blocks and no history was rewritten. What paused was the guarantee that recent blocks were irreversible, which affects systems waiting on finalization rather than balances.

Is the tracker a live monitor?

No. It is a historical dataset with a 23 August 2026 cutoff, built from primary alerts, post-mortems and technical reports. It is not exhaustive and it does not observe live chain conditions. For an ongoing event, use the network's own channel and your venue's status page.

Open the chain reorganization tracker to filter these events by cause, network and depth, or return to the announcement explainer for the shorter decision cards.