(source)

Table of Contents

• RFC-0122: Asset transfers can alias XCM origin on destination to original origin
  • Summary
  • Motivation
  • Stakeholders
  • Explanation
    • Trust assumptions
    • XCM InitiateAssetsTransfer instruction changes
    • Example scenarios
  • Drawbacks
  • Testing, Security, and Privacy
  • Performance, Ergonomics, and Compatibility
    • Performance
    • Ergonomics
    • Compatibility
  • Prior Art and References
  • Unresolved Questions
  • Future Directions and Related Material

RFC-0122: Asset transfers can alias XCM origin on destination to original origin

Summary

XCM programs generated by the InitiateAssetTransfer instruction shall have the option to carry over the original origin all the way to the final destination. They shall do so by internally making use of AliasOrigin or ClearOrigin depending on given parameters.

This allows asset transfers to retain their original origin even across multiple hops.

Ecosystem chains would have to change their trusted aliasing rules to effectively make use of this feature.

Motivation

Currently, all XCM asset transfer instructions ultimately clear the origin in the remote XCM message by use of the ClearOrigin instruction. This is done for security considerations to ensure that subsequent (user-controlled) instructions cannot command the authority of the sending chain.

The problem with this approach is that it limits what can be achieved on remote chains through XCM. Most XCM operations require having an origin, and following any asset transfer the origin is lost, meaning not much can be done other than depositing the transferred assets to some local account or transferring them onward to another chain.

For example, we cannot transfer some funds for buying execution, then do a Transact (all in the same XCM message).

The above example is a basic, core building block for cross-chain interactions and we should support it.

Transact XCM programs today require a two step process:

And we want to be able to do it using a single XCM program.

Stakeholders

Runtime Users, Runtime Devs, wallets, cross-chain dApps.

Explanation

In the case of XCM programs going from source-chain directly to dest-chain without an intermediary hop, we can enable scenarios such as above by using the AliasOrigin instruction instead of the ClearOrigin instruction.

Instead of clearing the source-chain origin, the destination chain shall attempt to alias source-chain to "original origin" on the source chain. Most common such origin aliasing would be X1(Parachain(source-chain)) -> X2(Parachain(source-chain), AccountId32(origin-account)) for the case of a single hop transfer where the initiator is a (signed/pure/proxy) account origin-account on source-chain. This is equivalent to using the DescendOrigin instruction in this case, but also usable in the multi hop case.

This allows an actor on chain A to Transact on chain B without having to prefund its SA account on chain B, instead they can simply transfer the required fees in the same XCM program as the Transact.

As long as the asset transfer has the same XCM route/hops as the rest of the program, this pattern of usage can be composed across multiple hops, to ultimately Transact on the final hop using the original origin on the source chain, effectively abstracting away any intermediary hops.

Trust assumptions

The model described above works between chains that configure certain aliasing rules. Origin aliasing is highly customizable at the runtime level, so that chains can define coarse filters or granular pairs of (source, target) locations aliasing.

This RFC suggests a coarse set of aliasing rules that chains can use for allowing the vast majority of Transact usecases in a "one-click" manner (single user signature), without practically lowering their security posture.

Suggested Aliasing Rules:

1. Any chain allows aliasing origin into a child location. Equivalent to DescendOrigin into an interior location.
2. Parachains allow Asset Hub root location to alias into any other origin.

The first rule is allowing use of AliasOrigin with same effect as doing a DescendOrigin, so it is absolutely not controversial.

Now, the second rule as defined above in its most generic form might seem "dangerous" at first, but in practical terms if Asset Hub Root gets compromised and can access arbitrary sovereign accounts on Asset Hub and/or send arbitrary XCMs, the blast radius and potential damage to other chains is already so large that it is not relevantly impacted by this aliasing rule. A compromised system chain root would already be by itself an "apocalypse" scenario for the whole Polkadot Ecosystem.

It's important noting that the aliasing rules above are a suggestion only, ultimately they are chain specific configuration. Therefore, each chain can tighten them to their own liking. For example, use stricter range of locations that Asset Hub can alias like:

• "allow Asset Hub root to alias Ethereum locations" - which enables support for Transact over the Ethereum Snowbridge (but doesn't support sibling parachain to Transact through Asset Hub),
• "allow Asset Hub root to alias Kusama locations"
• "allow Asset Hub root to alias specific pallet or smart contract on Chain X"

Please note that Bridge Hub already does something similar today: Bridge Hub root is allowed/trusted to UniversalOrigin+DescendOrigin into any external location in order to impersonate/proxy external locations.

XCM InitiateAssetsTransfer instruction changes

A new parameter preserve_origin to be added to the InitiateAssetsTransfer XCM instruction that specifies if the original origin should be preserved or cleared.

InitiateAssetsTransfer {
	destination: Location,
	assets: Vec<AssetTransferFilter>,
	remote_fees: Option<AssetTransferFilter>,
+	preserve_origin: bool,
	remote_xcm: Xcm<()>,
}

This parameter is explicitly necessary because the instruction should be usable between any two chains regardless of their origin-aliasing trust relationship. Preserving the origin requires some level of trust, while clearing it works regardless of that relationship. Specifying preserve_origin: false will always work regardless of the configured alias filters of the involved chains.

Example scenarios

Transact within the ecosytem:

• between two chains using an asset native to either one of them for paying for Transact,
• between two chains using an Asset Hub asset (e.g. USDT) for paying for Transact,

Transact over Snowbridge (same for other bridges):

• user on Ethereum calls function in Parachain A on Polkadot, pays with ETH,
• user on ParaA on Polkdaot calls function on Ethereum, pays with ETH,

Drawbacks

In terms of ergonomics and user experience, this support for combining an asset transfer with a subsequent action (like Transact) is a net positive.

In terms of performance, and privacy, this is neutral with no changes.

In terms of security, the feature by itself is also neutral because it allows preserve_origin: false usage for operating with no extra trust assumptions. When wanting to support preserving origin, chains need to configure secure origin aliasing filters. The one suggested in this RFC should be the right choice for the majority of chains, but each chain will ultimately choose depending on their business model and logic (e.g. chain does not plan to integrate with Asset Hub). It is up to the individual chains to configure accordingly.

Testing, Security, and Privacy

Barriers should now allow AliasOrigin, DescendOrigin or ClearOrigin.

Normally, XCM program builders should audit their programs and eliminate assumptions of "no origin" on remote side of this instruction. In this case, the InitiateAssetsTransfer has not been released yet, it will be part of XCMv5, and we can make this change part of the same XCMv5 so that there isn't even the possibility of someone in the wild having built XCM programs using this instruction on those wrong assumptions.

The working assumption going forward is that the origin on the remote side can either be cleared or it can be the local origin's reanchored location. This assumption is in line with the current behavior of remote XCM programs sent over using pallet_xcm::send.

The existing DepositReserveAsset, InitiateReserveWithdraw and InitiateTeleport cross chain asset transfer instructions will not attempt to do origin aliasing and will always clear origin same as before for compatibility reasons.

Performance, Ergonomics, and Compatibility

Performance

No impact.

Ergonomics

Improves ergonomics by allowing the local origin to operate on the remote chain even when the XCM program includes an asset transfer.

Compatibility

At the executor-level this change is backwards and forwards compatible. Both types of programs can be executed on new and old versions of XCM with no changes in behavior.

New version of the InitiateAssetsTransfer instruction acts same as before when used with preserve_origin: false.

For using the new capabilities, the XCM builder has to verify that the involved chains have the required origin-aliasing filters configured and use some new version of Barriers aware of AliasOrigin as an allowed alternative to ClearOrigin.

For compatibility reasons, this RFC proposes this mechanism be added as an enhancement to the yet unreleased InitiateAssetsTransfer instruction, thus eliminating possibilities of XCM logic breakages in the wild. Following the same logic, the existing DepositReserveAsset, InitiateReserveWithdraw and InitiateTeleport cross chain asset transfer instructions will not attempt to do origin aliasing and will always clear the origin same as before for compatibility reasons.

Any one of DepositReserveAsset, InitiateReserveWithdraw and InitiateTeleport instructions can be replaced with a InitiateAssetsTransfer instruction with or without origin aliasing, thus providing a clean and clear upgrade path for opting-in this new feature.

Prior Art and References

• RFC: InitiateAssetsTransfer for complex asset transfers
• RFC: Descend XCM origin instead of clearing it where possible

Unresolved Questions

None

Future Directions and Related Material