THORChain Trading Halt Follows an Incorrect Refund
The THORChain trading halt followed an October 31 incident in which a vault paid out 10 ETH against a deposit that had not settled on Ethereum’s canonical chain—the transaction history the network ultimately accepted.
According to the project’s incident statement, reproduced by CoinAlerts, the user returned the excess funds. Ten external-chain integrations remained halted in that update, while AVAX, BASE, RUNE and XRPL trading was listed as available.
THORChain paused its own services involving those networks. It did not stop Bitcoin, Ethereum, Solana or the other underlying blockchains.
How the Ethereum Reorganisation Triggered the Error
THORChain’s account places the one-block reorganisation at 11:34 UTC on October 31.
A 10 ETH deposit appeared in the discarded block, but THORChain had already observed and credited it. The associated swap failed its price limit and triggered a refund. The sender’s actual deposit was also refunded, leaving the vault short.
The project said nodes detected the reorganisation, but a follow-up check failed to resolve the deposit’s status before it was finalised within THORChain.
The important distinction is between observing a transaction and safely treating it as settled. Here, the project’s explanation describes an accounting and refund failure following a change in the external chain’s accepted history.
What Stopped Further Outflows?
THORChain said its automatic solvency checker halted ETH swaps after detecting the shortfall. Within approximately two minutes, node operators stopped ETH transaction signing, followed by broader precautionary restrictions.
The protocol’s security documentation explains the purpose of these controls. Solvency checks compare expected vault balances with actual holdings. Trading halts and signing halts serve different functions: stopping swaps restricts trading, while stopping signing prevents new outbound transactions from being authorised.
These controls can limit damage after a discrepancy appears. Their activation does not establish that the software condition responsible for the discrepancy has been fixed.
Which THORChain Services Were Affected?
The project’s November 1 statement listed the following status:
Status in the update | Networks or native asset |
|---|---|
Trading available | AVAX, BASE, RUNE, XRPL |
Trading halted | ATOM, BCH, BSC, BTC, DOGE, ETH, LTC, SOL, TRON, ZEC |
This is a dated status snapshot, not confirmation of availability at the moment a reader initiates a transaction.
For users, the distinction between a functioning blockchain and an available swap route is essential. An Ethereum transaction may process normally while a service that exchanges ETH for another asset remains unavailable.
Bitnxt’s safe-transfer guide provides related background on checking destination addresses and network compatibility. A paused protocol route adds another operational condition to verify before moving funds.
Why Returning the Funds Does Not Complete Recovery
Restoring a vault balance addresses the immediate financial discrepancy. Recovery also requires correcting the faulty behaviour and determining when affected integrations can reopen.
THORChain’s emergency procedures describe node-led restrictions, investigation and subsequent decisions to resume operations once threats are mitigated. This separates emergency containment from the process of restoring service.
There is historical context for that emphasis. THORChain’s own third-quarter report describes August disruptions involving inconsistent results across nodes, followed by a hotfix and additional checks before affected application-layer activity resumed. Those were different technical problems, but they illustrate why a restart requires more than correcting a balance.
Bitnxt’s Take: The Remaining Risk Matters More Than the Amount
Our assessment is that the returned 10 ETH is reassuring for the affected vault, but the broader lesson concerns how cross-chain systems respond when an external blockchain changes its recent history.
A small discrepancy can expose a failure with wider implications. Conversely, a precautionary pause across several integrations does not establish losses on every affected network.
Bitnxt’s earlier coverage of Aave’s precautionary reserve freezes highlighted a similar operational distinction: restrictions can protect a protocol while creating practical access problems for legitimate users. The two incidents have different causes.
The next meaningful evidence will be a published fix, confirmation that operators have adopted it, and explicit reopening notices. Those developments would establish progress more clearly than treating the returned funds as a complete all-clear.
