The deepest Litecoin reorg in history was an eighteen-month-old bug.

On April 25, Litecoin reorganized 13 blocks deep. It wasn't an attack. It was a consensus-critical flaw in MWEB peg-out validation that had been shipping in production since November. Coinbase saw it first. THORChain auto-halted in thirty minutes. NEAR Intents disclosed $600K. And the response chain inverted the usual order.

On April 25, 2026, at 10:42 UTC, Coinbase posted a quiet status incident: "delayed sends/receives" on Litecoin. Six hours and twenty-eight minutes later, Aurora Labs founder Alex Shevchenko posted to X that LTC had just reorganized 13 blocks deep. By the time crypto Twitter understood what happened, the patched chain had already won, the bug was patched on GitHub, and THORChain's automated solvency checker had hard-halted the LTC chain over a $500 vault discrepancy.⁰¹

This was the deepest Litecoin reorg in history and the deepest non-attack proof-of-work reorganization on a top-10 chain since Bitcoin's BIP50 incident in March 2013.¹⁵ It was caused by a consensus-critical bug in MWEB (Mimblewimble Extension Block) peg-out validation that had been shipping in production for nearly eighteen months. And the response chain inverted the usual order of how crypto news breaks.

§ 01 The detection

Most crypto news travels X-first. A whale spots an anomaly. ZachXBT confirms. Coingecko data follows. Forty minutes later the Coinbase support page acknowledges. Then Bloomberg.

This event ran the opposite direction.

The first public-facing acknowledgment was Coinbase's status page at 10:42 UTC: a "delayed sends/receives" incident with no mention of a reorg.⁰⁹ Whatever Coinbase saw — almost certainly internal custody-side telemetry showing LTC deposits failing to confirm at expected depths — predated any X analytical thread by six hours and twenty-eight minutes.

The X chatter only started at 17:10:31 UTC, when Shevchenko posted that NEAR Intents had detected a 13-block reorg on Litecoin and that the protocol was facing approximately $600,000 of exposure. Onchain analyst Zacodil followed at 17:36 with the depth confirmation. Zooko Wilcox of Zcash weighed in at 17:46 with the historical pattern context. The Litecoin Foundation's official statement landed at 20:22:23 UTC — three hours after the X thread started, and almost ten hours after Coinbase's first public signal.⁰²

The detection chain matters because it inverts the usual narrative about exchanges being slow. In this incident, custody-side telemetry was the first reliable indicator. The X threads that eventually drove discourse were responding to a symptom — failing deposits — that an institution had detected hours earlier and was already working through.

§ 02 The bug

Litecoin's official account, posted at 20:22 UTC by the @litecoin handle:

A zero-day bug caused a DoS attack that disrupted major mining pools. Non-updated mining nodes allowed an invalid MWEB transaction allowing them to peg out coins to third party DEXs. A 13-block reorg reversed those invalid transactions.@litecoin · X · 2026-04-25 20:22 UTC

The fix shipped as Litecoin Core v0.21.5.4 the same day, authored entirely by core developer David Burkett. Fifteen commits in a single push, with two consensus-critical changes: 1dcbf3f ("Consensus: Freeze MWEB-rebalancing output") and 42e7071 ("Prevent kernel fee overflow").⁰³ The release notes describe the underlying flaw verbatim:

A consensus fix for an input validation flaw that could allow the MWEB kernel sum to become unbalanced. Miners are blocked from including MWEB transactions when the input and output commitments in the block would sum to zero.Litecoin Core v0.21.5.4 release notes · 2026-04-25

The bug had been live in production since Litecoin Core v0.21.4, released on November 7, 2024. That's seventeen months and eighteen days of exposure between deployment and discovery — almost a year and a half of consensus-critical code shipping in production unnoticed. No CVE was assigned. The original LIP-0002 design document for Extension Blocks — published years earlier — explicitly warned that peg-out transaction hashes "will change if there's a reorg."⁰⁴ That warning was foundational to MWEB's design intent. The April 25 reorg was, in a strict sense, the protocol working as the original designers warned it could.

§ 03 The mechanism

The single most important technical fact in distinguishing this event from a 51% attack: the orphaned 13 blocks took roughly three hours to be mined. Litecoin's target block time is 2.5 minutes. Thirteen blocks should take 32.5 minutes on the canonical chain. The orphaned branch took roughly 5.5× that.

A 51% attacker's branch mines faster than honest, not slower — that's the entire point of the attack. So a 3-hour-for-13-blocks signature rules out a deliberate rented-hashrate attack outright. It also rules out selfish mining, which produces blocks at honest-chain speed or faster while withholding them. What it leaves is a partial-hashrate split: a subset of mining pools running unpatched binaries that accepted the invalid MWEB transaction and built blocks on top of it, while the patched-software cohort rejected the same transaction and built a separate canonical chain.

The unpatched cohort's hashrate share was roughly 18% of the network total — derived from the ratio of expected vs. actual block times. That share is too small for any single top-2 pool (ViaBTC at ~28% or F2Pool at ~25%) to have caused alone. Most likely a combination of two or three medium pools running stale node binaries.

This places the event firmly in the BIP50 historical class.¹⁵ In March 2013, Bitcoin reorged 24 blocks because nodes running v0.7 and v0.8 disagreed on whether a particular block was valid. Same pattern: not an attack, just a software-version split that produced a partial chain fork until enough hashrate updated to converge. The 2026 Litecoin event is the deepest non-attack proof-of-work reorg on a top-10 chain since.

§ 04 The ledger

Concrete dollar exposure across the ecosystem, sourced from primary on-chain data and protocol disclosures:

The aggregate financial damage is small in absolute terms — and concentrated in cross-chain venues that finalized off-chain transactions before the LTC reorg reversed the on-chain inbounds. NEAR Intents publicly disclosed approximately $600,000 of exposure to invalid peg-out transactions and stated the team would cover any user losses.¹¹ Because the canonical chain ultimately erased those invalid transactions, NEAR Intents' realized loss is likely materially smaller than the disclosed figure: only the destination-chain outbound (which NEAR Intents already paid out to users on chains like Solana or Ethereum) constitutes the actual loss. The LTC inbound NEAR Intents was crediting against simply does not exist on the canonical chain.

THORChain's exposure is more interesting structurally. The protocol's automated solvency-checker — PermittedSolvencyGapUSD, defaulted to $500 — tripped at THORChain block 25,914,181 and set four Mimir flags simultaneously: HALTLTCCHAIN: 1, HALTLTCTRADING: 1, HALTSIGNINGLTC: 1, and SOLVENCYHALTLTCCHAIN: 25914181.⁰⁵ The official LTC inbound address ltc1qayml3n2nyavx0saqjpkz07h0wcpdum59c9j2m4 returns halted: true and chain_trading_paused: true to anyone querying the THORChain inbound-addresses endpoint.⁰⁶ All 40,724 LTC ($2.28M) sitting in five active Asgard vaults is intact — funds cannot move while the chain is paused. No realized loss on THORChain's books, but the protocol stopped processing LTC swaps the moment the solvency check caught the discrepancy.

§ 05 The auto-halt and what it means

This is where the story gets interesting for anyone who read my prior editorial on the THORChain Bybit response.¹⁶

JP Thorbjornsen, THORChain's founder, posted to X within an hour of the halt:

THORChain automatically: 1) detected the reorg and removed the transactions from the network 2) subsequently detected a $500 insolvency and halted the chain. This is built into the protocol itself and required no human input.JP Thorbjornsen · @jpthor · X · 2026-04-25

That was the trigger for an immediate round of criticism on X. From David Cumps, replying to JP's thread:

lol, can't pause the protocol to stop millions from a hack, but for $500 loss @THORChain is suddenly able to pause itDavid Cumps · @cumpsd · X · 2026-04-25

And from @monerify, amplifying:

unstoppable protocol thorchain pauses LTC swaps due to the recent double spend attack — oh but when it comes to helping the north koreans launder money it's a permissionless protocol@monerify · X · 2026-04-25

The criticism is rhetorically strong and surface-plausible. It's also wrong, and wrong in a specific and clarifying way.

I argued this in the THORChain editorial three days ago and I'll restate it here because the LTC event is the cleanest possible illustration. There is a categorical distinction between protocol-survival halts and third-party-user-funds-adjudication halts. They use the same governance machinery. They are not the same kind of decision.

A protocol-survival halt is when the protocol's own solvency, accounting, or vault balances are at risk. THORChain's January 2025 THORFi halt was this: a $200M internal liability the protocol itself was carrying. The April 25 LTC solvency-halt is also this: a $500 gap between THORChain's own on-chain bookkeeping and its physical LTC vault holdings, caused by an external reorg invalidating LTC inbound observations the protocol had already credited internally. In both cases the halt is the protocol defending its own books. There is no censorship dimension. There is no third party whose funds are being adjudicated. The protocol is acting on its own state.

A third-party-user-funds-adjudication halt is what the post-Bybit critics demanded in February 2025: that THORChain's validators inspect the origin of user funds and refuse to process swaps where the source was disfavored. That is a categorically different decision, and it's the one the validator set declined to make. Validators voted to be infrastructure, not deputies. Three voted to halt; four voted to keep the protocol open.¹⁶

The April 25 LTC auto-halt does not contradict that decision. It validates it. The same machinery that protected THORChain's books from a $500 reorg-induced gap is exactly the machinery that should not be re-purposed to adjudicate the moral status of user-controlled inbounds. When critics say "you halted for $500 but not for the Bybit billions," they are describing two different kinds of decisions and treating them as the same.

If you read the Bybit piece and disagreed with the framing, the LTC event is the test. The protocol halted itself the moment its own solvency was at risk, automatically, without human input, in thirty minutes. The Bybit non-halt was not a failure of capacity. It was the same governance system applied to a categorically different question and arriving at a categorically different answer.

I think that distinction is intellectually correct. I also think the optics of the thirty-minute LTC auto-halt next to the seventy-two-hour Bybit non-halt make the framing harder to defend in public, because most people don't draw category lines this finely. The Litecoin team's official line — "the chain is safe, the bug is patched, the reorg actually protected the network" — is technically true but does not address the political point. THORChain's framing has the same shape.

§ 06 What this means for cross-chain DeFi

Three operational takeaways that affect every cross-chain protocol that touches Litecoin (and by extension, anything that touches a top-10 PoW chain).

Confirmation depth was one block short almost everywhere. Coinbase's LTC deposit policy was raised to 12 confirmations in 2019 specifically to mitigate this class of risk. The 13-block reorg sat exactly one block above that threshold. Kraken (12), OKX (12), Binance (6), and most other major exchanges had thresholds the reorg exceeded. THORChain's MAXCONFIRMATIONS-LTC was 6. Every major venue's deposit-confirmation policy assumed a reorg of this depth was so improbable as to not warrant defending against. That assumption held for thirteen years. It just stopped holding.

No DeFi insurer sells named "reorg cover" today. Nexus Mutual offers no chain-level reorg product. Risk Harbor has the closest parametric architecture but no LTC reorg coverage. The April 25 event is exactly the kind of incident the DeFi insurance market should price — a $600K NEAR Intents loss is well within the size that an insurer would underwrite — but the product simply doesn't exist. That's a gap.

Software-monoculture is the underlying structural risk. Litecoin's consensus split happened because two or three medium mining pools were running unpatched node binaries nearly eighteen months after the (then-unknown) bug shipped. A protocol designed with expected hashrate diversity assumed software-version diversity as a corollary. It got the opposite. The same risk exists on Bitcoin — Bitcoin Core has a near-monoculture share of the network — and the same exists on every PoW chain whose pools standardize on a single reference client.

For LeoDex specifically: we route through THORChain (currently halted for LTC), MAYAChain (no active LTC pool), Chainflip (no LTC support), and NEAR Intents ($600K exposure self-disclosed, pledged user coverage). We aggregate every venue. We screen at our frontend against sanctions lists. None of those venues had a worse outcome than its own design constraints predicted, and the most exposed venues are the ones most directly working through their disclosures.

I don't know how the LTC reorg story ends. The patch is shipping. The halts will lift when node operators are confident the chain is stable. NEAR Intents will publish a final realized-loss figure or quietly absorb it. The Litecoin Foundation will probably propose a confirmation-depth advisory. Cross-chain protocols will quietly raise their LTC confirmation requirements to 14+ where they were at 6.

The deeper question — whether a top-10 PoW chain can afford a year and a half of consensus-critical bug exposure in production — is the one that should make every chain operator nervous. This wasn't a malicious attack. It was a Tuesday with a partial network upgrade gap. The protocols that absorbed the cost were the protocols that built proper automated defenses. The protocols that sailed through were the ones whose confirmation policies happened to be one block deeper than the reorg.

That's a lot of luck dressed up as design.