Unexpected XCM instruction v3 to v2 conversion

[dmoka]

I am experiencing an unexpected XCM instruction v3 to v2 conversion when sending XCM instruction from Acala to HydraDX.

I use the latest master from the chopsticks repo.

I use the latest blocks for both chains and running the following command:

yarn start xcm --relaychain=configs/polkadot.yml --parachain=configs/hydradx.yml --parachain=configs/acala.yml

But when I send an XCM instruction with sudo from Acala to HydraDX, then the instruction got converted to V2, then back to V3 when arriving on HydraDX side.

This is the conversion logic from V3 to V2 that happens.

I checked with different kinds of instructions like ExchangeAsset and QueryResponse, but the same conversion happens, resulting in losing information when arriving on HydraDX.

I also checked and both chains Acala and HydraDX are on XCM v3, together with Polkadot relay chain, so such conversion should not happen, that's why I thought maybe it is related to chopsticks.

What do you think, what could be the issue here? Thank you!

[ermalkaleci]

But when I send an XCM instruction with sudo from Acala to HydraDX, then the instruction got converted to V2, then back to V3 when arriving on HydraDX side.

Chopsticks doesn't do anything with the message, it just pass to other chain. How can you tell it got converted to v2 and back to v3?

[ermalkaleci]

BTW you don't need relaychain to xcm between 2 parachains 😉

[dmoka]

Thanks for the swift reply! Yes, good point, also tried without relaychain, but the same happens.

Chopsticks doesn't do anything with the message, it just pass to other chain. How can you tell it got converted to v2 and back to v3?

When ExchangeAsset arrives on HydraDX, then the maximal attribute is always set to true, regardless if I set it false on Acala when I send it.

This is the only place where such conversion with losing information happens in the entire polkadot codebase, that's why I assume that v3 to v2 conversion happens.

This is where the maximal is set back to true in v2 to v3 conversion

Or the same happens for QueryResponse. I set its querier attribute to a specific value, but when it arrives on HydraDX, it is set to None. And if we look at the v3 to v2 conversion, we can see that the querier info is lost in the conversion.

[ermalkaleci]

can you post an link to a tx on actual chain?

[dmoka]

can you post an link to a tx on actual chain?

Unfortunately, I don't have a transaction for that on an actual chain, as I am spinning up the chains locally by using chopsticks.

Here is the decoded call, I hope this helps:

0x45038400d43593c715fdd31c61141abd04a99fd6822c8558854ccde39a5684e7a56da27d01902712a2cf447000526c6a668fa197e2a92a890ff3f0956f2c2255f58e628858c2304796a7b387d459c3659752f64ea0cc01b8cf6d7056b2dbdccb07bc616486a4000000ff00330003010100c91f031000040000010500000b00407a10f35a130000010500000b00203d88792d000f00040000010500000b00a0724e18090400010000a10f000d010208010101007369626cd0070000000000000000000000000000000000000000000000000000

[ermalkaleci]

It's very unlikely to be a chopsticks issue. As I said chopsticks doesn't change the message. As you can see the message send and received is the same. We can't debug this unless you have an onchain tx. Seems more like Acala's issue or incorrect message

[xlc]

This is not Chopsticks issue.

For some reason Acala does not know the XCM version of HydraDX chain. It could be HydraDX failed to notify XCM version, or Acala failed to handle the notification. A solution is use xcmPallet.forceXcmVersion on Acala side to set the XCM versioni of HydraDX parachain. It will be great if you can give it a try and let us know if it works. You can use sudo to dispatch it on Acala with Chopsticks.

[dmoka]

This is not Chopsticks issue.

For some reason Acala does not know the XCM version of HydraDX chain. It could be HydraDX failed to notify XCM version, or Acala failed to handle the notification. A solution is use xcmPallet.forceXcmVersion on Acala side to set the XCM versioni of HydraDX parachain. It will be great if you can give it a try and let us know if it works. You can use sudo to dispatch it on Acala with Chopsticks.

xcmPallet.forceXcmVersion did indeed the job, thanks everyone!

What do you recommend, what could be the follow-up actions for this?

Because within HydraDX, we added support for ExchangeAsset XCM instruction, to enable sibling parachains to execute trades (with best onchain routes) on HydraDX via XCM. But as it clearly seems, there is a XCM version notification issue between Acala and HydraDX, so wondering what is the usual/best way to tackle and solve this between us.

[xlc]

We can make a proposal for Acala to perform xcmPallet.forceXcmVersion. The notification issues exists for long time for many other chains and I haven't investigated on the root cause so maybe there is something we need to do to completely address this. However, we don't have new XCM version that often so it should be fine for now.

Closing as this is not a Chopsticks issue.