THORChain Paid Out 10 ETH It Never Received: The Reorg Bug That Could Happen Again

The decentralized cross-chain liquidity protocol THORChain found itself in a precarious situation on October 31, 2023, when a one-block reorganization on the Ethereum network caused it to erroneously refund 10 ETH it had never actually received. This incident, while swiftly contained by THORChain’s internal safety mechanisms and resolved with the return of the funds, has…

 Avatar

by

9 minutes

Read Time

The decentralized cross-chain liquidity protocol THORChain found itself in a precarious situation on October 31, 2023, when a one-block reorganization on the Ethereum network caused it to erroneously refund 10 ETH it had never actually received. This incident, while swiftly contained by THORChain’s internal safety mechanisms and resolved with the return of the funds, has unveiled a critical vulnerability that the protocol itself warns could be exploited again under similar circumstances on any of the external chains it integrates with. This development shifts the narrative from an isolated technical glitch to a systemic risk within the complex architecture of cross-chain decentralized finance.

Understanding the Mechanics of a Blockchain Reorganization

To fully grasp the implications of the THORChain incident, it is essential to understand what a blockchain reorganization, or "reorg," entails. Blockchains operate by appending new blocks of transactions to an existing chain. Occasionally, two different valid blocks are mined almost simultaneously, creating a temporary fork in the chain. Network participants then build on one of these forks. When one fork gains more computational power and extends further, the shorter, competing fork is "reorganized" out of existence. Transactions included only in the orphaned blocks are effectively erased from the canonical history of the blockchain.

On robust, high-security networks like Ethereum, reorgs are a rare but normal occurrence, typically shallow (one or two blocks deep) and quickly resolved. They are usually a consequence of network latency or minor synchronization issues among validators. While generally benign, they introduce a fleeting period of uncertainty regarding transaction finality – the point at which a transaction can be considered irreversible. For protocols that interact with multiple chains, like THORChain, this brief window of uncertainty can become a critical vulnerability.

The October 31 Incident: A Chronology of Events

The incident unfolded at precisely 11:34 UTC on Saturday, October 31. A user initiated a deposit of 10 ETH into THORChain’s system, intending to perform a cross-chain swap. This transaction was successfully included in an Ethereum block. THORChain’s sophisticated observation system, designed to monitor and interpret events across integrated blockchains, promptly registered this deposit. Based on its observation, THORChain’s internal state machine credited the user with the 10 ETH, marking it as received and preparing it for the subsequent swap.

However, almost immediately after this credit, the Ethereum network experienced a one-block reorganization. A competing block was validated and replaced the block containing the user’s initial 10 ETH deposit. Consequently, the original deposit transaction was effectively erased from Ethereum’s canonical chain history.

THORChain Paid Out 10 ETH It Never Received: The Reorg Bug That Could Happen Again

Crucially, THORChain’s internal state did not immediately reflect this change. There was a critical, albeit short, window during which THORChain continued to operate under the belief that it had received the 10 ETH, while the underlying Ethereum chain had, in reality, nullified the deposit. This divergence between THORChain’s ledger and Ethereum’s finalized state formed the crux of the exploit.

The swap associated with the now-erased 10 ETH deposit then failed, likely due to a predefined price limit or other execution conditions that could not be met given the market state or the non-existence of the deposit itself. In such scenarios, THORChain’s protocol is designed to initiate a refund to the user. This is where the vulnerability manifested. The refund logic, unaware that the original deposit had been reverted on Ethereum, proceeded to process a refund for 10 ETH from THORChain’s vaults. Simultaneously, because the original deposit transaction was orphaned by the Ethereum reorg, the user’s initial 10 ETH never actually left their wallet on the canonical chain. The result was a double payout: the user effectively retained their original 10 ETH and received an additional 10 ETH refund from THORChain’s vaults, leading to a net loss of 10 ETH for the protocol.

THORChain’s Robust Response and Safeguards

Despite the exploit, THORChain’s internal safety mechanisms proved effective in containing the damage. The protocol’s Automatic Solvency Checker (ASC), a critical circuit breaker implemented after previous security incidents, detected the discrepancy between the expected vault balance and the actual funds held. This system, designed to continuously monitor the integrity of THORChain’s liquidity pools, immediately triggered an automatic pause of cross-chain swaps.

The pause was comprehensive, halting operations for assets across 10 different networks integrated with THORChain, including major blockchains like Bitcoin, Ethereum, Solana, and Tron. For a cross-chain liquidity protocol, such a widespread halt represents a near-complete standstill, underscoring the severity of the detected anomaly.

The timing of this pause garnered additional attention from the wider cryptocurrency community. Notably, blockchain analytics firm Chainalysis reported that the halt inadvertently slowed down the laundering of funds stolen in a recent Binance hack. THORChain has historically been identified as one of the routes used by malicious actors to move and obscure stolen assets, with Elliptic’s analysis describing such laundering as "running on autopilot." THORChain, however, clarified that the pause was a direct consequence of the reorg bug and its automated safety protocols, not a deliberate action targeting the Binance thieves.

In a positive turn, the recipient of the erroneous 10 ETH refund acted responsibly and returned the surplus funds to THORChain. This swift recovery restored the vault’s balance and mitigated the financial loss to the protocol.

The Critical Warning: A Systemic Vulnerability

THORChain Paid Out 10 ETH It Never Received: The Reorg Bug That Could Happen Again

While the immediate financial loss was recuperated, the incident’s most significant outcome is THORChain’s subsequent public warning. Initially, many in the crypto community viewed the event as an isolated "freak accident"—a rare confluence of a blockchain reorg and a protocol’s refund mechanism. However, THORChain’s official statement unequivocally shifted this perspective.

The protocol explicitly 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." This statement elevates the incident from a one-off error to a persistent, exploitable vulnerability.

The "nonce" detail is crucial here. In blockchain transactions, a nonce (number used once) is a sequential number assigned to each transaction originating from a specific address. It ensures that transactions are processed in order and prevents replay attacks. When a transaction is orphaned during a reorg, its associated nonce becomes available again. A malicious actor, having observed an original deposit transaction that subsequently falls out of the canonical chain due to a reorg, could craft a new transaction using the same nonce. If this new transaction is designed to trigger THORChain’s refund logic against a deposit that the protocol still believes it received (but which was actually erased by the reorg), the vaults would again pay out funds they never truly possessed.

This means an attacker would not need to cause a reorg, which is technically challenging and expensive on a network like Ethereum. Instead, they would only need to monitor for naturally occurring reorgs on any of the numerous chains THORChain integrates with. Once a suitable reorg occurs, they could then execute a pre-prepared transaction that leverages the nonce vulnerability, effectively tricking THORChain into a double payout. Given that reorgs, however rare, are an inherent operational aspect of proof-of-work and some proof-of-stake blockchains, this vulnerability presents an ongoing risk.

Recurring Refund Logic Vulnerabilities

This is not the first instance where THORChain’s refund mechanics have been identified as a weak point in its security architecture. In 2021, the protocol suffered significant losses during the "ETH router exploits," where attackers drained approximately 4,200 ETH (worth around $7.6 million at the time) by manipulating refund logic. In that incident, attackers exploited malformed memo instructions—the internal commands that guide THORChain swaps—to force the protocol to issue erroneous refunds.

While the specific attack vectors differ—the 2021 exploits abused instruction parsing, whereas the 2023 reorg bug stems from a divergence in chain state—the underlying theme remains consistent: THORChain’s refund mechanism, intended as a safe fallback for failed transactions, has repeatedly become an avenue for value extraction. This pattern suggests a deeper architectural challenge in how THORChain’s state machine reconciles with the asynchronous and eventually consistent nature of external blockchains.

Broader Implications for Cross-Chain Design

THORChain Paid Out 10 ETH It Never Received: The Reorg Bug That Could Happen Again

The THORChain reorg incident underscores a fundamental challenge in cross-chain protocol design: how to reliably interpret and act upon data from external blockchains, each with its own finality rules and consensus mechanisms. A protocol like THORChain, which aims to facilitate seamless asset swaps across disparate chains, must contend with the inherent risks of acting on data that might not yet be definitively finalized.

A sturdier approach, as highlighted by security experts, would involve implementing more conservative finality thresholds. This means treating a deposit as genuinely "final" only after a sufficient number of blocks have passed on the source chain, significantly reducing the probability of a reorg reversing the transaction. For Ethereum, while one-block reorgs are common, deep reorgs (beyond 6-12 blocks) are exceedingly rare. Introducing confirmation delays for deposits—e.g., waiting for 10-20 blocks to confirm a transaction before crediting it—could mitigate this specific vulnerability.

Furthermore, protocols need to implement more rigorous pre-refund checks. Before any refund is issued, THORChain’s internal logic should ideally verify the actual existence and validity of the original deposit on the external chain, not just rely on its own credited state. This would involve a real-time query to the external chain’s current canonical state, ensuring that the deposit hasn’t been orphaned.

What Comes Next for THORChain Users and the Protocol

With the 10 ETH restored and the immediate crisis averted, THORChain faces the critical task of patching this vulnerability before resuming full operations. The protocol has not yet announced a date for restarting the paused chains, which is a prudent decision given the public disclosure of the bug. Restarting operations prematurely would expose liquidity providers and users to potential losses from opportunistic attackers awaiting the next reorg event.

For users and liquidity providers, several key questions remain. How will THORChain adjust its handling of deposits to account for reorg risks? Will it implement longer confirmation delays, thereby impacting transaction speed? How will its refund logic be reconciled with real-time external chain states? The team’s public acknowledgment of the risk indicates that a robust fix is a top priority.

Security researchers are expected to delve deeply into this incident. The mechanism of the exploit is relatively straightforward to understand, and the traces of the reorged Ethereum block, the dropped deposit, and the double payout are all publicly accessible via blockchain explorers. This accessibility makes the bug highly scrutinizable and emphasizes the urgency of a comprehensive solution. The incident serves as a stark reminder that even seemingly minor blockchain events like a one-block reorg can have significant financial consequences for complex cross-chain protocols holding substantial user funds. The ongoing challenge for THORChain, and indeed for the broader DeFi ecosystem, is to engineer systems that are not only efficient but also resilient against the inherent uncertainties of distributed ledger technologies.

Disclaimer: This article provides general information and is not intended as financial or investment advice. Always conduct thorough research before engaging in any cryptocurrency transactions or investments.

About the Author

About the Author

Easy WordPress Websites Builder: Versatile Demos for Blogs, News, eCommerce and More – One-Click Import, No Coding! 1000+ Ready-made Templates for Stunning Newspaper, Magazine, Blog, and Publishing Websites.

BlockSpare — News, Magazine and Blog Addons for (Gutenberg) Block Editor

Search the Archives

Access over the years of investigative journalism and breaking reports