Notice: Polkadot has migrated to AssetHub. Balances, data, referenda, and other on-chain activity has moved to AssetHub.Learn more
Reimbursement of 102 KSM Lost Due to Incorrect Reserve Selection in XCM Transfer
Summary
I am requesting a treasury spend of 102 KSM on Kusama Asset Hub to reimburse funds lost during an XCM transfer from Basilisk to Asset Hub.
The transfer executed successfully on the origin chain, but the assets never arrived on Asset Hub and are not claimable through any existing “trapped assets” mechanism.
This request is made with full transparency and gratitude to the ecosystem contributors who helped investigate the issue.
Background
On 2025-11-07, I attempted to transfer KSM from Basilisk to Kusama Asset Hub using the Paraspell XCM Playground, a tool intended primarily for developers. The flow was:
- A 0.1 KSM test transfer, which succeeded and appeared on Asset Hub:
https://basilisk.subscan.io/extrinsic/11888805-2 - The main 102 KSM transfer, with the same configuration except for the amount:
https://basilisk.subscan.io/extrinsic/11888816-2
The second transaction was finalized on Basilisk and the funds were deducted, but the tokens never arrived on Asset Hub.
After I reached out, the Paraspell team—especially Dudo—was extremely helpful in investigating the issue and explaining what had occurred. Their support is greatly appreciated.
What Happened
Based on our joint analysis with Dudo:
- The XCM message generated for the larger amount selected Kusama Relay Chain as the reserve chain instead of Kusama Asset Hub.
- After Kusama governance migrated to KAH, the Relay can no longer serve as the reserve for this transfer path.
- The resulting message failed on Kusama. Relevant event:
https://kusama.subscan.io/event/30866491-35 - Unfortunately, the failure mode did not create a recoverable trapped asset entry.
This situation was the result of a combination of two circumstances:
- The Basilisk chain currently does not support dry-run for XCM, so I had no way to simulate the final message before signing.
- A small edge-case issue in the Paraspell SDK’s reserve-selection logic, which only appeared for larger transfer amounts.
The Paraspell team has since updated the SDK so that the correct reserve (Kusama Asset Hub) is always selected for this route.
I want to emphasize that I am not blaming Paraspell or anyone involved — XCM is complex and evolving, and without dry-run support on Basilisk, even developers cannot reliably detect such edge cases.
I am very grateful to Dudo and Paraspell for taking the time to investigate, clarify the root cause, and guide me through the next steps.
Why Governance Action Is Needed
- The transfer was executed on Basilisk (funds deducted).
- The failure on Kusama did not result in a claimable trapped asset.
- Parity/XCM contributors who reviewed the case advised that the only path to recover the funds is via a referendum on Kusama Asset Hub, since Kusama governance has migrated there.
I am submitting this referendum based on their guidance, with respect for the process and community.
Requested Action
I respectfully ask Kusama Asset Hub governance to:
- Approve a treasury spend of 102 KSM,
- Paid to the beneficiary address included in the referendum submission.
This would restore funds lost due to a rare and complex XCM routing issue during an active migration period.
Closing
I am submitting this request with appreciation to everyone who helped analyze the problem—especially Dudo and the Paraspell team for their responsiveness and clarity.
Thank you to the Kusama community for considering this referendum and for maintaining a governance system that allows users to resolve exceptional situations in a fair and transparent manner.
Comments (2)
We’d like to confirm that this issue did, unfortunately, occur on our side. After reviewing the situation, there are a few important points that explain how this happened and why the bug wasn’t detectable in advance:
We were unable to detect the problematic behavior early because the Basilisk dry-run API has a runtime issue. We reported this a few months ago: https://github.com/galacticcouncil/Basilisk-node/issues/680
Without a functioning dry-run, it’s not possible to reliably validate XCM execution beforehand.
It’s designed as a testing environment for developers before implementing XCM logic into production applications. While end users can use it, it requires caution because it does not provide all the safety mechanisms of a full user-facing product (especially when upstream chains have broken features, such as dry-run).
In the absence of a working dry-run from the origin chain, our tools have no way to verify the validity of an XCM message before it is signed. This means that signing an extrinsic is ultimately a user’s explicit consent that they accept the risks—simply because the chain gives us no mechanism to validate it on their behalf.
Regardless of points 1-3, we would also like to confirm that the user had no way of knowing whether the extrinsic is correct or not as well, because the transfer happened not long after the migration, and at that time, there were no example extrinsics that were transferring KSM from Basilisk (At least not indexed on Subscan) - https://basilisk.subscan.io/xcm_transfer?page=1&time_dimension=date&fromChain=2090&toChain=1000&page_size=25&symbol=KSM so they had no extrinsic to compare with the one they were singning.
I would also like to point out that this issue was fixed - https://github.com/paraspell/xcm-tools/pull/1437 the day that it was reported to us, so the pathway is now fully functional again (As the extrinsic now always chooses AHK as a reserve).
Losing funds is not fun, specially due to a technical glitch outside of the user's control. It's also nice that issue resulted in a fix that will prevent future users to encounter the same problem.