Swaps for XCM delivery fees #5131
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Jul 24, 2024
franciscoaguirre
changed the base branch from
master
to
single-asset-exchange-adapter
franciscoaguirre
force-pushed
the
swaps-for-delivery-fees
branch
2 times, most recently
from
70caf38
to
5939ba2
Compare
...ains/integration-tests/emulated/tests/assets/asset-hub-westend/src/tests/reserve_transfer.rs
Outdated
Show resolved
Hide resolved
...ains/integration-tests/emulated/tests/assets/asset-hub-westend/src/tests/reserve_transfer.rs
Show resolved
Hide resolved
...ains/integration-tests/emulated/tests/assets/asset-hub-westend/src/tests/reserve_transfer.rs
Show resolved
Hide resolved
...ains/integration-tests/emulated/tests/assets/asset-hub-westend/src/tests/reserve_transfer.rs
Outdated
Show resolved
Hide resolved
|
Same tests for rococo? |
acatangiu
approved these changes
Jul 29, 2024
...hains/integration-tests/emulated/tests/assets/asset-hub-rococo/src/tests/reserve_transfer.rs
Outdated
Show resolved
Hide resolved
cumulus/parachains/runtimes/assets/asset-hub-rococo/src/xcm_config.rs
Outdated
Show resolved
Hide resolved
cumulus/parachains/runtimes/assets/asset-hub-westend/src/xcm_config.rs
Outdated
Show resolved
Hide resolved
github-merge-queue bot
pushed a commit
that referenced
this pull request
Aug 2, 2024
Added a new adapter to xcm-builder, the `SingleAssetExchangeAdapter`. This adapter makes it easy to use `pallet-asset-conversion` for configuring the `AssetExchanger` XCM config item. I also took the liberty of adding a new function to the `AssetExchange` trait, with the following signature: ```rust fn quote_exchange_price(give: &Assets, want: &Assets, maximal: bool) -> Option<Assets>; ``` The signature is meant to be fairly symmetric to that of `exchange_asset`. The way they interact can be seen in the doc comment for it in the `AssetExchange` trait. This is a breaking change but is needed for #5131. Another idea is to create a new trait for this but that would require setting it in the XCM config which is also breaking. Old PR: #4375. --------- Co-authored-by: Adrian Catangiu <[email protected]>
|
The CI pipeline was cancelled due to failure one of the required jobs. |
muharem
reviewed
Aug 8, 2024
muharem
reviewed
Aug 9, 2024
muharem
approved these changes
Aug 9, 2024
x3c41a
added a commit
that referenced
this pull request
Sep 4, 2024
# Context Fees can already be paid in other assets locally thanks to the Trader implementations we have. This doesn't work when sending messages because delivery fees go through a different mechanism altogether. The idea is to fix this leveraging the `AssetExchanger` config item that's able to turn the asset the user wants to pay fees in into the asset the router expects for delivery fees. # Main addition An adapter was needed to use `pallet-asset-conversion` for exchanging assets in XCM. This was created in #5130. The XCM executor was modified to use `AssetExchanger` (when available) to swap assets to pay for delivery fees. ## Limitations We can only pay for delivery fees in different assets in intermediate hops. We can't pay in different assets locally. The first hop will always need the native token of the chain (or whatever is specified in the `XcmRouter`). This is a byproduct of using the `BuyExecution` instruction to know which asset should be used for delivery fee payment. Since this instruction is not present when executing an XCM locally, we are left with this limitation. To illustrate this limitation, I'll show two scenarios. All chains involved have pools. ### Scenario 1 Parachain A --> Parachain B Here, parachain A can use any asset in a pool with its native asset to pay for local execution fees. However, as of now we can't use those for local delivery fees. This means transfers from A to B need some amount of A's native token to pay for delivery fees. ### Scenario 2 Parachain A --> Parachain C --> Parachain B Here, Parachain C's remote delivery fees can be paid with any asset in a pool with its native asset. This allows a reserve asset transfer between A and B with C as the reserve to only need A's native token at the starting hop. After that, it could all be pool assets. ## Future work The fact that delivery fees go through a totally different mechanism results in a lot of bugs and pain points. Unfortunately, this is not so easy to solve in a backwards compatible manner. Delivery fees will be integrated into the language in future XCM versions, following polkadot-fellows/xcm-format#53. Old PR: #4375.
5 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context
Fees can already be paid in other assets locally thanks to the Trader implementations we have.
This doesn't work when sending messages because delivery fees go through a different mechanism altogether.
The idea is to fix this leveraging the
AssetExchangerconfig item that's able to turn the asset the user wants to pay fees in into the asset the router expects for delivery fees.Main addition
An adapter was needed to use
pallet-asset-conversionfor exchanging assets in XCM.This was created in #5130.
The XCM executor was modified to use
AssetExchanger(when available) to swap assets to pay for delivery fees.Limitations
We can only pay for delivery fees in different assets in intermediate hops. We can't pay in different assets locally. The first hop will always need the native token of the chain (or whatever is specified in the
XcmRouter).This is a byproduct of using the
BuyExecutioninstruction to know which asset should be used for delivery fee payment.Since this instruction is not present when executing an XCM locally, we are left with this limitation.
To illustrate this limitation, I'll show two scenarios. All chains involved have pools.
Scenario 1
Parachain A --> Parachain B
Here, parachain A can use any asset in a pool with its native asset to pay for local execution fees.
However, as of now we can't use those for local delivery fees.
This means transfers from A to B need some amount of A's native token to pay for delivery fees.
Scenario 2
Parachain A --> Parachain C --> Parachain B
Here, Parachain C's remote delivery fees can be paid with any asset in a pool with its native asset.
This allows a reserve asset transfer between A and B with C as the reserve to only need A's native token at the starting hop.
After that, it could all be pool assets.
Future work
The fact that delivery fees go through a totally different mechanism results in a lot of bugs and pain points.
Unfortunately, this is not so easy to solve in a backwards compatible manner.
Delivery fees will be integrated into the language in future XCM versions, following polkadot-fellows/xcm-format#53.
Old PR: #4375.