paritytech/substrate-api-sidecar

Correctly Interpret XCM messages?

will-yjn opened this issue · 3 comments

will-yjn commented

Description

Related to this issue: #1401
Tx hash: https://kusama.subscan.io/xcm_message/kusama-68882b46f2567e950457e91afcf189c2cbfbf0a1
The curl request: curl -X GET "http://0.0.0.0:8080/blocks/21548602?decodedXcmMsgs=true" -H "accept: application/json"

The XCM is sent on block 21548600. The decodedXcmMsgs does not show the exact address: EtM6qyZJz4qjM8uf91DLQiztsTYupnobp6iDLmNxNJeVaRi, but it does show the id: 0x6638373965e8969f5d960c781c56ee438ae0b6d4f93f56da9bc285e6e51ccc6e, and the amount sent from the origin chain: 1000122874273.

On the other hand, the message is processed on block 21548602. The onInitialize.events does have an event:

            {
                "method": {
                    "pallet": "balances",
                    "method": "Deposit"
                },
                "data": [
                    "EtM6qyZJz4qjM8uf91DLQiztsTYupnobp6iDLmNxNJeVaRi",
                    "1000041094728"
                ]
            },

But the event is not balances.Transfer which we used to determine a transfer event happened. And the amount is not the amount withdrawn from the origin chain.

Should we use the decodedXcmMsgs on block 21548600 or the balances.Deposit event on block 21548602 to determine a deposit?

Imod7 commented

Just to clarify, your question here is related on how to correctly track and parse XCM transfers (and the balance changes as a result of those) and not to report a bug in Sidecar.

As far as I checked, the endpoint is working as expected. The XCM instructions displayed on Subscan aligns with the information returned by Sidecar including the id part you mentioned:

 "parents": "0",
                  "interior": {
                    "x1": {
                      "accountId32": {
                        "network": null,
                        "id": "0x6638373965e8969f5d960c781c56ee438ae0b6d4f93f56da9bc285e6e51ccc6e"

which is consistent across both platforms.

Regarding your question about tracking transfers: while such questions are typically addressed on Substrate and Polkadot Stack Exchange, I can provide some guiding points.

As a general note, tracking XCM transfers is not as straightforward as you would expect. Primarily because it depends on the specific chain you are connected to. Each chain might have their own customized implementation of XCM.

Regarding the events you see, the presence of a Deposit event instead of a Transfer event is expected. This is due to the agnostic nature of XCM which is also explained in this polkadot forum post :

... The intent is that XCM be general rather than be constrained to the lowest-common denominator which all systems could possibly support perfectly. Withdraw + Deposit is strictly more general than Transfer. You can accomplish everything with a combination of Withdraw & Deposit which you can with Transfer, but not the other way around ...

You can also check this SE post for some additional context on events.

As for the id you see instead of an address, this is also expected. The reason is because in XCM messages, we use Multilocations, which represent locations relative to the current location (and we do not use addresses). You can read more about this concept in the Polkadot wiki - Multilocation.

Last, to your question on which information to track, I would recommend to monitor both the decodedXcmMsgs on block 21548600 and the balances.Deposit event on block 21548602. This will give you a full picture of the XCM transfer since they convey different information. The first one indicates that an XCM message was included/sent and the second signifies that a deposit was made to an account as a result of this XCM message.

EDIT: A very useful and related resource is the section of XCM Transfer Monitoring from the Polkadot wiki. Credits to @IkerAlus for reminding me this one.

  • 👍2
  • ❤️2
will-yjn commented

The above tx succeeded. What would happen if after 1-2 blocks when Kusama process the message, it failed? How would subscan interpret a failed message when processed?

Imod7 commented

As I previously mentioned, this type of questions are better suited for our Stack Exchange platform. The purpose of submitting issues in this repository is when bugs are found or new features are proposed in this specific tool.

I will answer this last question and close this issue as resolved : In Subscan you can use the Filter option and see all Failed XCM messages. Then you can choose one and see the events emitted, e.g. in this HRMP the event xcmpqueue (Fail) is returned.

  • 👍1