Polkadot’s Treasury lost approximately $1.38 million in DOT value after a security fix failed to reach affected production runtimes, according to Parity’s November 2 incident review. The October 24–26 exploit distorted pricing in the DOT/dotUSD liquidity pool on Polkadot Asset Hub.
The Treasury was the pool’s only liquidity provider. Parity says no users lost funds, while the incident exposed a gap between correcting vulnerable code and deploying that correction where it was needed.
Key Takeaways
- A flaw in the XCM executor distorted dotUSD supply accounting and pool pricing.
- The treasury absorbed the loss; individual account balances were not reduced.
- Separate upgrades addressed the vulnerability and corrected the remaining accounting discrepancy.
How the Accounting Error Affected Prices
Parity’s incident review says failed XCM instructions reduced recorded dotUSD issuance while account balances remained unchanged. That broke the expected relationship between total issuance and the sum of balances.
The mismatch distorted the DOT/dotUSD pool’s pricing and created artificial exchange rates. The report says dotUSD remained backed, but the understated supply restricted redemption capacity pending correction. It has not established that the person exploiting the bug also profited from the subsequent arbitrage.
For context on the network’s design, UEEx’s Polkadot explainer covers its cross-chain architecture. The incident concerned a specific execution and accounting failure, rather than evidence that all Polkadot wallets were compromised.
The Fix That Missed Production
As CryptoSlate reported from the review, Parity had received the bug report and merged a code fix in June. The fix missed a release cut-off and was absent from the runtimes affected in October.
The initial medium-severity assessment had not accounted for interactions with dotUSD, which had not launched at that point. Parity later reclassified the issue as critical. The sequence illustrates why teams need to revisit earlier security assessments when new financial functionality depends on existing code.
A merged patch and a deployed patch are different milestones. Reviewing a repository can show that developers addressed a bug, but confirming protection requires checking the version actually operating on-chain. A useful release check follows each security correction into the versions that need it, records which deployments remain exposed and verifies completion after the upgrade. That process becomes more important when several release branches and governance steps sit between a developer’s change and production.
Why the Relayer Halt Only Delayed the Attack
Snowfork initially halted its own consensus relayers, interrupting the attack. Parity says the attacker later ran an independent relayer and resumed before the corrective runtime took effect.
Snowbridge’s documentation describes relayers as permissionless off-chain software that carries messages between blockchains. Anyone can operate one, subject to the protocol’s on-chain requirements. Stopping one operator’s software therefore does not necessarily stop every possible message route.
The review places the underlying bug in the XCM executor and says it could be reproduced without Snowbridge. That distinction matters when describing responsibility: the route used to deliver a message is separate from the component that processes it incorrectly. Our cross-chain interoperability guide explains the broader role of these connections.
What the Corrective Upgrade Changed
The executed supply-correction referendum describes recorded dotUSD supply as approximately 4.06 million below the amount that existed. Its correction recalculated supply from existing balances without changing anyone’s balance.
The proposal also restored Snowbridge settings affected by the previous runtime upgrade. Correcting supply accounting and repairing bridge operation were distinct tasks, even though they were handled together in the subsequent upgrade.
For readers following remediation, the important evidence is the completed on-chain change and the behaviour it restores. UEEx’s crypto hacks archive provides context on how disclosures, containment measures and final repairs can represent different stages of an incident.
Conclusion
The Polkadot incident shows why security work must extend from bug discovery through production verification. The treasury loss was real, while user balances remained unchanged. Future assessments should track the deployed fix, corrected accounting and release controls separately, rather than treating a code update alone as completed protection.
