THORChain pauses after 10 ETH refund error: how to check an unfinished swap

The 10 ETH error and the wider interruption

TokenPost published its report at 01:58 SGT on November 1, corresponding to 13:58 EDT on October 31. It says an Ethereum reorganization caused THORChain to refund a user's 10 ETH deposit twice. The emergency response then interrupted swaps for users across most of the protocol's cross-chain bridges. The reported trigger was one deposit; the resulting service interruption reached beyond that account.

The deposit amount needs to stay attached to its actual meaning. Ten ETH was the size of the deposit involved in the duplicate refund. It is not a reported total loss for THORChain, a count of user deposits affected or an estimate of funds frozen across the service. The opened reports do not provide those totals. Turning the triggering amount into a system-wide damage estimate would answer a question the evidence does not resolve.

The sequence also matters. TokenPost describes a change to Ethereum's chain history, a refund error at THORChain and a protocol pause. That report supports a relationship between these events. It does not provide a complete technical reconstruction or establish that every pending transaction suffered the same error. Readers should avoid treating a concise incident report as a diagnosis of their individual account.

For a customer who has already sent assets, the useful question is narrower: which step has a transaction record, and which step is still waiting? A deposit record can identify what was sent. A refund record, if present, can identify what came back. A destination record can identify what reached the receiving chain. Keep each record attached to its own transaction rather than using a general headline to fill a missing step.

Why 12 of 13 chains is a snapshot

PANews says the status interface showed paused transactions on 12 of 13 listed chains. Its report attributes this observation to The Defiant. Odaily also carried the 12-of-13 figure and said outbound signing remained enabled on most chains. We read both reports for this article, but the overlapping wording and shared attribution do not establish independent technical confirmation. Odaily's report of the pause.

The arithmetic describes the breadth of the reported interruption: 12 listed chains were paused and one was outside that count. The reports do not identify the exception in their text. They also do not provide a chain-by-chain table from which a customer could decide that their exact route was available. Guessing the exception would be especially unhelpful to someone deciding whether to send a new deposit.

Treat the count as an observation made for the reports, not as a live reading refreshed whenever this article is opened. A later interface could show a different state. When checking a route, note the chain name, the operation being checked and the observation time in SGT. A screenshot without those details can leave the reader comparing different operations at different moments.

Outbound signing is the other part of the reported snapshot. Its continued availability on most chains does not demonstrate that a specific outbound transaction was signed, broadcast or received. Our reading is that the reports describe a service with different operational states, rather than a single switch that proves everything is either working or stopped. The reports themselves do not enumerate completed customer transactions.

The Binance connection does not prove funds were recovered

TokenPost attributes the laundering connection to Chainalysis. The analytics firm linked the interrupted route to North Korean hackers moving funds stolen from Binance and said the pause delayed that activity. PANews carries the same attribution. This is a reported finding by Chainalysis; the opened material does not include transaction-level evidence allowing us to reproduce its attribution.

The distinction between delay and recovery is central to this story. An unavailable swap route can interrupt an attempted movement through that route. That observation alone does not establish that assets have returned to Binance, that an address has been frozen or that the people controlling it have lost access. The reports describe delayed laundering. We do not turn that statement into a recovered-funds figure.

Nor do they give an amount for the funds whose movement was delayed. The phrase describing a large amount cannot be converted into a dollar number, a percentage of the wider Binance incident or a measure of permanent disruption. The 10 ETH deposit belongs to the refund error; it is not the missing laundering amount. Keeping these subjects separate prevents two unrelated quantities from being combined into a false calculation.

For Binance customers, the THORChain report therefore answers a question about a reported movement route. It does not answer when an exchange withdrawal will reach their wallet. Exchange processing and a cross-chain service pause need their own records. A customer with a pending Binance withdrawal should check that withdrawal's status and transaction reference through the account they already use, rather than infer completion from news about someone else's route.

If your swap was already submitted

Start with the transaction you actually made. Preserve the sending-chain transaction reference, asset, amount and destination you entered. Record when you sent it, then compare that record with any refund or destination transaction you can identify. These are reader steps prompted by the incident, not a claim that we inspected a particular user's records or verified a current recovery workflow.

If a refund appears, compare it with the original deposit before deciding the swap completed. The reported incident involved a refund error, which makes that distinction particularly relevant. Receiving something back and receiving the intended destination asset answer different questions. Save the transaction references so a support enquiry can describe the specific mismatch instead of relying on the general word “pending.”

If no destination transaction is visible, prepare a support enquiry with the sending-chain transaction reference, the route you selected and the destination address. Ask which operation remains unfinished: refund, outbound signing or destination transfer. The enabled-signing report supplies no receipt for your address.

For a new swap, check the exact route before sending a fresh deposit. The 12-of-13 headline cannot identify the unnamed exception, and the report does not verify present availability. Waiting for an identifiable route status and keeping a dated record is a concrete response to that gap. We have not established a restart time from the sources opened for this article.

Keep the incident check separate from compensation messages

Use the account interface or support route you already know to examine an existing transaction. An unsolicited message offering “Binance compensation” is not evidence that a THORChain swap has resumed or that a refund is owed. Do not supply a wallet recovery phrase or approve a new transaction merely to obtain an incident update. These are precautions for readers checking the story, rather than a report that we observed a particular scam campaign in this incident.

The same discipline applies to a screenshot said to show recovery. Ask which chain and transaction it concerns, which address received the funds and how it relates to the transfer you are checking. A picture of a different transfer cannot settle your own missing transaction. A quoted percentage about exchange backing cannot replace the destination record either.

Check the source before drawing a market conclusion

The opened reports provide no measured RUNE or ETH price reaction attributable to this pause. They also give no liquidation figure or exchange-wide trading restriction linked to it. A trader should therefore avoid turning this operational incident into an asserted market cause. Anyone comparing the event with a price chart would first need matching observation times and a separately sourced market record.

What would change this assessment

A useful next report would name the affected routes, give the time and scope of any restart, and explain the duplicate-refund correction. Those are the missing details that would make the current report more useful to customers. We do not have a verified total-loss figure, a complete list of affected transfers or a confirmed resumption time in the opened sources.

For the laundering claim, a recovery update would need to identify assets actually recovered or controlled, rather than simply repeat that a route was unavailable. For an individual swap, the decisive update is the transaction record corresponding to its unfinished step. Those are separate checks; progress on one should not be used to announce completion of the other.

Quick answers

Was 10 ETH the total loss?

TokenPost identifies 10 ETH as the deposit involved in the duplicate refund. It does not provide a total-loss figure.

Does enabled outbound signing prove my transfer arrived?

The reported signing state supplies no receipt for an individual transfer. Look for the transaction corresponding to the intended destination address.

Did the pause recover Binance funds?

The opened reports describe delayed laundering, attributed to Chainalysis. They do not identify assets recovered as a result of this pause.