Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
IkerAlus opened this issue May 2, 2024 · 3 comments · Fixed by #383
Closed

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

IkerAlus opened this issue May 2, 2024 · 3 comments · Fixed by #383
Assignees
@marshacb
Labels
enhancement New feature or request P2 - Medium Medium Priority

Comments

@IkerAlus
Copy link
Contributor

IkerAlus commented May 2, 2024 •
edited

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.
@IkerAlus IkerAlus added enhancement New feature or request P2 - Medium Medium Priority labels May 2, 2024
@IkerAlus IkerAlus changed the title Add support default for the new transfer_assets_using_type_and_then() call in pallet XCM Add support for the new transfer_assets_using_type_and_then() call in pallet XCM May 2, 2024
@marshacb marshacb self-assigned this May 6, 2024
@acatangiu acatangiu mentioned this issue May 9, 2024
Closed
@acatangiu
Copy link

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
Copy link
Contributor Author

@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
Copy link

Sounds great to me! 👍

@marshacb marshacb mentioned this issue May 17, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@marshacb marshacb

Labels
enhancement New feature or request P2 - Medium Medium Priority
Projects
Asset Transfer API
Status: Done
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat: support system to bridge txs paritytech/asset-transfer-api
3 participants
@marshacb @acatangiu @IkerAlus