-
Notifications
You must be signed in to change notification settings - Fork 710
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.
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
pallet-xcm::transfer_assets_using_type_and_then() supports custom actions on destination #4260
pallet-xcm::transfer_assets_using_type_and_then() supports custom actions on destination #4260
Conversation
…estination Change `transfer_assets_using_type()` to not assume `DepositAssets` as the intended use of the assets on the destination. Instead provides the caller with the ability to specify custom XCM that be executed on `dest` chain as the last step of the transfer, thus allowing custom usecases for the transferred assets. E.g. some are used/swapped/etc there, while some are sent further to yet another chain. Note: this is an API change for `transfer_assets_using_type()`, but it is ok as the previous version has not been yet released. Thus, its first release will include the new API proposed by this PR. Signed-off-by: Adrian Catangiu <[email protected]>
6a07074
to
ee88f2e
Compare
fees_transfer_type: Box<TransferType>, | ||
custom_xcm_on_dest: Box<VersionedXcm<()>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I don't have much context regarding this change. A couple of questions. Not sure if they make sense:
- Should this be a blob ? Just as we did for
send
andexecute
? - Isn't it risky to allow the user to perform arbitrary xcm execution here ?
- Nit: seems unexpected to pass a
custom_xcm_on_dest
here. Partially because of the name.transfer_assets_using_type
makes me think automatically of the asset being deposited at the destination chain. And also because the other transfer-related extrinsics seem to deposit the assets from what I understand. Maybe renaming the method to something liketransfer_assets_using_type_and_then
would make this more clear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- With
UncheckedExtrinsic
decoding improvements #4255 we don't need the blob hack anymore. - No, a
ClearOrigin
is run before these user-controlled instructions. Only thing they can do is operate on the holding register (which they loaded in the first place). - Yes, I like the name suggestion will rename to
transfer_assets_using_type_and_then
@bkontur @serban300 I made the suggested changes, edited the prdoc from the original PR, and added emulated tests. PTAL |
e0584a1
Continuation of #3695
Change
transfer_assets_using_type_and_then()
to not assumeDepositAssets
as the intended use of the assets on the destination.Instead provides the caller with the ability to specify custom XCM that be executed on
dest
chain as the last step of the transfer, thus allowing custom usecases for the transferred assets. E.g. some are used/swapped/etc there, while some are sent further to yet another chain.Note: this is a follow-up on #3695, bringing in an API change (and rename) for
transfer_assets_using_type()
. This is ok as the previous version has not been yet released. Thus, its first release will include the new API proposed by this PR.This allows usecases such as: https://forum.polkadot.network/t/managing-sas-on-multiple-reserve-chains-for-same-asset/7538/4
BTW: all this pallet-xcm asset transfers code will be massively reduced once we have polkadot-fellows/xcm-format#54