- Around $1.38m left the Polkadot treasury after a flaw in cross-chain messaging distorted pricing in a DOT/dotUSD pool.
- A patch for the flaw had been written before the loss but, according to the reporting, never reached the software actually running.
- A later upgrade repaired the ’s supply accounting and left holder balances untouched. The money is still gone.
A bug in Polkadot‘s cross-chain messaging cost its treasury about $1.38m. The part worth pausing on is that a fix for the flaw had already been written. It simply wasn’t running on the network when the money went out.
That treasury isn’t a company’s cash pile. It is funded by DOT holders collectively, through newly issued coins and network fees, and spent on whatever governance votes to spend it on. A loss there is spread thinly across everyone holding the coin rather than landing on one firm’s balance sheet.
And the accounting being tidied up afterwards is not the same as the money coming back. Those are two different events, and only one of them has happened.
What XCM is for
Polkadot is not one chain. It’s a set of separate chains, each doing its own job, all connected through a shared central one. The point of that design is specialisation: a chain built for trading doesn’t have to also be a chain built for identity or governance.
For that to be useful, the chains have to talk. XCM, short for cross-consensus messaging, is the format they use to do it. Move this from here to there. Run this instruction on that chain. It is plumbing, and like plumbing it is mostly invisible until something leaks.
When the messaging layer miscounts, two chains can end up disagreeing about how much of something exists. That disagreement is where the money goes.
Where the loss happened
According to The Defiant, the flaw distorted pricing in a DOT/dotUSD liquidity pool. A liquidity pool is a pot holding two tokens that traders swap against, with the price set by the ratio between the two sides. Put a wrong number on one side and the pool quotes a wrong price. Anyone who spots it can buy cheaply from it until the balance corrects, and the pool’s backers absorb the difference.
Here, the treasury was among those backers, and roughly $1.38m of its funds went with it.
We could not find primary documentation for that figure or for the sequence of events: the account here rests on The Defiant’s write-up, and no statement from anyone involved was quoted in it. Treat the number as the one reported rather than one that has been independently confirmed.
Repaired accounting, unrecovered money
A later runtime upgrade is reported to have corrected the stablecoin’s supply accounting without altering any holder’s balance. That matters, and it is a genuinely better outcome than the alternative. If a token’s recorded supply drifts away from what actually backs it, every balance denominated in it is standing on a number that nobody trusts.
What the repair does is make the ledger internally consistent again. What it does not do is pull back the DOT that already left. Nothing in the reporting suggests the treasury has been made whole, and nobody has said it will be.
The gap was deployment, not discovery
The uncomfortable detail is the patch. Somebody had identified the problem and written the code to close it. The loss happened anyway, because that code was not running where it needed to run.
We’ve now seen several versions of this across the industry this autumn: the vulnerability is known, the fix exists in a repository, and the failure sits in the distance between a merged commit and live software. It is a less dramatic kind of failure than an attacker finding something nobody had thought of. It is also, for a holder, the more irritating kind, because the hard part had already been done.
Polkadot’s runtime upgrades are normally enacted through governance, where DOT holders vote on what the network runs. That makes the question of who was responsible for getting this particular patch deployed, and why it stalled, a question with an actual constituency attached to it. The reporting doesn’t answer it.
What to watch
Whether a treasury reimbursement proposal appears on chain, and who is expected to fund it. That is the clearest signal of how the people closest to this read their own responsibility for it.
Whether a technical post-mortem is published that addresses the deployment gap specifically rather than the bug. Explaining the flaw is the easy half. Explaining why a written fix sat unused is the half that would change anything.
And whether anything in the process for shipping security patches changes as a result. A one-off loss of $1.38m is survivable for a treasury this size. A standing habit of fixes not reaching production is the part that would cost more over time. You can follow the coin on our Polkadot page, and the rest of our infrastructure coverage in Technology.