Skip to content
Snippets Groups Projects
Select Git revision
  • 8076
  • 8057
  • gh-readonly-queue/master/pr-8062-10d15dd1219b6124a265b8f9069916023e58b7ed protected
  • gh-readonly-queue/master/pr-8062-b128314a8929982c5a1a96dc654e5c52b2ccaa60 protected
  • gh-readonly-queue/master/pr-8000-10d15dd1219b6124a265b8f9069916023e58b7ed protected
  • 7567
  • 7952
  • 8063
  • gh-readonly-queue/master/pr-7952-10d15dd1219b6124a265b8f9069916023e58b7ed protected
  • 8071
  • 8068
  • 8062
  • 8075
  • 6137
  • master default protected
  • 7995
  • 8058
  • 8074
  • gh-readonly-queue/master/pr-8059-7b74d9ecd5da768c762ecf4d6a362ae137e005af protected
  • gh-readonly-queue/master/pr-8059-c31ab2a246af0318a989ce6486f0bf8d7d385243 protected
20 results
Compare History
Francisco Aguirre's avatar
Swaps for XCM delivery fees (#5131)
Francisco Aguirre authored 
# 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
https://github.com/paritytech/polkadot-sdk/pull/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
https://github.com/polkadot-fellows/xcm-format/pull/53.

Old PR: https://github.com/paritytech/polkadot-sdk/pull/4375.
5291412e
Name Last commit Last update
.cargo
.config
.forklift
.github
.gitlab
bridges
cumulus
docker
docs
polkadot
prdoc
scripts
substrate
templates
umbrella
.gitignore
.gitlab-ci.yml
.prdoc.toml
.rustfmt.toml
CODE_OF_CONDUCT.md
CONTRIBUTING.md
Cargo.lock
Cargo.toml
README.md
README.md

SDK Logo SDK Logo

Polkadot SDK

GitHub stars  GitHub forks

StackExchange  GitHub contributors  GitHub commit activity  GitHub last commit

The Polkadot SDK repository provides all the components needed to start building on the Polkadot network, a multi-chain blockchain platform that enables different blockchains to interoperate and share information in a secure and scalable way.

⚡ Quickstart

If you want to get an example node running quickly you can execute the following getting started script:

curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/paritytech/polkadot-sdk/master/scripts/getting-started.sh | bash

📚 Documentation

🚀 Releases

[!NOTE] Our release process is still Work-In-Progress and may not yet reflect the aspired outline here.

The Polkadot-SDK has two release channels: stable and nightly. Production software is advised to only use stable. nightly is meant for tinkerers to try out the latest features. The detailed release process is described in RELEASE.md.

You can use psvm to manage your Polkadot-SDK dependency versions in downstream projects.

😌 Stable

stable releases have a support duration of three months. In this period, the release will not have any breaking changes. It will receive bug fixes, security fixes, performance fixes and new non-breaking features on a two week cadence.

🤠 Nightly

nightly releases are released every night from the master branch, potentially with breaking changes. They have pre-release version numbers in the format major.0.0-nightlyYYMMDD.

🛠️ Tooling

Polkadot SDK Version Manager: A simple tool to manage and update the Polkadot SDK dependencies in any Cargo.toml file. It will automatically update the Polkadot SDK dependencies to their correct crates.io version.

🔐 Security

The security policy and procedures can be found in docs/contributor/SECURITY.md.

🤍 Contributing & Code of Conduct

Ensure you follow our contribution guidelines. In every interaction and contribution, this project adheres to the Contributor Covenant Code of Conduct.

👾 Ready to Contribute?

Take a look at the issues labeled with mentor (or alternatively this page, created by one of the maintainers) label to get started! We always recognize valuable contributions by proposing an on-chain tip to the Polkadot network as a token of our appreciation.

Polkadot Fellowship

Development in this repo usually goes hand in hand with the fellowship organization. In short, this repository provides all the SDK pieces needed to build both Polkadot and its parachains. But, the actual Polkadot runtime lives in the fellowship/runtimes repository. Read more about the fellowship, this separation, the RFC process here.

History

This repository is the amalgamation of 3 separate repositories that used to make up Polkadot SDK, namely Substrate, Polkadot and Cumulus. Read more about the merge and its history here.