I am currently bridging the tokens from one Parachain to another, and I am examining two events to ensure the successful completion of the transaction. The first event is xcmpQueue.Success, which occurs on the destination chain, while the second event is xcmpQueue.XcmpMessageSent, which takes place on the chain from which I am bridging the tokens.

Both of these events provide a messageHash that I can compare to establish a connection between the two events and verify the successful execution of the transaction.

However, this approach requires me to maintain connections with both chains, which may be unnecessary. I am considering an alternative solution to address this concern.

In the block where the XCM message is received, I can examine the parachainSystem.setValidationData extrinsic and inspect the downwardMessages. Here is an example of what I observed:

  2001: [
      sentAt: 18,066,095
      data: 0x000210010400010200451f06080001000700e87648170a1300010200451f06080001000700e8764817010220bcbe0d01000400010100d8a1107cf72bacdb288d6fd9af62dc85988f267043c4958821b215a24055706d

Although I am unsure about the specific contents of the data, my assumption is that it could be used to compute the same hash as in the xcmpQueue.Success event. Hence, my question is twofold: How can I decode the data field, or is there an entirely different approach that would allow me to achieve my intended outcome?

I would greatly appreciate any assistance or guidance you can provide. Thank you.

1 Answer 1


Great question! As you probably know, one of the properties of XCM is that it is asymmetric - so you fire away and there is no guarantee of results.

That being said, you can use the following instructions:

  • ReportHolding
  • QueryPallet
  • ReportError
  • ReportTransactStatus

Each of these instructions include a QueryResponseInfo struct:

pub struct QueryResponseInfo {
    pub destination: MultiLocation,
    pub query_id: QueryId,
    pub max_weight: Weight,

The consensus system that receives this instruction would execute the instruction that includes the QueryResponseInfo and send a corresponding QueryResponse:

QueryResponse {
    query_id: QueryId,
    response: Response,
    max_weight: Weight,
    querier: Option<MultiLocation>,

// Reponse Struct
pub enum Response {
    /// No response. Serves as a neutral default.
    /// Some assets.
    /// The outcome of an XCM instruction.
    ExecutionResult(Option<(u32, Error)>),
    /// An XCM version.
    /// The index, instance name, pallet name and version of some pallets.
    PalletsInfo(BoundedVec<PalletInfo, MaxPalletsInfo>),
    /// The status of a dispatch attempt using `Transact`.

A lot more on this subject is written here:

with some concrete examples here:

You may also be interested in the Expect instructions:

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.