Polkadot's $1.38 million XCM loss: what DOT and dotUSD holders should check
The short answer Polkadot's XCM incident review estimates a loss of approximately $1.381 million in DOT value from the Asset Hub DOT/dotUSD pool during October 24–26, 2026. The review says the Treasury was the pool's only liquidity provider and no users lost funds. It also describes a restriction on dotUSD redemption capacity before the recorded supply was corrected, so an unchanged wallet balance was not enough to describe the incident's effect on holders.
The original review was posted on November 3 SGT, with further news coverage on November 5. This is an analysis of that disclosed incident, not a report of a new attack today. A holder's useful checks concern the actual asset, network, pool and current transfer route, rather than a general assumption that every DOT service was affected. Source: Polkadot incident review.
Show less
What the loss figure measures The review puts the estimated loss at approximately $1.381 million in DOT value. Its scope is the DOT/dotUSD pool on Polkadot Asset Hub, where the Treasury was the only liquidity provider at the time. That scope belongs beside the number whenever the story is shortened for a headline or an account note.
PANews reported the same estimate in its November 5 coverage and said the Treasury was the pool's sole liquidity provider. Its report also describes the later runtime remediation. Source: PANews.
Odaily separately carried the approximate $1.381 million figure and the October 24–26 incident window. Both news reports point back to the forum review. They corroborate what the review says; they do not establish a second independent on-chain calculation of the loss. Source: Odaily.
The primary text also leaves an attribution question open: available on-chain evidence has not established that the party exploiting the XCM flaw also profited from the subsequent arbitrage. For that reason, describing the entire estimated pool loss as one identified attacker's realised proceeds would go beyond the evidence opened here.
Why balances could stay unchanged while the pool price broke The failure involved the difference between individual account balances and the system's recorded issuance of dotUSD. The review says a crafted program could fail, reverse the account debit, and still leave behind the corresponding reduction in recorded total supply. Repeating that sequence reduced recorded issuance without removing dotUSD from account balances.
Normally, the recorded supply is expected to equal the sum of account balances. The attack broke that relationship. A reader checking only a wallet's token quantity could therefore miss the accounting discrepancy that affected the exchange pool. That explains why the review can report unchanged individual balances alongside an estimated loss from the Treasury's liquidity position.
The pool used the smaller of its actual asset balance and the recorded supply when determining how much dotUSD to treat as available. Once recorded issuance fell below the pool's balance, that rule distorted the price. Trades could then exchange dotUSD for DOT at an artificial rate. This is the mechanism described in the review, rather than evidence that DOT balances across all venues were rewritten.
For a holder, the practical question is which route a quoted price or redemption offer uses. A token balance, a swap quote and a redemption interface answer different questions. Before acting on a historical price discrepancy, identify the pool and route involved and examine the current quote for the amount you actually intend to exchange.
Backing and redemption capacity answered different questions The review says dotUSD remained fully backed throughout the incident. It also says the Peg Stability Module continued to support minting and redemption at a fixed one-to-one ratio with USDT. In the same account, understated recorded issuance restricted redemption capacity pending correction.
Those statements need to remain together. Full backing describes the asset's backing in the review; it does not erase the reported capacity restriction. A reader trying to redeem should look at the actual route and its currently displayed conditions, rather than infer unlimited operational capacity from the backing statement alone.
The source does not give a current liquidity quote for a reader's transaction. It does not establish that every exchange offered dotUSD deposits or that every route is open today. This article therefore uses the one-to-one ratio only to explain the incident's stated mechanism and does not present it as a live execution quote.
A code fix existed before it reached the affected runtime The vulnerability was reported through Parity's bug-bounty programme in June 2026. The review says a fix was made in the codebase but missed the stable-2606 release cut-off and was absent from the affected production runtimes. It was subsequently included in stable-2609. The initial severity assessment was medium; after the incident it was changed to critical.
This is useful context for a holder reading the phrase 'already fixed'. A source-code change and an upgrade enacted on the network are separate milestones. When evaluating the response, use the deployed-runtime timeline in the review. A development reference alone cannot show that a transaction you made after that reference ran under the corrected version.
The review says Parity learned of a public forum comment referencing the fix on October 20. Parity believes the comment may have given attackers enough context to find the vulnerability through other vectors. That is Parity's assessment of a possible clue, not proof that the comment caused the attack or that a specific person exploited it.
How the response unfolded Ecosystem partners reported suspicious activity on October 24. According to the review, investigators reproduced the problem within hours. Snowfork halted its own consensus relayers, delaying further messages from the attacker and temporarily stopping the attack.
Runtime 2.5.1, containing the XCM fix, was proposed on October 24. On October 26, the attacker resumed activity using its own consensus relayer, roughly six hours before the runtime upgrade was applied on-chain. After the upgrade, a transaction rescued the remaining pool liquidity, leaving the DOT/dotUSD pool with minimal liquidity.
Runtime 2.5.2 was approved and enacted on October 30. It corrected recorded dotUSD supply using existing account balances without changing individual balances. The review also says recovered dotUSD was returned to the Treasury. It does not present that return as a statement that the estimated DOT-value loss was fully recovered.
Messages in the attack arrived from Ethereum through Snowbridge. The review locates the underlying flaw in the XCM executor and says the behaviour was reproduced without the bridge. A reader should therefore avoid turning the message route into a claim that Snowbridge itself contained the accounting vulnerability.
What to check before moving DOT or dotUSD Start with the record of the asset you hold. Is the intended action an exchange deposit, a withdrawal, a DOT/dotUSD swap or a dotUSD redemption? Identify the network and the destination shown for that specific action. The incident review cannot confirm an individual exchange account's current deposit permissions.
If you hold DOT on OKX, inspect that account's DOT deposit or withdrawal screen for the network and current status before initiating a transfer. Preserve any pending transfer reference and compare it with the action shown by the venue. These are checks to perform; they are not a claim that the route is open or closed at this moment.
For a pool swap, inspect the pool named in the review and obtain a fresh quote for your intended size. The review's statement that remaining liquidity was rescued is a reason to avoid reusing an old quote or a screenshot from before the response. For a redemption, separately examine the capacity and terms shown by that route.
Our funding-rate board and liquidation page cover different market observations. This article has not opened a current DOT market snapshot from those boards and uses neither to assert that the incident caused a price move, funding change or liquidation wave. The documented loss belongs to the pool and time window described above.
What Parity says it will change Parity's review says the fix merged in June had not reached the affected production runtimes, and that the potential impact changed once new functionality was introduced. It commits to reassessing security findings as features interact, more comprehensive testing of XCM failure scenarios, and verifying that fixes have reached deployed runtimes.
On monitoring, the review says Parity is expanding detection of unusual changes in asset issuance, with clearer incident-response procedures. For a holder, the follow-up worth watching is dated evidence that these steps were deployed. The review gives no completion date for them, so they are stated plans, not finished audits.
What remains unestablished The opened sources do not identify a verified net profit for the XCM exploiter. They do not provide a transaction-by-transaction loss reconstruction in this article, a current pool-depth measurement or a universal exchange status for DOT and dotUSD. Those gaps limit which account actions can be inferred from the review.
The age of the original post also matters. November 5 news coverage brought the incident back into the news, but the underlying exploit occurred in October and the original review predates that coverage. Nothing in the opened material establishes a fresh November 5 exploit. A new incident claim would require a new dated source describing new activity.