Xtokens Polkadot 1.5 XCM with Different Reserves

[albertov19]

As part of paritytech/polkadot-sdk@e7651cf - pallet XCM now allows to send reserve and non-reserve assets in a single XCM message.

Nevertheless, Xtokens requires that both the asset and feeAsset should come from the same reserve - https://github.com/open-web3-stack/open-runtime-module-library/blob/master/xtokens/src/lib.rs#L549-L554

It would be great if Xtokens supports the scenario that is supported now by pallet-xcm

[xlc]

Yeah we can add this

[xlc]

Actually, can you elaborate a bit more about this issue? In what case that pallet-xcm is supported but xtokens is not?

https://github.com/paritytech/polkadot-sdk/blob/5c79ed37dc6485d2b3f4fc69b8cf8456b86b4e17/polkadot/xcm/pallet-xcm/src/lib.rs#L1479-L1481 it looks to me also doesn't support sending assets with different reserve in a single call.

[albertov19]

Hey @xlc - The PR I referenced in the initial comment adds the new transfer_asset function that, from what I understand, supports transferring assets from different reserves.

@Agusrodri tried this already on an internal network, and it worked.

This is the function: https://github.com/paritytech/polkadot-sdk/blob/5c79ed37dc6485d2b3f4fc69b8cf8456b86b4e17/polkadot/xcm/pallet-xcm/src/lib.rs#L1287

[xlc]

I can't find the code in asset_transfer that does the magic. Could you provide an example of the usage in your internal network? What kinds of assets are been transferred?

[Agusrodri]

Hey @xlc! Here is a test that checks the following scenario:

• Send two tokens (ParaAToken and ParaBToken) from an account on para A to an account on para B (A -> B).
• Chain A is the reserve for ParaAToken.
• Chain B is the reserve for ParaBToken.

The new extrinsic transfer_assets allows to actually combine fee assets and non-fee assets in several ways. This use case is just one of them.

In this case, the asset used to pay fees is ParaAToken, and the process of actually "sending" this asset is done by depositing the remaining amount in the destination account after paying for fees with it, so you end up having both ParaAToken and ParaBToken in the destination account.

Of course, for this use case to work, both chains have to support each corresponding foreign asset.

[xlc]

Thanks for the example. I have identified a few improvements that we need to do to support such use case:

• Improve fee asset handling for multi-hop transfer. Currently we use MinXcmFee to calculate the dest fee and assume the rest are the fee for the intermediary transfer. We should make it in such way that it to queries the intermediary fee instead and then deposit the rest to dest so we can actually perform transfer of the fee asset.
• Use the new trait config in XcmExecutor to detect asset type if is teleport or reserve transfer
• Identify the case that we only need a single xcm transfer instead of two

[xlc]

A quick update. I started the refactor work to improve xtokens based on the asset_transfer implementation. However, recently there are also few more issues and improvements have been raised about the asset_transfer. So I will wait a bit and see how it goes.

Also the complexity of this is kinda getting out of control and that means something is wrong. Not sure if there is anything we can do though.

[xlc]

With all the additional complicated requirements, I am considering maybe we should just deprecate xtokens and use pallet-xcm instead. xtokens is built because there was no pallet offers such functionality. Now that pallet-xcm should support all the transfer needs, I don't feel the needs to support an alternative implementation.

[albertov19]

I agree. I think Moonbeam is moving away from Xtokens in favor of Pallet XCM.

[IkerAlus]

@albertov19 @xlc is there any update around this?

Note that the incoming 1.2.4 release will implement a new interface from pallet XCM which will allow all the scenarios mentioned above plus many more complex cases.

[albertov19]

@IkerAlus We are slowly transitioning to PalletXCM, but there is no hard deadline and this will be a slow process as there are many teams still using our Xtokens precompile

[xlc]

I think it is best to keep xtokens as it is for compatibility reason and for new use cases, use new features from the pallet-xcm