Multihop XCM transfer from Parachain > Relay chain #6637
Comments
dudo50
changed the title
|
Unfortunately it is not possible yet to do that in a single XCM program while using XCM v3 or v4. It will be possible with XCMv5. You would need to do a I had added support for charging transport fees from transferred assets for these types of cases here: #4834 but was met with resistance and ultimately closed in favor of XCMv5 which can do this easily and safely. So your options are to:
|
|
Thanks for the thorough answer, @acatangiu. I appreciate the time you invested in the answer. It is indeed unfortunate that this isn't possible yet. I think waiting for v5 is the safest option, but I am also leaning towards the second option because the first one - forcing chains to update into v5 seems a bit brutal. Some chains might not have time to allocate to upgrade to the latest version as they could focus on other higher priority tasks (So they will eventually update to the latest, but once their Task pipeline allows). I think that the safest option is giving them the ability to use the feature in earlier versions also. That's just my opinion though. Thanks anyway! |
github-merge-queue bot
pushed a commit
that referenced
this issue
Dec 9, 2024
…#4834) # Description Sending XCM messages to other chains requires paying a "transport fee". This can be paid either: - from `origin` local account if `jit_withdraw = true`, - taken from Holding register otherwise. This currently works for following hops/scenarios: 1. On destination no transport fee needed (only sending costs, not receiving), 2. Local/originating chain: just set JIT=true and fee will be paid from signed account, 3. Intermediary hops - only if intermediary is acting as reserve between two untrusted chains (aka only for `DepositReserveAsset` instruction) - this was fixed in #3142 But now we're seeing more complex asset transfers that are mixing reserve transfers with teleports depending on the involved chains. # Example E.g. transferring DOT between Relay and parachain, but through AH (using AH instead of the Relay chain as parachain's DOT reserve). In the `Parachain --1--> AssetHub --2--> Relay` scenario, DOT has to be reserve-withdrawn in leg `1`, then teleported in leg `2`. On the intermediary hop (AssetHub), `InitiateTeleport` fails to send onward message because of missing transport fees. We also can't rely on `jit_withdraw` because the original origin is lost on the way, and even if it weren't we can't rely on the user having funded accounts on each hop along the way. # Solution/Changes - Charge the transport fee in the executor from the transferred assets (if available), - Only charge from transferred assets if JIT_WITHDRAW was not set, - Only charge from transferred assets if unless using XCMv5 `PayFees` where we do not have this problem. # Testing Added regression tests in emulated transfers. Fixes #4832 Fixes #6637 --------- Signed-off-by: Adrian Catangiu <[email protected]> Co-authored-by: Francisco Aguirre <[email protected]>
github-actions bot
pushed a commit
that referenced
this issue
Dec 9, 2024
…#4834) # Description Sending XCM messages to other chains requires paying a "transport fee". This can be paid either: - from `origin` local account if `jit_withdraw = true`, - taken from Holding register otherwise. This currently works for following hops/scenarios: 1. On destination no transport fee needed (only sending costs, not receiving), 2. Local/originating chain: just set JIT=true and fee will be paid from signed account, 3. Intermediary hops - only if intermediary is acting as reserve between two untrusted chains (aka only for `DepositReserveAsset` instruction) - this was fixed in #3142 But now we're seeing more complex asset transfers that are mixing reserve transfers with teleports depending on the involved chains. # Example E.g. transferring DOT between Relay and parachain, but through AH (using AH instead of the Relay chain as parachain's DOT reserve). In the `Parachain --1--> AssetHub --2--> Relay` scenario, DOT has to be reserve-withdrawn in leg `1`, then teleported in leg `2`. On the intermediary hop (AssetHub), `InitiateTeleport` fails to send onward message because of missing transport fees. We also can't rely on `jit_withdraw` because the original origin is lost on the way, and even if it weren't we can't rely on the user having funded accounts on each hop along the way. # Solution/Changes - Charge the transport fee in the executor from the transferred assets (if available), - Only charge from transferred assets if JIT_WITHDRAW was not set, - Only charge from transferred assets if unless using XCMv5 `PayFees` where we do not have this problem. # Testing Added regression tests in emulated transfers. Fixes #4832 Fixes #6637 --------- Signed-off-by: Adrian Catangiu <[email protected]> Co-authored-by: Francisco Aguirre <[email protected]> (cherry picked from commit e79fd2b)
Ank4n
pushed a commit
that referenced
this issue
Dec 15, 2024
…#4834) # Description Sending XCM messages to other chains requires paying a "transport fee". This can be paid either: - from `origin` local account if `jit_withdraw = true`, - taken from Holding register otherwise. This currently works for following hops/scenarios: 1. On destination no transport fee needed (only sending costs, not receiving), 2. Local/originating chain: just set JIT=true and fee will be paid from signed account, 3. Intermediary hops - only if intermediary is acting as reserve between two untrusted chains (aka only for `DepositReserveAsset` instruction) - this was fixed in #3142 But now we're seeing more complex asset transfers that are mixing reserve transfers with teleports depending on the involved chains. # Example E.g. transferring DOT between Relay and parachain, but through AH (using AH instead of the Relay chain as parachain's DOT reserve). In the `Parachain --1--> AssetHub --2--> Relay` scenario, DOT has to be reserve-withdrawn in leg `1`, then teleported in leg `2`. On the intermediary hop (AssetHub), `InitiateTeleport` fails to send onward message because of missing transport fees. We also can't rely on `jit_withdraw` because the original origin is lost on the way, and even if it weren't we can't rely on the user having funded accounts on each hop along the way. # Solution/Changes - Charge the transport fee in the executor from the transferred assets (if available), - Only charge from transferred assets if JIT_WITHDRAW was not set, - Only charge from transferred assets if unless using XCMv5 `PayFees` where we do not have this problem. # Testing Added regression tests in emulated transfers. Fixes #4832 Fixes #6637 --------- Signed-off-by: Adrian Catangiu <[email protected]> Co-authored-by: Francisco Aguirre <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Dear Parity team,
We are currently exploring
MultiHop XCMtransfers and we are running into issue which we believe is simple to resolve, but we need some explanation to help us further understand what needs to be changed.The following scenario is for transferring
DOTfromPolkadot > Polkadot AssetHub > Polimechttps://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fpolkadot-rpc-tn.dwellir.com#/extrinsics/decode/0x630d03000100a10f030400000000130000e8890423c78a00030000000003040e010204010100413408130001000002286bee000d0102040001010084fc49ce30071ea611731838cc7736113c1ec68fbc47119be8a0805066df9b2b00
What this extrinsic does is
Teleport from Relay to AHP and then Reserve transfer from AHP to PolimecHow does the extrinsic must change in order for this transfer to work backwards also?
Polimec > Polkadot AssetHub > Polkadot? What we expect extrinsic to do isReserve transfer from Polimec to AHP and then Teleport from AHP to PolkadotThanks for your help in advance!
The text was updated successfully, but these errors were encountered: