XCM messages not decoded when `decodedXcmMsgs=true` - returns raw hex data instead

[TarikGul]

Description

When querying blocks with decodedXcmMsgs=true, the API returns raw hex-encoded data instead of decoded XCM messages.

Steps to Reproduce

Query a Polkadot block with XCM messages:

GET /v1/blocks/30219740?decodedXcmMsgs=true

Expected Behavior

The decodedXcmMsgs field should contain decoded XCM message structures with human-readable instruction data.

Actual Behavior

The response contains raw hex data in the data field instead of decoded XCM:

{
  "decodedXcmMsgs": {
    "horizontalMessages": [],
    "downwardMessages": [],
    "upwardMessages": [
      {
        "originParaId": "3428",
        "data": "0x019800240801122027dfed38c9c2df1dd987f71f8a661552bd5f7aed01a86fe043484a04f1770cc0"
      },
      {
        "originParaId": "3428",
        "data": "0x000001"
      }
    ]
  }
}

Context

- Block 30219740 on Polkadot contains upward messages from parachain 3428
- Sidecar fails to decode this block with error: createType(XcmVersionedXcm):: Unable to create Enum via index 152
- The first byte 0x98 (152 decimal) suggests this may not be a standard VersionedXcm - possibly a different message type or custom encoding from the parachain

Environment

- Network: Polkadot
- Block: 30219740
- Parachain origin: 3428

[decrypto21]

Root Cause

The messages from parachain 3428 (SORA) are not XCM messages. They are SORA's proprietary HASHI bridge protocol messages sent via UMP (Upward Message Passing).

XCM format is not enforced at the protocol level for UMP transport. SORA uses UMP to ferry messages for its custom bridge between the SORA parachain and the SORA mainnet (a standalone Substrate chain). The payload is SCALE-encoded BridgeCall - a SORA-specific enum defined in sora2-common/pallets/types/src/substrate.rs:

The first byte 0x00 maps to ParachainApp, 0x01 maps to XCMApp, etc. These are not valid VersionedXcm discriminants (which are 2 = V2, 3 = V3, 4 = V4, 5 = V5), which is why decoding fails.

This is not limited to SORA - we observed the same pattern from:

• Para 3367 on Polkadot
• Para 3392 on Kusama
• Even para 1000 (Kusama Asset Hub) sends bridge-format messages in some blocks

In fact, in recent Polkadot blocks, bridge messages heavily outnumber actual XCM: ~961 bridge messages vs ~1 XCM message across 50 blocks.

Polkadot-rest-api vs Sidecar behavior

Scenario	Polkadot-rest-api	Sidecar
V4 XCM messages	✔ Decoded correctly	✔ Decoded correctly
Non-XCM bridge messages	✔ Returns raw hex gracefully	X Crashes with HTTP 500 (createType(XcmVersionedXcm):: Unable to create Enum via index 152)

Polkadot-rest-api is already handling this correctly.
The decode_xcm_message() function attempts to decode the bytes as VersionedXcm, and when that fails (as it should for non-XCM messages), it falls back to returning the raw hex string. This is the correct behavior - these bytes are not XCM and cannot be decoded as XCM.

Why we can't decode these bridge messages
Polkadot-rest-api decodes extrinsics dynamically using runtime metadata from the connected chain. The only hardcoded type dependency is staging-xcm for VersionedXcm.

Bridge messages like SORA's BridgeCall are parachain-specific types that:

1. Are not defined in the relay chain's runtime metadata (UMP payloads are just Vec)
2. Are defined in SORA's own crates (bridge-types), not in any standard Polkadot crate
3. Would require importing and maintaining type definitions for every parachain's custom protocols

This would be an unbounded maintenance burden and is outside the scope of a generic API.

Resolution

Should be closed as working-as-designed. The raw hex output for non-XCM UMP messages is the correct and expected behavior. Polkadot-rest-api already handles this more gracefully than Sidecar (which crashes).

Related
During this investigation, we identified a separate, actionable bug: V5 XCM messages (first byte 0x05) are not decoded because staging-xcm v14 only supports V2–V4. V5 XCM exists in the wild (e.g., Polkadot block 28490504, para 1000). This is tracked in #296