$6.3 million just moved to Bitcoin in front of everyone watching, and nobody could stop it -- not because nobody tried, but perhaps because the most plausible response, a protocol-level address freeze, is not in their power.

On 24 September 2026, Bitget lost roughly $387.5 million after attackers penetrated the controls over its exchange wallets.

Four days later, the exchange's CEO made a public request directed at a third party: stop the hacker from using your protocol. THORChain said no. In the subsequent three hours, the attacker executed 27 swaps through it, transferring $6.3 million worth of the theft's proceeds into Bitcoin, in full public view.

Nobody disputes the events. The dispute is over the proposition that THORChain could have and should have stopped it.

The request

Bitget CEO Gracy Chen asked THORChain to cease servicing the attacker's identified wallet addresses. The exchange offered a 5% bounty -- over $19 million at the scale of the full hack -- for assistance in freezing or recovering the funds.

It is not an unreasonable request. THORChain is infrastructure that a hacker would need to use in order to convert stolen assets into something more useful in terms of their value than the original tokens.

THORChain's response is that it cannot and would not do what was being asked of it.

"A halt is not a selective freeze"

The first stated reason is architectural: THORChain's halt functionality is a network-level kill switch; there is no finer-grained mechanism to selectively block specific addresses.

"A halt is not a selective freeze of specific funds or an individual swap."

This is not a convenient fiction, but an accurate description of the system's limitations.

However, it is not the only reason given. THORChain takes the position that it would not implement such a system even if it had the capacity to do so, as the protocol is designed to be "useable by anyone, regardless of the origin of their funds".

In other words, there is no permission layer, no compliance, no KYC, and no way to determine whether funds being swapped are legitimate or not before the swap takes place.

This is a consistent position: THORChain was itself hacked in the amount of $10.7 million in May 2026, and refused to blacklist the involved addresses as well.

What actually moved

Between 03:55 and 06:23 UTC on 28 September, the attacker executed 27 successful swaps through THORChain: roughly 2,390 ETH ($6.3 million) worth of funds were converted into 75.2 BTC, with all proceeds sent to a single receiving address.

I say "roughly" because every single one of those swaps is available to be inspected in detail right now. Anyone can follow the trail of the $6.3 million thief, inspect every address involved in the heist, and determine the exact amount of cryptocurrency transferred at any point during the attack, down to the second.

This is the kind of visibility that the Wormhole article discussed: being able to trace stolen funds does not automatically grant the ability to recover them, and having a known destination address does not necessarily identify the owner.

The Wormhole article identified three properties of a digital currency theft: traceability, identifiability, and recoverability. All three are independent of each other, and may or may not be present in any particular case.

THORChain introduces a fourth: governability. There is an entity that has the capacity and intent to intervene.

In the case of a centralized exchange, it is the operator. If the protocol is sufficiently centralized, it may freeze targeted accounts at the request of a third party.

In the case of THORChain, it is not available or possible, either due to the technical limitations of the system or the stated preference of its maintainers not to implement it.

Why a protocol would choose this

I think that it is an understandable position to take, given the circumstances.

Permissionless nature of the protocol -- anybody can use it without the permission of the operators -- is the primary reason for its existence. Once the capability to block a particular address is built, it can be used to block any address by any interested party, and there is no objective standard by which to determine who may ask for such an action and who may not.

Therefore, THORChain's stated preference is to sacrifice the ability to block bad actors in favor of permissionless execution, the same way that a private club may sacrifice the ability to admit undesirable customers in favor of being open to anybody who shows up at the door.

Where the actual choke point still is

None of this changes the fact that THORChain is not the final destination for the $6.3 million. The choke point is the same as it was in the Wormhole case: a regulated exchange. Converting Bitcoin into cash involves a KYC procedure, and the UK and international laws are being introduced to close the loopholes that allowed such procedures to be circumvented.

The hacker has converted the stolen funds into Bitcoin, but has not yet cashed out. Therefore, the Bitcoin address containing the $6.3 million is still visible to anybody who cares to look at the public ledger, and its subsequent history will be visible as well.

This is the point at which identifiability becomes a factor in the Wormhole theft: until the Bitcoin is converted into cash, it is still subject to being traced.

What I took from it

Permissionless systems are not a vulnerability that vendors fail to address; they are a design decision, no less valid than any other.

I think it is worth emphasizing that "on-chain and public" is not the same thing as "stoppable". The Wormhole hack's history is in many ways more comprehensible than this one: it is easier to understand how the bad actors were able to do what they did, because they took greater risks and left more visible tracks.

THORChain's history is one of permissionless execution, where the bad actors were able to do what they did because they were using a system that was designed to allow that to happen.

When evaluating the capabilities of a protocol, ask what it cannot do. Bitget's request assumed a capability that THORChain did not have and did not want. This gap is worth understanding before relying on a system to behave in a certain way.

References

1. THORChain, public statement on the halt mechanism and address-freezing refusal -- thorchain.org

2. Bitget, incident disclosure on the 24 September 2026 exchange breach -- bitget.com

3. CoinDesk, "Thorchain Rejects Bitget Request to Block Hacker as $6 Million Moves to Bitcoin", 28 September 2026 -- coindesk.com