A one-block Ethereum reorg led THORChain to refund 10 ETH it never got. The protocol now warns that a reorg on any external chain could set off the same exploit.
A deposit that no longer exists can still be refunded. That is what happened to THORChain on October 31, and the protocol itself says the same trick could work again.
A One-Block Reorg Erases a Deposit
According to THORChain’s own account, the incident began at 11:34 UTC on Saturday, October 31. Ethereum went through a one-block reorganization, which happens when the network replaces a recent block with a competing one. A 10 ETH deposit that THORChain had already credited dropped off the canonical chain.
THORChain never noticed. It kept treating the deposit as real, and that gap is the heart of the whole incident: a short window between what the protocol believed and what Ethereum had actually finalized.
How the Refund Paid Out Twice
The swap tied to that deposit had a price limit. With the deposit gone and the market where it was, the swap couldn’t meet that limit, so THORChain’s refund logic took over. It sent a refund against funds the vault had never received.
Meanwhile, the sender’s real deposit was also returned, which meant the vault paid out an extra 10 ETH. Put simply, THORChain covered a transaction that Ethereum had already written out of history. The vault came up short, and its Automatic Solvency Checker spotted the discrepancy and triggered an automatic pause. That is exactly what it was built to do. THORChain added the checker as a circuit breaker after earlier incidents, and this time it worked.
Ten Chains Go Quiet
Node operators halted swaps for assets on 10 networks, among them Bitcoin, Ethereum, Solana and Tron. For a cross-chain liquidity protocol, that is close to a complete standstill.
The timing drew extra attention. Chainalysis reported that the halt slowed the laundering of funds stolen in the recent Binance hack, since THORChain has been one of the routes used to move them. Elliptic’s analysis had earlier described that laundering as running on autopilot, with money crossing chains at a steady, automated pace. THORChain’s own explanation was far plainer: the pause came from the reorg bug, not from any deliberate move against the Binance thieves.
The Warning That Changes the Story
Most coverage stopped at the freak-accident angle. A glitch hit a protocol, the safety system held, and the 10 ETH came back once the recipient returned the extra funds. That is accurate as far as it goes.
THORChain went further in its own statement, and that part matters most. The team warned that, now that the bug is public, “every time there’s 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.”
With that one line, a single incident becomes an ongoing risk. Reorgs are a normal part of how external chains operate. They are rare on a network like Ethereum, but they do happen, and THORChain connects to a lot of chains. An attacker wouldn’t have to cause a reorg. They would only have to be ready when one occurs naturally, with a transaction built so the refund path fires against a deposit that has already vanished.
The nonce detail deserves a closer look. Reusing a nonce is how a replacement transaction can take the original’s place on the canonical chain. During a reorg, the original deposit falls out and a competing transaction can claim its slot. If the protocol has already credited the first one, its books and the chain no longer match.
Why Refunds Keep Showing Up in THORChain Incidents
This is not the first time THORChain’s refund mechanics have been the weak spot. In its post-mortem on the 2021 ETH router exploits, the protocol explained how attackers drained roughly 4,200 ETH by forcing a refund with a deliberately bad memo.
The mechanics differ, of course. The 2021 attack abused malformed instructions, while the 2026 bug comes from chain state shifting underneath the protocol. Still, refunds link the two. A refund is meant to be the safe, boring fallback when a swap can’t complete, yet in both cases it became the way value left the vaults.
This points to a wider issue in cross-chain design. Each external chain has its own finality rules, so a protocol that acts on unconfirmed or reversible data takes on those risks as its own. A sturdier approach is to treat a deposit as final only once the source chain’s reorg risk has passed, and to check vault balances against chain state before any refund goes out.
What Comes Next for THORChain Users
According to the latest reports, the vault balance has been restored because the recipient sent back the surplus 10 ETH. THORChain hasn’t named a date for resuming the paused chains, which makes sense given the stakes. Restarting before the flaw is patched would give the same opening to anyone waiting for the next reorg.
For users and liquidity providers, the open questions are fairly direct. How will THORChain handle deposits sitting in blocks that could still be reorganized? Will it add confirmation delays, or reconcile refund logic against chain state? The team has flagged the risk publicly, so a fix is clearly a priority.
I also expect security researchers to dig into this. The mechanism is simple to grasp and general enough to apply across chains. Anyone can find the reorged Ethereum block, spot the dropped deposit and trace the double payout through block explorers. That is why this incident calls for more than a retelling of THORChain’s statement. What a missed reorg can cost is the real concern: a publicly known bug, in a protocol holding user funds across ten networks.
Disclosure: This is not trading or investment advice. Always do your research before buying any cryptocurrency or investing in any services.
Follow us on Twitter @themerklehash to stay updated with the latest Crypto, NFT, AI, Cybersecurity, and Metaverse news!
Source link