-
Notifications
You must be signed in to change notification settings - Fork 732
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] fix transport fees for remote reserve transfers #3792
[pallet-xcm] fix transport fees for remote reserve transfers #3792
Conversation
Good catch! Seems this was missed in emulated tests because Penpal still has free message delivery 🤦 Let me add an emulated transfer regression test as well 👍 |
In the meantime, can you please add a prdoc for documenting the fix in the changelog? |
Add `SetFeesMode { jit_withdraw: true }` before `InitiateReserveWithdraw` instruction to allow paying JIT fees in the executor. This is backport of #3792
Absolutely! |
I added regression tests PR (to merge with this PR): girazoki#1 @girazoki PTAL and let's merge those to this PR so this PR is complete with fix and regression tests. |
…sfers Regression tests for paritytech#3792
Merged @acatangiu |
The CI pipeline was cancelled due to failure one of the required jobs. |
@acatangiu I dont know how to fix the prdoc failure now :(, do I need to put the title in between quotes? |
9a04ebb
…ech#3792) Currently `transfer_assets` from pallet-xcm covers 4 main different transfer types: - `localReserve` - `DestinationReserve` - `Teleport` - `RemoteReserve` For the first three, the local execution and the remote message sending are separated, and fees are deducted in pallet-xcm itself: https://github.com/paritytech/polkadot-sdk/blob/3410dfb3929462da88be2da813f121d8b1cf46b3/polkadot/xcm/pallet-xcm/src/lib.rs#L1758. For the 4th case `RemoteReserve`, pallet-xcm is still relying on the xcm-executor itself to send the message (through the `initiateReserveWithdraw` instruction). In this case, if delivery fees need to be charged, it is not possible to do so because the `jit_withdraw` mode has not being set. This PR proposes to still use the `initiateReserveWithdraw` but prepending a `setFeesMode { jit_withdraw: true }` to make sure delivery fees can be paid. A test-case is also added to present the aforementioned case --------- Co-authored-by: Adrian Catangiu <[email protected]>
Add `SetFeesMode { jit_withdraw: true }` before `InitiateReserveWithdraw` instruction to allow paying JIT fees in the executor. This is backport of #3792
Add `SetFeesMode { jit_withdraw: true }` before `InitiateReserveWithdraw` instruction to allow paying JIT fees in the executor. This is backport of #3792
… backport for 1.8 (#3839) This is backport of #3792 Expected patches for: - pallet-xcm --------- Co-authored-by: Adrian Catangiu <[email protected]>
… backport for 1.9 (#3840) This is backport of #3792 Expected patches for: - pallet-xcm Co-authored-by: Adrian Catangiu <[email protected]>
Currently
transfer_assets
from pallet-xcm covers 4 main different transfer types:localReserve
DestinationReserve
Teleport
RemoteReserve
For the first three, the local execution and the remote message sending are separated, and fees are deducted in pallet-xcm itself:
polkadot-sdk/polkadot/xcm/pallet-xcm/src/lib.rs
Line 1758 in 3410dfb
For the 4th case
RemoteReserve
, pallet-xcm is still relying on the xcm-executor itself to send the message (through theinitiateReserveWithdraw
instruction). In this case, if delivery fees need to be charged, it is not possible to do so because thejit_withdraw
mode has not being set.This PR proposes to still use the
initiateReserveWithdraw
but prepending asetFeesMode { jit_withdraw: true }
to make sure delivery fees can be paid.A test-case is also added to present the aforementioned case