My First Blog. Everything XCM Made Simple.

6 min readMay 23, 2022

Hello. Welcome to my blog.

I graduated from Washington and Lee University two years ago with a Summa Cum Laude BA in English and Chinese (full major name: East Asian Languages & Literatures). With no technical background whatsoever rather than some day-one HTML picked up from a free Codecademy course and video editing skills, I'm now writing as Marketing Executive and Researcher at SubWallet — what a turn of events. I'll share about my journey later if anyone is interested (hint: it's pretty rocky).

For now, allow me to proudly present my first research project on Polkadot's XCM where I try to pull in information scattered around various sources and make it as digestible as possible. I fumbled for a good week, found no place where XCM is explained in common terms for regular users, and so decided to write this article. If you have any further questions, please leave a comment so I can continue my quest for clues in the internet sea, or simply nag our developers at SubWallet for help.

Let's jump in.

What is XCM?

XCM is short for cross-consensus messaging, a format that allows communication between various consensus systems, including, but not limited to, relay chains, parachains, dApps, and smart contracts. This means that a parachain can talk to a relay chain, a neighboring parachain, a parachain or even a smart contract on another ecosystem (say Ethereum) via bridge, and the list goes on. The possibilities are endless.

Why do we need XCM?

Imagine each parachain as a country, and an ecosystem as a continent. To facilitate trade and eventually growth, countries need to find ways to communicate with one another, thus the need for one common language. XCM is this common language. Whatever messages sent are written in the XCM language so that the recipient can decode and act upon the instructions.

How does XCM do that?

In order to be the language that connects them all, XCM retains the following properties:

General: Being general allows it to be flexible and extensible. XCM is compatible with different fee-based systems, be it a fee-free or a gas-metered smart contract platform. It can even interact with systems whose transaction formats are unknown.
Well-versioned: As countries and communities evolve in keeping with market demands, so does the language. Independent XCM messages are always wrapped inside an envelope that denotes which version of the language they are using so that newer and older systems can recognize and act accordingly.
Efficient: High efficiency means that XCM is usable even in metered environments such as in a smart contract.

Can you elaborate on versioning?

Yes. So we know there’s a container wrapping around the XCM-formatted message that serves to notify systems of which version of XCM language is being used. Three key points about versioning discussed by Gavin Wood the Polkadot godfather are summarized below:

Compatibility & Translation: Every version is both backwards-compatible and forwards-compatible when possible, meaning that version 1 is compatible with both version 0 and version 2. This permits easier and smoother transition between consecutive versions.
Practical Communication: Note that not all messages can be interpreted by all systems, say a v2-enabled system is able to understand a v0 message, yet a v0-enabled system cannot decipher a v2 message. The sender therefore always needs to make sure that the message it is sending is readable by the recipient.
Version Negotiation: The making-sure process mentioned above is autonomized by a version-tracking mechanism, allowing senders to query for the XCM version used and processable by the recipient as well as to get notifications on any change with regards to this.

What are the use-cases of XCM?

The possibilities are limitless, but here are some initial and practical XCM use-cases:

Teleporting: If two endpoints trust each other and have the same native asset, they can choose this type of asset transference. After the XCM is executed, the asset is burned on the sending network and minted on the receiving network. Thus, teleporting is cheaper and faster but requires trust. Statemint has reportedly supported DOT teleporting.

Reserved-based Transfer: If two endpoints do not necessarily trust each other, they agree on a third-party holder as a reserve. Both endpoints have their own accounts on the third chain called Sovereign Accounts, and the transfer is made between these two Sovereign Accounts. Once the transaction is finished on the third chain, the sending network burns the native assets and the receiving network mints derivative assets. Reserved-based transfer is slower and more expensive but does not require trust. So far Moonbeam is currently implementing this type of transfer to support xcDOT, xcACA, and xcaUSD.

What is the life cycle of an XCM?

Image courtesy of Polkadot. I add the text on the right.

We go from top to bottom with the figure above: first a user places a request, then an XCM is built on an XCM interface, then the XCM message is transferred via a transport protocol, and finally the XCM message is executed in a consensus environment. (See more on Moonbuilders Workshop: A Technical Introduction to XCM on Moonbeam, starting 7:40).

What is XCMP?

You see it on the figure above, you heard it somewhere, the abbreviation looks like XCM. It’s quite different. XCMP is short for cross-chain message passing. Together with VMP aka vertical message passing, they are protocols that assist the transporting of XCM messages within Polkadot.

How do VMP and XCMP work?

For VMP, there are two kinds:

UMP, or upward message passing. Message data goes from parachain up to relay chain.
DMP, or downward message passing. Message data goes from relay chain down to parachain.

For XCMP, there are direct route and relayed route:

Direct: Message data goes directly from parachain to parachain, thus the model is scalable. This direct route is currently under development.
Relayed: Message data passes through relay chain, then from relay chain to parachain via VMP. This model is being used under the name HRMP aka horizontal relay-routed message passing, or XCMP-Lite. Since HRMP routing is cumbersome and takes up storage on the relay chain, it will be phased out once the direct route is launched.

Why don’t we just jump into building the direct route?

Sounds like something intuitive but it’s not. In order for XCMP and VMP to work, channels have to be opened between endpoints. When parachains get “attached” to the relay chain, the channels between them and the relay chain are established by default. Therefore, while waiting for the road between parachains themselves to be built, it is only natural to use the ready-made route via the relay chain.

Can XCM be transferred two-way?

No. If two endpoints want to communicate two-way, they need to open two channels, one for sending and another for receiving. In fact, XCM is designed around four elements:

Absolute: XCM messages are guaranteed to be delivered correctly in order and in a timely fashion.
Agnostic: XCM messages are compatible with a variety of consensus systems.
Asynchronous: XCM messages can be transferred continuously without having to synchronize with block production.
Asymmetric: XCM messages are one-way only and do not have results.

That's it for this one. For a more in-depth understanding of XCM, be sure to check out these resources:

Adios!