Thirty-Six Hours of Patience. Then Four Minutes.

Nothing was forged

The exchange's own statement, published at 02:23 UTC on 30 October, puts the estimated total impact at around 6.3 billion dollars and says that roughly 3 billion of it had been frozen on-chain at the time of writing. The on-chain analysis published separately that morning put the amount taken at about 6.36 billion dollars, valued at what each asset was worth when it moved. Either way it is the largest theft in the history of the asset class, roughly four times the size of the exchange theft of February 2025 that held the record until now.

What makes it worth reading as a security practitioner is not the size. It is that the usual explanations do not apply. There was no ransomware, no encryption, no zero-day in a wallet contract and, on the exchange's account, no leaked private key. The transactions that drained the wallets were signed by the wallets that owned the funds. They were valid. Every node that verified them was right to verify them.

The company has been careful about how it characterises the cause, and the carefulness is worth preserving rather than flattening. Its statement says the initial investigation suggests the incident may involve a compromised DevOps engineer's laptop, which allowed an attacker to gain access to a service container and submit unauthorised withdrawal transactions. Those are hedged words, deliberately. The company has said it will publish a technical post-mortem once the investigation is complete, and it has not published a root cause yet.

The company's own account, and what it leaves open

Two sentences from the exchange do most of the work. The first is the one above: a suspected compromised engineer laptop, access to a service container, unauthorised withdrawal transactions. The second came from its co-chief executive, Richard Teng, who addressed the obvious follow-up question directly.

"To be clear: the attacker did not simply use one engineer's permissions, and this was not a single 'one-click' action," he said. "It involved a more complex attack process." He added that the investigation had not attributed responsibility to any individual.

That is an unusually useful clarification, because it closes off the comfortable reading. The comfortable reading is that one over-privileged engineer existed, and that the lesson is to review entitlements. The company is saying that is not what happened. Something stood between a compromised workstation and the authority to move funds on ten chains, and whatever that something was, it was traversed. Until the post-mortem lands, how it was traversed is the open question in this incident, and nobody outside the company can answer it.

Thirty-six hours of patience

The published on-chain analysis dates the start of the operation to the morning of 28 October, when the wallet that would go on to drive the attack received three small withdrawals from a mixing service. That is at least 36 hours before anything of value moved.

Early on 29 October the operator deployed a first version of the attack code and tested it against two wallets. Later the same day it rehearsed the final version on a third wallet and routed the test funds back to itself. Four hours after that rehearsal, the same code was installed on an exchange hot wallet.

Read that sequence as a defender and the thing to notice is how much of it is observable. A rehearsal happened. Code was deployed, tested, revised and tested again against live wallets, with the proceeds returned so that nothing would show up as a loss. For a day and a half there was activity in the environment that was not a theft and was not normal either, and it was the cheapest possible moment to find.

A documented feature, used exactly as documented

The Ethereum leg of the attack used EIP-7702, an account abstraction mechanism introduced in the Pectra upgrade in May 2025. It lets an ordinary wallet hand control of its own behaviour to a smart contract by signing an authorisation, and the arrangement stays in place until the wallet signs a new one.

The attacker had the exchange's hot wallet sign an authorisation pointing at a sweeper contract that accepts instructions only from the operator. From that moment the wallet was no longer a plain account that moves funds when its owner says so. It was an account that does what the sweeper tells it, and the sweeper took instructions from one address.

There is no vulnerability in that paragraph. The feature is public, specified and behaving correctly. What it changes is the meaning of a single signature. A conventional transfer signature spends once and expires. A delegation signature does not spend anything at all, which is exactly why it is easy to treat as harmless, and it persists. The analysis notes that funds arriving in the wallet after the first sweep were swept again, repeatedly, through the evening, because the delegation was still in force.

Fifty signatures for a moving target

One detail in this attack is worth understanding properly, because it is the part that leaves a usable fingerprint.

Every wallet keeps a running count of the transactions it has sent, called a nonce, and an authorisation is valid only at the count the wallet has reached at the moment it executes. An exchange hot wallet is the worst possible target for this constraint, because it is processing customer withdrawals continuously and its count never stops moving. Sign one authorisation and by the time it reaches the chain the wallet has moved past it.

The attacker solved this by not guessing. A single transaction carried 50 authorisations, each signed by the hot wallet, each valid at a different consecutive count, prepared in advance as one batch. One of them matched when the transaction executed, which was all that was needed.

That batch is the most defensible thing in the whole incident. No legitimate operation asks a treasury wallet to authorise the same delegation across fifty consecutive positions. It is a request whose shape has no benign explanation, and it was made by a system that could have been asked to refuse it.

Four minutes

The execution bears no relation to the preparation in pace. Between 20:05 and 20:09 UTC, five XRP Ledger wallets sent 233.46 million XRP to a single attacker address, each one left holding nothing but its minimum balance. Shortly after 20:10, wallets on Solana and Optimism followed.

At 20:20 the Bitcoin hot wallet sent 18,270 BTC to an attacker address and, inside the same block, began breaking it into round 1,000 and 100 piece amounts, a splitting pattern used to make later tracing expensive. At 20:20 the transaction carrying the fifty authorisations was submitted. Within two minutes of the Bitcoin transfer a Tron hot wallet sent 612.7 million USDT and 46.4 million TRX.

Three minutes and 24 seconds after the delegation landed, the operator instructed the hot wallet to send its entire balance. That single transaction moved 167,464 ETH and 63 tokens, including 1.615 billion USDT. Further sweeps of the same wallet followed at 20:41, 20:59, 21:04, 21:44, 22:39 and 23:56, and a second wave reached wallets on two more chains at 23:05.

The whole of the main event fits inside the interval that a well-run security operation spends deciding whether an alert is worth opening.

Ten chains, one window, and an explanation that does not fit

The early theory, when the first transactions appeared, was that the authorisations had been obtained by phishing. The analysis points out the problem with that: phishing a signature covers the Ethereum leg and leaves everything else unexplained.

Only the Ethereum wallet used the delegation. The XRP Ledger wallets, the Bitcoin hot wallet, the Tron hot wallet and the Solana, Arbitrum, Avalanche, Optimism, Base and Polygon wallets all moved their funds by ordinary signed transfers. A second Ethereum hot wallet sent 28,006 ETH, 55.7 million USDT and 25.9 million RLUSD the same way, with no delegation involved at all.

These are different chains with different key types and different signing schemes, and all of them produced valid signatures for the attacker inside about half an hour. The assessment in the published analysis is that this points to a compromise of the exchange's hot wallet signing infrastructure, and that the most likely explanation is that the attacker gained the ability to make that signing system sign transactions of its choosing across chains. The batch of fifty suggests the access may have been time limited, or that signatures had to be requested through a system rather than taken freely.

This is the part that generalises furthest beyond cryptocurrency, and it is worth stating plainly. The blast radius was not a wallet or a chain. It was everything one signing service would sign.

The response ran at a different speed

What happened next was fast by the standards of incident response and slow by the standards of the attack. The first freeze landed at 21:01, when the issuer of the largest dollar stablecoin froze 971.1 million of its tokens, 37 minutes after the main sweep. A second issuer froze 823 million of its own, in coordination with law enforcement, at 21:04.

Between 21:42 and 22:01 one attacker wallet sold 48 million of a third stablecoin on decentralised exchanges before its issuer froze the 40.5 million that remained at 22:01. A fourth issuer froze 27.8 million at 22:10 and more at 22:26. At 23:35 the verified total frozen reached 2.54 billion dollars. At 00:08 on 30 October the security council of one chain used its powers to force two transfers out of the attacker's wallet there, moving 8,426 ETH and 74.6 million ARB back out of reach.

By the 00:30 cut-off of the published analysis, about 2.7 billion dollars had been frozen and the attacker still controlled about 2.4 billion, including more than 420,000 ETH and 18,270 BTC, in assets that no issuer can freeze. The exchange's own statement a couple of hours later put the frozen figure near 3 billion. Both numbers are moving, and neither is final.

The asymmetry is the lesson, not the arithmetic. The theft took minutes and reached everything. The recovery took hours, required four separate companies and a governance body to act, and reached a little under half.

The laundering had already started

One detail says more about the operation's priorities than any statement will. Before the freezes landed, about 325 million dollars of stablecoin was sold through intent based contracts to professional market makers for roughly 122,300 ETH. The implied price was near 2,650 dollars per ETH at a time when ETH was trading around 2,300 to 2,350: a discount of more than ten per cent, paid voluntarily.

A second wallet supplied 60 million to a lending protocol and borrowed about 19,760 ETH against it, and the protocol froze the affected markets. On Tron, 300 million moved to a wallet supplying a lending platform and a further 200 million went through intermediate wallets and was swapped.

Paying a ten per cent premium to convert a freezable asset into an unfreezable one is a rational trade when you expect the freeze within the hour, and it tells you the attacker had modelled the defensive response in advance. They were not surprised by the freezes. They had priced them.

Attribution, and how firmly to hold it

The analysis attributes the theft, with high confidence, to a state sponsored group operating on behalf of North Korea, the same group the FBI named as responsible for the 1.5 billion dollar exchange theft in February 2025. The stated basis is on-chain and off-chain intelligence, and the specific similarities to that earlier theft and to another in April 2026: small mixing service withdrawals funding an operator wallet, staging that began well before the theft, and signatures obtained in advance and then executed in a single burst.

The laundering since has differed from the earlier pattern, which leant heavily on cross-chain bridges, in favour of large swaps through market makers and lending protocols.

High confidence is a strong judgement and it is not a confirmation. The exchange has said it is working with law enforcement to confirm the identity of those responsible and has not itself attributed the attack. For defenders the attribution matters less than the tradecraft, which is specific, repeated and now documented three times: obtain signing authority quietly, rehearse, pre-position the authorisations, and spend them all at once.

What a detection would have had to notice

It is easy to write a list of controls after the fact and harder to be honest about which of them would have fired. So it is worth being precise about what was actually observable, and what reading it would have required.

Nothing on that list is a signature match, and none of those facts is damning on its own. Engineers reach internal services. Treasury wallets receive authorisation requests. Small transfers happen constantly. Each of the five is a line in a log that a reasonable analyst would close.

What is not reasonable to close is the conjunction: a workstation reaching a signing service, a delegation appearing on a wallet that should never carry code, an authorisation covering a range of positions no workflow needs, and valid signatures emerging from independent systems on nine other chains inside the same half hour. That statement is detectable. The five statements underneath it are not, which is the same structural problem that cloud control plane intrusions have, and it has the same answer.

• Contract code attached to a treasury wallet that is meant to be a plain account.
• An authorisation request spanning many consecutive transaction counts, which no legitimate workflow needs.
• An engineering endpoint with a path to the service container that signs withdrawals.
• Independent signing systems, on different chains and different key types, all producing valid signatures inside one window.
• Small test movements that return to their origin, a day before anything of value moves.

This is not a cryptocurrency story

Strip out the chains and the tokens and the shape of this intrusion is ordinary. An attacker obtained the ability to make a trusted system issue valid credentials, collected more of them than any single operation needed, held them, and spent them all in one burst at a moment of their choosing.

An enterprise has several systems that fit that description. A certificate authority issues trust. A code signing service converts an artefact into something every machine in the estate will execute. An identity provider mints tokens that outlive the session that requested them. A privileged access system hands out credentials that work for a window. In each case the thing worth stealing is not the data behind the system, it is the authority the system confers, and in each case an attacker who holds that authority produces activity that is, by construction, correctly authorised.

That is why detection in this category cannot rest on whether an action was permitted. Every action here was permitted. It rests on who asked, how many times, in what order, across how many systems that have no reason to move together, and how far that pattern sits from how that identity has behaved before.

The second constraint is the clock. Three minutes and 24 seconds separated the delegation from the sweep. Thirty-seven minutes separated the sweep from the first freeze. A manual investigation across the relevant evidence, five to twelve consoles and 60 to 90 minutes of analyst time, does not fit in that gap. The same collection and correlation run by agents completes in 60 to 120 seconds, and runs on every qualified alert rather than on the ones a shift reached. That is not a claim about this incident, which nobody outside the exchange can make. It is a statement about the size of the window that this incident measured for everyone.

The honest version

A good deal about this is still unknown, and the unknown part is the part that matters most. The exchange has not published a root cause. How a compromised laptop became signing authority across ten chains is unexplained, and the co-chief executive has said explicitly that it was not a matter of one engineer's permissions. The totals are moving, the two published estimates of the amount taken differ by hundreds of millions, and the attribution is a high confidence judgement by an outside party rather than a confirmed fact.

What can be said is that the exchange has committed to covering the losses from its insurance fund and its own money, said that customer funds are safe, suspended deposits and withdrawals while it completes checks, revoked the affected authorisation, and said it expects withdrawals to resume within 48 hours once it has completed a security revamp of the withdrawal service and its related addresses. It has also promised an updated proof of reserves once remediation is finished. Those are commitments made on day one, and they should be read as commitments rather than outcomes.

The defensive recommendations in the published analysis are specific and apply to anyone holding assets on a chain: watch treasury wallets for code appearing at addresses that should have none, alert immediately on any delegation, keep a tested and pre-approved way of signing a revocation, configure signing policies to reject delegation authorisations unless they are expected, treat a request covering many consecutive positions as an indicator of compromise, and separate signing infrastructure and approval paths by chain and by wallet tier.

The one that travels furthest is the last one. A single signing path that will sign anything, for anyone who can reach it, converts one compromised endpoint into the entire treasury. That was true of this incident, it is true of every code signing service in every enterprise, and it was true long before anyone put money on a blockchain.