💰 Assets in XCM

Most messages will deal with assets in some way.

How do we address these assets?

---v

Asset Representation

#![allow(unused)]
fn main() {
struct Asset {
    pub id: AssetId,
    pub fun: Fungibility,
}

struct AssetId(Location); // <- We reuse the location!

enum Fungibility {
    Fungible(u128),
    NonFungible(AssetInstance),
}
}

Notes:

We use locations, which we've already discussed, to refer to assets.

A Asset is composed of an asset ID and an enum representing the fungibility of the asset. Asset IDs are the location that leads to the system that issues it, this can be just an index in an assets pallet, for example.

Assets can also either be fungible or non-fungible: Fungible - each token of this asset has the same value as any other NonFungible - each token of this asset is unique and cannot be seen as having the same value as any other token under this asset

---v

Asset filtering and wildcards

#![allow(unused)]
fn main() {
enum AssetFilter {
    Definite(Assets),
    Wild(WildAsset),
}

enum WildAsset {
    All,
    AllOf { id: AssetId, fun: WildFungibility },
    // Counted variants
}

enum WildFungibility {
    Fungible,
    NonFungible,
}
}

Notes:

Sometimes we don't want to specify an asset, but rather filter a collection of them. In this case, we can either list all the assets we want or use a wildcard to select all of them. In reality, it's better to use the counted variant of the wildcards, for benchmarking.

Reanchoring

How do different locations reference the same asset?

Notes:

Locations are relative, so they must be updated and rewritten when sent to another chain, for them to be interpreted correctly.

Native tokens are referenced by the location to their system.

---v

USDT from Asset Hub

PalletInstance(50)/GeneralIndex(1984)

---v

USDT from Bridge Hub

../Parachain(1000)/PalletInstance(50)/GeneralIndex(1984)

---v

Reanchoring to the rescue

🤹 Cross-consensus transfers

Notes:

The two ways of transferring assets between consensus systems are teleports and reserve transfers.

---v

1. Asset teleportation

Notes:

Teleportation works by burning the assets on the source chain and minting them on the destination chain. This method is the simplest one, but requires a lot of trust, since failure to burn or mint on either side will affect the total issuance.

---v

1.1. Example: System parachains?

---v

1.2. Example: Polkadot and Kusama?

---v

2. Reserve asset transfers

Notes:

Reserve asset transfers are more complicated, since they bring in a third actor called the reserve chain. Chain A and B needn't trust each other, they only need to trust the reserve chain. The reserve chain holds the real assets, A and B deal only with derivatives. The transfer is made by burning derivatives from A, moving them from A's SA to B's SA in R, then minting on B.

In some cases, the sender, A, can also be the reserve for a particular asset, in which case the process is simplified, there's no burning of derivatives. This usually happens with parachains' native tokens.

You always trust the issuer of the token to not mint infinite tokens.

---v

2.1. Example: Parachain native tokens

Notes:

Most parachains act as the reserve for their own token. To transfer their token to other chains, they move the real assets to a sovereign account and then tell the chain to mint equivalent derivatives.

---v

2.2. Example: Polkadot to Kusama

Notes:

AssetHub Kusama acts as the reserve for KSM. Kusama doesn't trust Polkadot to teleport KSM to it, but it does trust its own reserve, the AssetHub. Polkadot has a sovereign account in Kusama's AssetHub with some amount of KSM. Whenever some user in Polkadot wants to get KSM on Kusama, they just give the DOT to Polkadot and the KSM are moved from one sovereign account to another. No new trust relationships are added.

Summary

• XCM
• XCM vs XCMP
• Locations
• Sovereign Accounts
• Assets
• Reanchoring
• Cross-consensus transfers
  • Teleports
  • Reserve asset transfers

---v

Next steps

1. Blog series introducing XCM: Parts 1, 2, and 3.
2. XCM Format repository
3. XCM Docs

---v