Open acatangiu opened 3 weeks ago
This issue has been mentioned on Polkadot Forum. There might be relevant details there:
https://forum.polkadot.network/t/rfc-xcm-asset-transfer-program-builder/8528/1
This issue has been mentioned on Polkadot Forum. There might be relevant details there:
https://forum.polkadot.network/t/rfc-xcm-asset-transfer-program-builder/8528/2
I really like the API for this!
We already have the XCM builder pattern as well but each method maps 1:1 to instructions.
It would make a lot of sense to supercharge this with some utilities as you describe here.
The define_asset
is a good example of something very easy to add. That along with the context allows for nice behind-the-scenes reanchoring.
A utility for better separating hops is also a good idea to add, since now building multiple hops requires you to start the process from scratch.
This issue has been mentioned on Polkadot Forum. There might be relevant details there:
https://forum.polkadot.network/t/rfc-xcm-asset-transfer-program-builder/8528/3
Following the enablement of arbitrary XCM execution on Kusama and Polkadot system chains, users/wallets/dapps can interact uniformly across multiple chains directly using XCM programs, without having to figure out chain-specific pallets or calls/extrinsics.
Improving Asset Transfer UX/DX
Cross-chain asset transfers are currently hard to generalize across the ecosystem. Each Parachain uses its own assets transfer pallet (usually
xtokens
orpallet-xcm
) that exposes asset transfer extrinsics unique to that chain, and wallets/dapps need to integrate with all of them. These extrinsics then build opinionated XCM programs to do the asset transfers.With the ability to execute arbitrary XCM programs, we can make use of this powerful layer of abstraction, and slowly transition to switching that around:
Wallets/dApps define their desired asset transfers in an XCM program and execute that using the "universal"
pallet-xcm::execute()
extrinsic. This has two major advantages:xtokens
andpallet-xcm
transfer extrinsics are limited to basic use-cases, and trying to expose more flexible ones results in ugly calls like pallet-xcm::transfer_assets_using_type_and_then().The disadvantage of running "raw" XCM programs is that they're hard to build, it's a low-level language with gotchas and corner-cases, and easy to get wrong. Calling an extrinsic to build and execute an XCM program for you is definitely simpler and more reliable.
But what if we could fix (or mitigate) that?
XCM Asset Transfer Tooling
For automated, safe, reliable building of a complex asset transfer XCM we will require multiple layers of "helper" tools/libraries each operating at a different level. A quick exercise of imagination produces the following top-down view:
AssetX
fromAccountA
onChainA
toAccountB
onChainB
".some asset-transfer-library (ecosystem-stateful): has ecosystem-level knowledge/state, able to identify what cross-chain interactions are required to "move
AssetX
fromChainA
toChainB
", depending on the actual assets and chains involved it can define things like:AssetX
,ChainA
toChainB
(is it direct, through a reserve chain, over a bridge, etc?), and the "hops" involvedlibraries like asset-transfer-api and its assets-registry (cc @IkerAlus)
This ^, alongside tooling that exposes the DryRun runtime APIs, should allow dApps to confidently switch to using flexible, portable, interoperable XCM programs instead of opinionated, chain-specific asset transfer extrinsics.
XCM Asset Transfer Builder
This RFC proposes the following (Rust) builder pattern tool for addressing layer (3) above. Same or similar can be created in JS or other relevant languages.
Builder properties:
Location
s context-relative views (no need to worry about reanchoring all the time),Example 1 - HDX, USDT, GLMR from Hydration Network to Moonbeam (through AH)
Example 2 - KSM from Karura to Acala (over bridge, going through both Asset Hubs)
cc @xlc @franciscoaguirre