RFC: add complex asset transfers instructions

[acatangiu]

Summary

This RFC 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.

Example usage

    // XCM to be executed locally
    let xcm = Xcm::<penpal_runtime::RuntimeCall>(vec![
        // Withdraw both ROCs and PENs from origin account
        WithdrawAsset(assets.clone().into()),
        // ROCs are reserve-withdrawn on AHR
        DestinationReserveWithdrawAssets(rocs.into()),
        // PENs are teleported to AHR
        TeleportTransferAssets(pens.into()),
        // Execute the transfers while paying remote fees with ROCs
        ExecuteAssetTransfers {
            dest: local_asset_hub,
            remote_fees: Some(AssetFilter::Wild(AllOf { id: rocs_id.into(), fun })),
            remote_xcm: xcm_on_ahr,
        },
    ]);

Proof-of-Concept

I also have a proof-of-concept implementation and a proof-of-concept asset transfer test, transferring 2 different types of assets across 3 chains.

[acatangiu]

cc @mrshiposha @xlc

[franciscoaguirre]

Great suggestion! My only comment is about naming and the number of instructions. I want to make sure these instructions are simple to reason about. Right now, because of the names, it's hard to figure out what they do if I don't look at the documentation.

There was the option of having only one huge instruction.
When you only care about a specific transfer type, like when doing a simple teleport, you would have to add a bunch of Nones.
I prefer the two-step approach you described, first configure the asset transfer and then execute it, because you don't want to add a bunch of Nones all the time.

That said, I'd have only one previous instruction PrepareAssetTransfer that receives a vector of a TransferType enum. This instruction sets asides assets for teleports, local reserve and destination reserve.

enum Instruction {
  ...
  PrepareAssetTransfer(Vec<AssetTransferType>),
  ...
}

enum AssetTransferType {
  Teleport(AssetFilter),
  LocalReserve(AssetFilter),
  DestinationReserve(AssetFilter),
}

I think this strikes a good balance between having just one instruction or a lot of them. It makes XCM programs easier to reason about.
What do you think?

PS: We could also probably do this in the one big instruction, further coupling concepts that work together. It would always require specifying a vector of AssetTransferType, even if it has only one element. That makes it good UX even when just doing a simple teleport.

enum Instruction {
  ...
  InitiateAssetTransfer {
    destination: Location,
    assets: Vec<AssetTransferType>,
    remote_fees: Option<AssetFilter>,
    remote_xcm: Xcm<()>,
  },
  ...
}

[franciscoaguirre]

I think it makes sense to add UnpaidExecution here. It would be very useful as right now system parachains have to teleport with unpaid execution and there are currently no instructions that handle this use-case correctly.

[acatangiu]

I can imagine unpaid asset transfers, but haven't seen any in practice. Do you know of any practical usecases so we can make sure we properly support them?

[acatangiu]

PS: We could also probably do this in the one big instruction, further coupling concepts that work together. It would always require specifying a vector of AssetTransferType, even if it has only one element. That makes it good UX even when just doing a simple teleport.

enum Instruction {
  ...
  InitiateAssetTransfer {
    destination: Location,
    assets: Vec<AssetTransferType>,
    remote_fees: Option<AssetFilter>,
    remote_xcm: Xcm<()>,
  },
  ...
}

Yes, I like this ^

[eskimor]

For someone not having done a lot of XCM, one can only imagine why this is a very poor UX. What problems does a developer actually face with the current design?

[acatangiu]

The developer simply can not write an XCM program that can, for example, transfer both DOT (local reserve deposit) and HDX (destination reserve withdraw) from AssetHub to HydraDX. It is simply not possible with the current instruction set.

The only XCM instructions available currently (XCMv4) for transferring assets are DepositReserveAsset, InitiateReserveWithdraw and InitiateTeleport instructions. They initiate asset transfers on execution, but they are opinionated in the type of transfer to use. Combining them is not possible, because as a result of their individual execution, a message containing a ClearOrigin instruction is sent to the destination chain (for security reasons - more details available in their docs), making subsequent transfers impossible.

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/xcm-user-and-developer-experience-improvements/4511/21

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/managing-sas-on-multiple-reserve-chains-for-same-asset/7538/7

[acatangiu]

Unfortunately, following the repo migration to the new org, I lost write access to the PR (upstream) branch. I've opened the PR from a fork branch here #63

Closing this one.