Failed XTokens KSM transfers after 1.5.0 rollout

[green-jay]

Is there an existing issue?

• I have searched the existing issues

Experiencing problems? Have you tried our Stack Exchange first?

• This is not a support question.

Description of bug

After deployment of Kusama runtime 1.5.0, all xTokens messages that are used on Basilisk to transfer KSM got rejected as Corrupt on relay chain.

Examples:
https://basilisk.subscan.io/xcm_message/kusama-ebb41a01d6fc0a058b14c881b79104ac4ea72130
https://basilisk.subscan.io/xcm_transfer?page=1&time_dimension=date&result=pending

Calldata example (note version was changed to v4): 0x9a000100000000e0a835d629000000000000000000000401010100d43593c715fdd31c61141abd04a99fd6822c8558854ccde39a5684e7a56da27d00

Trace log on relay chain:

  runtime::election-provider  TRACE: [59] [#28320019] 🗳  current phase Off, next election 28323022, metadata: None
        xcm::process-message  TRACE: [59] `VersionedXcm` failed to decode: Error
                runtime::mmr  TRACE: [59] elems: [0x4e9ccb60e971871112535f57dc2433029c7e70e3899289a9798f6a402c9891c4]
                runtime::mmr  TRACE: [59] peaks_before: [8388606, 12582909, 14680060, 15204347, 15466490, 15597561, 15663096, 15695863, 15704054, 15708149, 15708404, 15708411]
                runtime::mmr  TRACE: [59] peaks_after: [8388606, 12582909, 14680060, 15204347, 15466490, 15597561, 15663096, 15695863, 15704054, 15708149, 15708404, 15708411, 15708412]
      runtime::mmr::offchain  DEBUG: [59] offchain db set: pos 15708412 parent_hash 0xb74344810546da294612c5366b2537cfcb747fdf260577ccd893df92438c6f85 key [12, 109, 109, 114, 252, 176, 239, 0, 0, 0, 0, 0, 183, 67, 68, 129, 5, 70, 218, 41, 70, 18, 197, 54, 107, 37, 55, 207, 203, 116, 127, 223, 38, 5, 119, 204, 216, 147, 223, 146, 67, 140, 111, 133]```

### Steps to reproduce

_No response_

[bkontur]

I think the reason could be that the XCMs contain the V2 version, which was removed in stable2412 (because we added V5 and we keep -2 versions), on which version 1.5.0 is based.

So the actual solution is to change those XCMs to version V3, V4, or V5.

At the button of these screens from your links, you can see V2.

[bkontur]

There is an XCM version subscribe/discovery mechanism that should ensure the sending chain does not send a higher version (e.g., V5) to a destination chain that doesn't support it yet.

However, it seems we need to extend this mechanism to also account for the minimum supported version of the destination parachain.

@green-jay can you please point me to the actual Basilisk runtime code, I would like to see XCM configuration.

[bkontur]

@green-jay

Basilisk supports V4, but you safe xcm version is 2 and for the relay you have 3:

So it should be enough to change safeXcmVersion to 3 or 4.

[green-jay]

Thanks @bkontur, yes I got to the same conclusion meanwhile. Tested with safe xcm version set to v4 and it works. Could you please create a tracking issue for minimal supported version and close this one? I'm on the same page this shouldn't be required maintenance action from parachain governance.

[bkontur]

@green-jay actually, I have for this older issue here: #3214, but I created separate one: #8499

[bkontur]

@green-jay but the problem is also elsewhere, in the Basilisk's polkadotXcm pallet for supported version data, there are date stored for two version for 3 and for 4,
the relaychain is stored with 3 under 3,
but Basilisk uses XCM_VERSION=3, so the pallet_xcm's WrapVersion implementation does not find correct record, and therefore it uses SafeXcmVersion=2, relevant code: https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/pallet-xcm/src/lib.rs#L3536-L3540

That's why I wanted to check Basilisk's configuration, can you still point me?

See the Basilisk's data:

[green-jay]

https://github.com/galacticcouncil/Basilisk-node/blob/master/runtime/basilisk/src/xcm.rs

[bkontur]

Thanks, I see now. I strongly recommend to add:

	// permanent
	pallet_xcm::migration::MigrateToLatestXcmVersion<Runtime>,

here: https://github.com/galacticcouncil/Basilisk-node/blob/master/runtime/basilisk/src/lib.rs#L280

E.g. all fellows runtimes have this: https://github.com/polkadot-fellows/runtimes/blob/main/system-parachains/asset-hubs/asset-hub-kusama/src/lib.rs#L1103-L1104.

And it will automatially fix the Basilisk's mentioned data.

[bkontur]

I also added this point to that new issue:

- [ ] add a way how to trigger migration on-chain, e.g. make `CurrentMigration` `pub` or add some extrinsic `force_migrate`