Exploring Cross-Chain Interoperability With XCM

Overview

XCM is a cross-chain message format used for communication between blockchains mostly within the Dotsama ecosystem. As it isn't a full protocol it relies on Horizontal Relaychain Message Passing or SPREE (still a work in progress) to enable communication between blockchains using different consensus algorithms. Each XCM message is a set of instructions that can be interpreted by the XCVM executor which processes them until none is left or an error is returned in the process.

Through this mechanism, functionality such as cross-chain transfers (for both fungible tokens and NFTs), remote transfers, and remote execution can be triggered between blockchains that support them. Such a solution enables the development of multichain DApps that rely on a single implementation of their functionality (rather than a separate smart contract for every layer 2 technology). This would enable developers to focus on building secure products rather than ensuring secure execution between different blockchains(or layer 2 solutions). Let's dive deeper into how cross-chain communication using XCM works.

Configuration

An important first step would be to ensure that a blockchain’s XCM configuration is correct or otherwise desired cross-chain asset transfers and remote executions will fail. It consists of the following key elements

• Asset Transactor enables the XCM executor to perform asset transactions ( withdraws, deposits, transfers, etc) on the chain
• Barrier defines which commands are allowed to be executed on the chain
• The trader sets the rates of teach asset which can be used to pay fees for XCM messages. The assets need to be registered as sufficient on the chain. More on that in the following sections.
• Allowed Reserves specify which assets the chain can be used as a reserve for Reserve Asset Transfers (and for which chains).
• Allowed Teleports specify which assets can be teleported to the chain, and from which blockchain. Please note that enabling teleports from blockchain A to blockchain B does not necessarily mean that tokens can be returned in the same way. That would depend on chain B XCM configuration.
• Execute Filter defines which extrinsics allow remote execution using XCM. For example, AssetHub enables parachains on Polkadot, Kusama, or Rococo to register their assets by sending XCM messages which create an asset and set its metadata.
  ‍

XCM Channels

In order for two blockchains that support XCM would be able to execute messages, they would need to have open channels between them. To open a unidirectional channel a blockchain needs to send an XCM instructions that initiates the opening. After that, the chain that received the request needs to submit an XCM transaction to the relay chain that approves the channel opening. Both operations would require admin privileges or approval in a governance vote. After the approval on the receiving end parachain A (sender) will be able to send messages to parachain B (receiver). The same process needs to be repeated in reverse order to create a bi-directional HRMP channel between the two chains.

Registering foreign assets on a blockchain

In order to be able to access other chain's assets a blockchain would need to register them. This is usually done by creating entries in pallet_asset. After that, the universal location of the foreign asset needs to be linked to the newly created derivative asset on the chain. Parachains like AssetHub also allow to use of remote execution to create reserves from assets on other chains using XCM. These derivative assets will not be set as sufficient by default

MultiLocation

An XCM MultiLocation is a format in which foreign assets identify a universal location. It consists of two parts:

• Parent - a number that represents how far the relay chain is from the destination chain. The value would be 0 if the asset is on the same chain, 1 if it is on a sibling chain, and 2 if it is on a chain in another ecosystem (e.g. when sending XCM from a Kusama-based account to a Polkadot-based destination)
• Interior - could have a value Here which refers to the native asset of the chain. Otherwise, it would be represented as an array of Junctions that would specify the asset location within the original blockchain. For example, the interior of USDT on AssetHub is X2(PalletInstance(50), GeneralIndex(1984)) as it is registered through pallet_assets (which is assigned the value of 50 on AssetHub) and the asset ID of the token is 1984. However, the MultiLocation interior of the derivative of USDT on another parachain will be X3(Parachain(1000), PalletInstance(50), GeneralIndex(1984)) as the original asset is located on AssetHub which is the parachain with ID 1000.

Sufficient assets

Each asset created through pallet assets has a non-sufficient status by default. It could be changed but that will require a governance vote or admin privileges.

• Assets that are not sufficient require the account that transfers them using XCM to also hold a sufficient amount of the native token of the receiver chain. This balance will be used for paying the cross-chain transaction fees.
• Sufficient assets do not require the accounts that are sending/receiving tokens to hold the native asset of their respective chain in order to be able to transfer balances. By default, all native parachain assets have that status. Another asset that has it is USDT on AssetHub. Furthermore, they can be used to pay fees for XCM transactions

Cross-chain transfers

There are 2 types of cross-chain transfers currently available - Teleports and Reserve Asset Transfers

• Teleports work by burning the asset on the sender parachain and minting the equivalent amount on the beneficiary account on the destination parachain. Since the sender cannot control how the assets are used on the receiver end, a good practice to enable it only if there is a high degree of trust between the two blockchains (e.g. between System chain and Relaychain, AssetHub, and parachains for their native asset).
• Reserve Asset Transfers rely on a trusted third location (e.g. AssetHub or the sender chain for its native assets) to keep track of the transfers. The sender transfers the desired amount to the reserve and the beneficiary has to withdraw it from it by minting a derivative. When the new asset is burned on the receiver chain the balance will be returned to the sender. However, if the beneficiary mints additional derivative assets it won't be able to claim more than the allocated amount for them on the reserve location, This approach is designed for situations where there is less trust between the two participating blockchains.

Sovereign accounts

Sovereign accounts are a special type of account that are assigned to each parachain and are derived from its ParachainId. They cannot be used to transfer assets in the same way as regular accounts as this would require admin permission or approval through governance voting. This makes them a perfect location to store tokens when using reserve asset transfers. They can also be used for the origin of a remote extrinsic execution when it is allowed (e.g. creating foreign assets on AssetHub). There are two sovereign accounts associated with each parachain.

• Relaychain sovereign account is associated with the parachian for actions that involve the relaychain.
• A sibling sovereign account is used as the parachain’s account on other parachains that have opened HRMP bi-directional channels.

The future of XCM and cross-chain interoperability

As of now, cross-chain operations are mainly used for bridging fungible tokens from one chain to another. However, XCM allows for many other use cases that are likely to appear as it gets more widely used. Here are some examples of future improvements that we may see:

• Better documentation - currently most information about how to use XCM is scattered between blog posts, documentation of different blockchain projects, and StackExchange question responses. This slows the adoption of this promising technology and some form of go-to documentation (ideally with some general use case examples) could make it easier to comprehend the new technology and apply it in innovative ways
• More extrinsics for commonly used XCM operations - at the moment palletXcm supports only teleports and reserve asset transfers as standard operations and for every other use case developers need to create custom XCM messages. As adoption progresses additional standard operations could be wrapped in a similar type of extrinsics which will make the format easier to use as developers and end users won't need to understand how to compose XCM messages to be able to use it. One such example is the withdrawAndTeleport extrinsic developed on Trappist which allows an account to teleport a token that is not sufficient on a destination chain while paying the relevant fees with a specified sufficient asset.
• Expanding remote execution use cases - currently, its use case is quite limited mainly because such executions can be a potential source of security vulnerabilities. However, they also offer opportunities for a new type of cross-chain interactions that allow utilizing functionality not currently available on a single chain (e.g. accessing multi-chain liquidity pools)
• Cross-chain NFTs - while they are technically supported by XCM that does not ensure that the metadata that is stored with them will be accurately replicated on the destination. This requires additional coordination between the developer teams of the participating chains and a generic working solution to that problem is still yet to be proposed.

t3rn and XCM

Currently, t0rn has opened bi-directional XCM channels with Basilisk and AssetHub on Rococo. The chain configuration allows for transferring ROC, TRN, and USDT between the chains. Once this functionality is proven to work successfully in production the XCM execution configuration can be updated to support more assets from other parachains that wish to utilize the fail-safe multichain XCM capabilities of the Circuit protocol.
‍

Join Multichain Matters

Gain a competitive edge on interoperability and stay up to date with the development of t3rn. Get insights from Maciej Baj (Founder & CTO), alongside 15,000 subscribers - no spam, only value.

‍

‍