XCM user and developer experience improvements

Tech Talk
21

I would like to provide an update on recent XCM UX improvement initiatives, looking for feedback from the community.

While each of the following sections/topics could have been its own Polkadot Forum thread, I decided to include them all here and suggest further discussions on the individual points happen on their linked Github pages. This will help keep all the feedback and information centralized.

NOTE: the items tagged XCMv5 can only be made available with a new (v5) XCM version, so will be delivered in the second half of this year. Everything else has either already landed or is under way, coming soon.

Addressing painpoint: XCM Fees

Estimating XCM fees

It is currently very difficult to figure out what are the total fees to be paid for XCM related operations. Total fees incurred by the complete execution of a cross-chain XCM program can be seen as the sum of:

  • local extrinsic tx fee (this is the classic tx fee and it is known or easy to find),
  • local XCM execution cost,
  • XCM delivery costs (for sending remote XCMs to other chains),
  • remote XCMs costs (remote execution + remote delivery) [repeated for each subsequent remote XCM].

In order to allow estimation of the total fees, we created XcmDryRun runtime APIs to expose the individual fees components on each chain along the XCM program path. An offchain entity (user, wallet, dApp component, etc) can simulate an extrinsic or XCM execution on the starting chain and repeat simulating the resulting remote XCMs on the subsequent chains to get an e2e overview of the total fees required as well as various other effects.

Furthermore, using the same API, emitted events across the cross-chain execution can be inspected for other purposes than just simulating fees.

You can see here multiple emulated asset transfer scenarios where the fees are “calculated off-chain” before executing the actual “on-chain transfer”.

Using multiple currencies for XCM fees

Chains that use pallet-asset-conversion (e.g. Asset Hub) could JIT swap any asset for DOT for the purpose of paying fees.

On Asset Hub, the fees required for local XCM execution have been integrated with above model, so that XCM execution can be
“bought” using any asset/currency that has a local DOT-pool set up. E.g. see this thread.

The (yet) missing piece is also hooking up XCM transport fees to the same mechanism. But this is also actively being worked on,
tracked by this issue, with a PR in progress.

This will allow e.g. fully paying fees using USDT.

Consolidating XCM execution and transport fees

While XCM execution fees are part of the XCM protocol and can be “bought” using BuyExecution instruction, XCM transport
fees only exist outside the XCM protocol and XCM programs have no control over them. This makes it very hard to create
complex or semi-complex reliable cross-chain XCM programs. In practice, many parachains have various hacks and workarounds
to be able to charge or handle these fees.

There is a new mechanism for specifying and paying for fees (execution and transport) in development, to be delivered with XCMv5.

I strongly urge anyone having had any sort of negative experience with the old model, to review the proposal and make sure their painpoints are addressed: RFC: Better fee handling #53 (XCMv5).

XCM cross-chain asset transfers

Hiding XCM complexity for non-trivial scenarios

While existing pallet_xcm::limited_teleport_assets(), pallet_xcm::limited_reserve_transfer_assets() could handle trivial asset transfers, they fell short when trying to combine multiple assets (with different reserves or teleport properties) in the same transfer. xtokens::transfer_multiassets() fares much better, but it also does not cover all scenarios.

pallet_xcm::transfer_assets() was added which allows mixing multiple asset types in same transfer with fewer artificial constraints imposed to the user.

You can see here an emulated e2e asset transfer between two parachains that teleports some asset while reserve-transferring another.

There is also now a higher layer JS asset-transfer-api library that offers wrappers over pallet-xcm and xtokens extrinsics which hides away even more XCM complexity.

I am hoping to see even more scenarios enabled in upper-layer libraries such as GitHub - paraspell/xcm-tools: ParaSpell✨: Set of XCM-Tools for Polkadot and Kusama ecosystem
(cc @dudo50).

Enabling complex scenarios

transfer_assets_using_type_and_then()

pallet_xcm::transfer_assets_using_type_and_then() was added for supporting complex multi-assets, multi-hops transfers.

For example moving KSM from “SomeKusamaParachain → Asset Hub Kusama → Asset Hub Polkadot → SomePolkadotParachain” in a single transfer (over the P<>K bridge). Or sending bridged ETH+DOT+USDT from “SomePolkadotParachain → Asset Hub Polkadot → OtherPolkadotParachain” while using a different asset for paying fees on each hop.

Example e2e scenarios are here (bridge transfers) and here (many hybrid transfers).

New XCM instructions

There’s an RFC up for new transfer instructions: RFC: add complex asset transfers instructions #54 (XCMv5).

It proposes new instructions that provide a way to initiate asset transfers which transfer multiple types (teleports, local-reserve, destination-reserve) of assets, on remote chains using XCM alone.

The currently existing instructions are too opinionated and force each XCM asset transfer to a single transfer type (teleport, local-reserve, destination-reserve). This results in inability to combine different types of transfers in single transfer which results in overall poor UX when trying to move assets across chains.

NOTE: these complex scenarios are now at least possible, but UX is poor for them, it requires heavy XCM knowledge to do them. Further work here to hide complexity is planned.

Better handling of transfer failures

Dedicated claim_assets extrinsic

pallet-xcm::claim_assets() was added to allow easier claim of trapped assets.

Fix UX for assets trapped on remote chains

New SetAssetClaimer instruction (XCMv5) to be added with XCMv5 which will allow XCM programs to set a custom Location as the authorized claimer of any assets trapped during XCM execution.

Idea under exploration and research

Overhaul of asset trapping mechanisms, use RemoteAccounts/SovereignAccounts when possible to deposit assets instead of trapping them.

General usability enhancements

Documentation and guides

Created an XCM Cookbook to explain XCM, as well as provide practical usage guides.

8 Likes