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:

1. A 0.1 KSM test transfer, which succeeded and appeared on Asset Hub:
   https://basilisk.subscan.io/extrinsic/11888805-2
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:

1. The Basilisk chain currently does not support dry-run for XCM, so I had no way to simulate the final message before signing.
2. 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.