How can I transfer assets using XCM?

Question

XCM, being the cross-chain (or more appropriately, cross-consensus) protocol designed to pass messages between disparate blockchains or consensus systems, has the ability to transfer crypto-assets, how exactly can I utilize XCM to do so?

Answer 1

There are two main ways in which assets are transferred between consensus systems in XCM. They are namely via Asset Teleportation or via Reserve Asset Transfers.

First of all, a preamble -- XCM instructions are always going to be interpreted according to the consensus system that executes them, and so for all of the instructions that I am going to explain below, always remember that the exact behaviour may change depending on which consensus system processes them. What I would hence be describing are the basic behaviours that you can expect each consensus system to possess, regardless of their peculiarities.

With that said, I am going to describe the intricacies with the two asset transfer models below.

Asset Teleportation

We start with the easier and more straightforward of the two -- Asset Teleportation. As you can see from the diagram above, there are only 2 actors within this model: the source and the destination. The way in which we transfer assets between the source and the destination are briefly summarized in the numbered labels on the diagram, and are explained in more detail below:

1. InitiateTeleport

The source gathers the assets to be teleported from the sending account and takes them out of the circulating supply, taking note of the total amount of assets that was taken out.

2. ReceiveTeleportedAssets

The source then creates an XCM instruction called "ReceiveTeleportedAssets" and puts the amount of assets taken out of circulation and the receiving account as parameters to this instruction. It then sends this instruction over to the destination, where it gets processed and new assets gets put back into circulating supply accordingly.

3. DepositAsset

The destination then deposits the assets to the receiving account of the asset.

The phrases taken out of circulating supply and put back into circulating supply are highlighted above to firstly give an indication of how much flexibility an XCM executor has in implementing the semantics of taking an asset out of and putting it back into its circulating supply. The straightforward answer is to burn the assets to take them out of circulation, but one can imagine that there are indeed multiple methods of achieving the same goal, such as transferring the assets locally to an inaccessible account, and likewise for putting assets back to circulation -- the receiving consensus system can freely choose to implement such semantics by releasing assets from a pre-filled and inaccessible treasury of the assets transferred, or perform a mint of the assets.

As such, the above also gives a hint on the disadvantages of this model -- it requires both the source and destination of have a high level of mutual trust. The destination must trust that the source has appropriately removed the assets that was sent over from the circulating supply, and the source must also trust the destination to put the assets that was taken out of circulation back into circulation. The result of an asset teleportation should result in the same circulating supply of the asset. Failing to uphold either of these two conditions will result in a change in the asset's total issuance (in the case of fungible tokens) or a complete loss/duplication of an NFT.

Reserve Asset Transfer

For consensus systems that don't have the level of trust required for asset teleportation, they can instead opt for trusting a 3rd entity called the reserve to store the real assets (think Statemine on Kusama or Statemint on Polkadot). What this entails is that the source and destination will have to create some sort of mechanism to keep track of the assets that they own on the reserve, and this is usually done by minting a new derivative token. As a corollary, both the source and destination must have accounts on the reserve -- we'll refer to such accounts owned by the source/destination as Sovereign Accounts.

Below are the steps in which a reserve asset transfer undergoes in order to transfer assets from the source to the destination:

1. InitiateReserveWithdraw

The source gathers the derivative assets to be transferred from the sending account and burns them, taking note of the amount of derivatives that were burned.

2. WithdrawAsset

The source sends a WithdrawAsset instruction to the reserve, instructing the reserve to withdraw assets equivalent to the amount of derivatives burned from the source chain.

3. DepositReserveAsset

The reserve deposits the assets withdrawn from the previous step to the destination's sovereign account, taking note of the amount of assets deposited.

4. ReserveAssetDeposited

The reserve creates a ReserveAssetDeposited instruction with the amount of assets deposited to the destination's sovereign account, and sends this instruction onwards to the destination. The destination receives the instruction and processes it, minting the derivative assets as a result of the process.

5. DepositAsset

The destination deposits the derivative assets minted to the receiving account.

The addition of a 3rd consensus system is already a hint of the disadvantages of a reserve asset transfer model -- firstly, the reserve could easily become a point of centralization when too many consensus systems rely on it to be the reserve of choice for their assets; secondly, the sheer amount of steps required necessarily makes it more prone to errors, and as such, implementors will have to consider more possible pitfalls and provide technical support accordingly when an end user encounters issues arising from these steps. Last but not least, either of the source or destination can opt to designate multiple consensus systems to be their reserves, and in such a situation, care must be taken in order to ensure that the sovereign account on the reserves are balanced, so that one doesn't get all drained while the others still contain a healthy balance.

One additional point of interest here is that I am also seeing that people are combining the roles of the source and reserve together, so that the source chain also acts as the reserve chain for their native token. This does make the reserve transfer process easier, in the sense that they would only need to execute a DepositReserveAsset to the sovereign account of the destination locally, and emit a ReserveAssetDeposited message to the destination. The destination would still however need to 1) recognize the source as the proper reserve for the tokens that are being sent over and 2) support minting derivatives of the tokens being sent over.

Summary

Despite being more complex, consensus systems often will first pick the reserve asset transfer model over asset teleportation, due to the trust issues discussed. However, we could imagine that as the source and destination continue to prove themselves to be trustworthy and cooperative on the reserve, they could then negotiate for an asset teleportation agreement and switch over to that entirely.

As such, we could in fact think of the reserve asset model as a way to establish a baseline of trust between the source and destination. They could even move into various intermediate arrangements, such as unifying the derivative tokens so that they all get issued by either the source or the destination, instead of having each minting their own derivatives. Whether or not the source and destination will move beyond the reserve asset transfer model is up to them to decide.

For further reading of XCMs in general, Gavin has plenty of blogposts that describe each component of the XCM in detail. Shawn also has an excellent video describing how you can craft your first cross-chain messages. Finally, there is also the XCM specification that is the definitive source of truth on any matters related to XCM.