Add support for the new transfer_assets_using_type_and_then() call in pallet XCM

[IkerAlus]

Following from the original issue: #384

The new transfer_assets_using_type_and_then() call in pallet XCM will add heavy changes to the original interface. Among other things, this call allows to transfer more than one asset in a proper manner (see discussion here). Asset Transfer API should support this call but leaving up to the user the flexibility and extra complexity that transfer_assets does not allow. This is, this call should meant to be only for advanced API users. More concretely:

• Whenever only one asset is meant to be transferred, this call should be disregarded and transfer_assets (or other calls) should be constructed.

• If there are more than one asset to be transferred, then the behaviour should be:

  • The remote_fees_id input param should be already supported by the paysWithFeeDest? input in the API, but now paysWithFeeDest? input should not be optional.
  • Give the user the option to choose one among the four transfer types to populate the assets_transfer_type input parameter.
  • Similar behaviour to populate the fees_transfer_type input paramter as per assets_transfer_type:

• In any case, the value of custom_xcm_on_dest input should default to Xcm(vec![DepositAsset { assets: Wild(AllCounted(assets.len())), beneficiary }]) as explained here. But the user should have the option to input their own custom instructions for destination.

[acatangiu]

In any case, the value of custom_xcm_on_dest input should default to Xcm(vec![DepositAsset { assets: Wild(AllCounted(assets.len())), beneficiary }]) as explained here. But the user should have the option to input their own custom instructions for destination.

I am hoping that this library be more than just a wrapper and instead can build on top of the pallet_xcm::transfer_assets_using_type_and_then functionality and be "smarter" and more helpful to the user.

The limitation of pallet-xcm/xtokens or any on-chain functionality is that it only has a limited view of the whole picture, its knowledge is limited to the local chain. Whereas this library (especially with the use of its registry paritytech/asset-transfer-api-registry#134) has information about the whole ecosystem.
Therefore, it could build any type of transfer for the user, without having the user write (or understand) any XCM.

I would really like to start from some "complex" user stories (bridged assets, multiple hops, multiple assets, mixing teleports with reserves, etc) that are either not possible or hard to do in practice in our ecosystem, and come up with some helper APIs here to do them, hiding all that complexity from the user.

For this ^ we really need to work backwards from the usecase, I expect we will find we still need some missing pieces from the chain to make it really great UX.

Lemme know what you think.

[IkerAlus]

@acatangiu Thanks for the comment, I totally agree, the main purpose of this API is to facilitate every kind of cross-chain transfers.

After thinking a bit about your comment my initial idea would be to:

• First add "default" support for this new call, make sure advance users are enabled right away. This will be what I described in the original issue.
• Secondly, define a set of complex user stories in the ecosystem and enable them via this API. This should be possible by setting the right inputs to this new call, with particular focus on the custom_xcm_on_dest input, where the API should have predefined XCM programs without requiring the user to deal with this lower level XCM logic. To kickstart this, it would be nice to have an agreement on the more important user stories.

[acatangiu]

Sounds great to me! 👍