THORChain Halts After ETH Reorg Double Payout

On 31 October 2026, THORChain node operators halted trading on most of the chains the cross-chain swap network supports. The trigger was not an exploit in the usual sense. It was a routine event on Ethereum: a one-block reorganisation. Here is what happened, what we could confirm, and why it matters.

What happened#

According to THORChain's own account, published on X on 1 November, Ethereum had a one-block reorg at 11:34 UTC on 31 October. A 10 ETH deposit to one of THORChain's vaults sat in the dropped block and never landed on the canonical chain. THORChain had already observed and credited that deposit. The requested swap then missed its price limit and was refunded, so the vault paid out 10 ETH it had never received. The sender's real deposit, which did reach the chain, was refunded as well.

THORChain says every node detected the reorg, but "the re-check that should have removed the deposit could not get a clear answer in time, so it was finalized." The safeguard existed; it simply did not resolve in time.

What we could verify#

Etherscan's public list of forked blocks shows block 26312477, timestamped 11:34:47 UTC on 31 October, with a reorg depth of 1. The canonical block at that height carries a timestamp of 11:34:59 UTC, which we read directly from a public Ethereum node. That matches THORChain's timeline.

The same list shows how ordinary this is: its first page alone records 25 depth-1 reorgs on Ethereum mainnet between 29 October and 1 November. A one-block reorg is not an attack on Ethereum. It is a normal property of a live network, and any system that credits deposits must handle it.

We also queried THORChain's live network parameters (mimir) through a public THORNode API on the morning of 2 November, at 06:33 UTC and again at 07:11 UTC. At both reads, chain and trading halts were still set for ETH, BTC, BCH, BSC, DOGE, LTC, TRON, ZEC and ATOM (GAIA), with Solana trading also halted. AVAX, BASE and XRP trading were not halted. ETH outbound signing was no longer halted, and the per-vault solvency halt for the affected ETH vault was cleared. No reopening date has been given.

Containment and recovery#

THORChain reports that its automatic solvency checker caught the shortfall and halted ETH swaps. Within about two minutes, node operators halted ETH transaction signing, so no further ETH could leave the vaults. Operators then halted all chains as a precaution. THORChain states that the user has returned the 10 ETH and the vault is solvent again. An early incident note relayed by Tree News said nothing suggested the double payout was intentional.

THORChain was direct about the residual risk: "Now that this is public knowledge, every time there is a block re-org on an external chain, a malicious actor could perform a new transaction with the same nonce and would be paid funds by the THORChain vaults." That is why the halt continued after the funds came back. THORChain says core developers are working on the necessary fixes; its early incident note said fixes to Bifrost, the component that observes external chains, and to thornode would ship in the next release. Nodes will re-enable chains "as they are deemed safe."

Cointelegraph reports that Chainalysis said the pause also delayed some cross-chain movements of stolen funds. That is a side effect, not the cause of the halt.

What remains open#

THORChain has not published the code-level root cause, the exact number of confirmations involved, a date for the release or a date for reopening the halted chains. We treat all of these as unknown. Reporting differs on how many chains were halted; we rely on THORChain's own list and on the live parameters we read.

Our view#

The lesson is about finality, not about one protocol. Any bridge, swap network or custody system that acts on a deposit from another chain is making a bet on when that deposit is final. Here the bet was lost on 10 ETH, and layered controls (an automatic solvency check, fast operator action and a cooperative user) limited the damage. The design question for every such system is the same: what happens if the deposit you credited disappears? The answer should be written into the system before a reorg asks it.