With not much XCM experience, I understand that with the Transact instruction one can call an arbitrary extrinsic in another chain passing the encoded Call which is specific to a particular chain(e.g. the index is based on the order of definition of the pallets).

What I'd like to know, maybe for a future XCM version if not currently possible, is how to send generic instructions that are chain agnostic and don't depend on specific implementations, e.g. the common case of asset transfers that follow the fungibles interface. I believe there's already support for fungibles so one question is how does it work and another is how could we implement more of those "standards" easily.

3 Answers 3


When it comes to generic instructions that don't depend on specific implementations, I don't think XCM is the right answer, because how an XCM instruction gets interpreted is always determined by the chain executing said XCM instruction. That goes to say that even for "generic" XCM fungible instructions like WithdrawAsset, there's no guarantee that the asset being withdrawn is always going to be from the Balances pallet, and the sender is unable to control any of such behaviours.

The more appropriate mechanism for executing cross-consensus instructions with well-defined semantics will be SPREE, but it is still in the works.


The XCM Format repository provides a place to propose and discuss additions to the XCM protocol. There is at present no means to introduce unofficial format extensions outside of the mainline versioning system (which is linear in nature), though the Transact instruction allows chains to query and utilise custom functionality in each other.

It should be possible to add a more flexible extension system to the XCM format, with the list of extensions being part of the XCM version identifier, however nothing is proposed yet.

  • Left some thoughts in github.com/paritytech/xcm-format/pull/28 with more context in the linked polkadot issue :) Are issues and PRs there the right way to start conversations around the evolution of XCM?
    – olanod
    Commented Apr 27, 2022 at 14:19

generic instructions that are chain agnostic and don't depend on specific implementations

This is basically what the entire XCM protocol is providing. XCM has made a generic interface for all the "common" cross chain messaging like asset transfers, taking / paying fees, etc...

The Transact instruction is the exception, where we make no guarantees about the underlying behavior from chain to chain, since it is literally just an opaque blob which needs to be interpreted by the receiving chain.

If you want to extend the number of available generic calls, you can make feature requests to the XCM protocol itself, or define your own custom interface pallet which is shared across the chains you talk to, and acts as a wrapper over the underlying implementations done by custom pallets.

  • Thanks, I was suspecting new instructions to be an answer but doesn't feel like it scales well for the many possible use cases the community can come up with, I see instructions as something static and low-level that probably should go through a lengthy process of review to know if it's really needed, not ideal for example for a handful of chains that want to "teleport kittens" one day and make "dogos bark" another.
    – olanod
    Commented Mar 8, 2022 at 9:11
  • Perhaps we need some sort of "XCM extensions" so the community can extend the base instructions and play with what could later become a "core instruction"? I'm thinking for example encoding the interface of "teleport kitten"(pretty much how it's already done in the metadata with the type info) and communicate over XCM that I provide that interface(the encoded interface can be hashed). A "DynamicTransact" would instead of encoding the Call with the index of the pallet attach the hash of the interface that it follows?
    – olanod
    Commented Mar 8, 2022 at 9:29
  • This is a possibility, but it's not a complete solution. The XCM instruction set and XCVM register set could reasonably support independent and composable extensions. However, these do not form the whole XCM protocol. MultiLocation and MultiAsset are two of the many other dependent types used substantially. Many of these types would not easily support independent and composable extensions, meaning that authoring an extension to XCM would look rather different to authoring a new version of XCM.
    – Gav
    Commented May 5, 2022 at 10:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.