[XCM] META: XCM additions

[franciscoaguirre]

Rationale

We want to make XCM more powerful, specifically in our journey to get all non-security functionality out of the relay chain.
For this we need to support more and more use cases over XCM, and make them more ergonomic and less error-prone.
A use case this new version aims to attack is staking, looking at a future staking parachain (stakemine? 🤔).

This was originally an issue for tracking the development of v4, but v4 had to be a simple renaming upgrade.
Because of the XCM RFC process, new versions will just be a list of accepted RFCs to be implemented.
The below instructions are intended to be added at some point, but they'll only be added once an approved RFC comes along.
The RFCs live in the xcm-format.

New instructions

Holding and slashing

Instructions for holding assets and freeing them. Similar to the locking instructions introduced in v3 (LockAsset, UnlockAsset, NoteUnlockable, RequestUnlock).

• HoldAsset
• ReleaseAsset
• NoteReleasable
• RequestRelease
• SlashAsset

This instructions would allow one system to communicate to another one that they are effectively holding assets and they are allowed to be slashed if the need arises.
While locking might work for proving you can vote on a different chain, holding and slashing allows for things like (but is not limited to) staking.

Good UX would be for voting and staking messages to a different chain (NoteUnlockable and NoteReleasable) to be free given that you've already locked/held a certain amount of assets.
Free always means rate limited.
This might be for locking/holding assets over a certain amount (e. g. 10 DOT).

Setting an agent (controller account) to operate in a different system on behalf of the origin

Instructions to set and reset an agent on another system.
This agent can perform actions on the receiver as if you the origin had an account there.

• SetAgent
• ResetAgent

This instructions will be interpreted differently based on the receiver.
For example, if the receiver is a staking parachain, the agent will have the privilege to stake on behalf of the origin who set it.
In this case, you might need to hold assets locally (or via XCM, like on statemint) and let the agent know you have held them.
The agent account can then receive staking rewards and slash your held assets over XCM if necessary.

Another example is the agent lives in a voting parachain.
In that case you'd need to lock some assets locally (or on statemint) and let the agent know so it can vote for you.

Voting instructions

Governance is a really useful and frequent feature of consensus systems.
Because of this, v4 might have specific voting instructions like the following:

• Vote
• Unvote
• Delegate
• Undelegate

Querying exchange rate

New instruction to query the exchange rate between two assets, could work for NFTs as well.

• QueryExchange

Might also be something like HintExchangeRate, it won't swap assets, it will just return an estimation of how much of one asset you'd get by swapping some amount of some other asset.

Temporary account

An instruction to create a temporary account on the receiver to be able to add liquidity or transfer assets.

• SetTempAccount

WithClearOrigin

An instruction to be able to "pop" the latest origin while executing another XCM but then returning to the original origin.
This provides a more ergonomic way to deal with multi-chain interactions.

• WithClearOrigin

It would be used like:

// Executing Xcm instructions with a particular origin
WithClearOrigin(Xcm(vec![
  // Do things without origin
]))
// Keep on executing Xcm instructions with the same origin as before

Low priority instructions

Adding/removing liquidity

Instruction to add/remove liquidity to a liquidity pool. It's a useful function but specific, many systems wouldn't implement it. Right now can be done via the Transact instruction.

• AddLiquidity
• RemoveLiquidity

Sync metadata

An instruction to sync asset metadata, for example for NFTs. Might be too specific, heavy and might be able to be implemented with Transact already.

• SyncMetadata

[xlc]

Can I suggest that we have a spec draft before implementation? https://github.com/paritytech/xcm-format
There should be a RFC process for XCM

[franciscoaguirre]

Certainly! I created this issue here first for bookkeeping purposes while I figure out an RFC format for the xcm-format repo. Will be creating RFCs in that repo in the following days.

[Polkadot-Forum]

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

https://forum.polkadot.network/t/xcm-rfc-process/2447/1

[ntn-x2]

I see the issue has ben put into the project "Deadline Q4 2023". Can we then expect a Polkadot release with XCM v4 by the end of the year?

[KiChjang]

XCM v4 is actually going to be using the new RFC process to make changes to XCM itself. We will in fact be creating RFCs for each and every individual feature that Francisco has written down on this issue.

As such, it's hard to say exactly for sure when we can release XCM v4, as it first depends upon community agreement on the new features that we want to introduce to v4, and then it depends upon the implementation difficulty of said features. However, assuming absolutely everything goes smoothly, we believe that we can release it by the end of the year, but do keep in mind that this is the optimistic happy path.