PaperlayerView exact revision on arXiv

Source-linked AI summary

XIM: The XDC Interledger Messaging Protocol

Atul Khekade, Ritesh Kakkad, Wanwiset Peerapatanapokin, Behnam Mohammadkhani

arXiv:2609.39310v1cs.CRcs.DC

TL;DR

Heterogeneous ledgers and payment systems need to exchange authenticated messages, but their different execution, finality, privacy, and governance models complicate interoperability. XIM specifies canonical messages with lane-specific verification policies and separates message semantics from other protocol functions. Its supported conclusion is a modular framework for interoperability across public chains, institutional assets, privacy-preserving ledgers, and authenticated financial gateways.

  • Problem

    Public, permissioned, institutional, and conventional payment systems have different execution, finality, privacy, and governance models, while point-to-point bridges do not scale as the number of networks grows.

    Source: §1 · p. 1

  • Method

    XIM uses canonical authenticated messages and explicit lane-scoped verification policies while separating message semantics from transport, verification, routing, execution, and settlement.

    Source: §1 · pp. 1–2

  • Results

    XIM specifies a modular protocol framework for public-chain interoperability, institutional tokenized assets, stablecoin settlement, privacy-preserving ledgers, and authenticated connections to traditional financial rails.

    Source: §30 · p. 16

  • Takeaways & Limitations

    Heterogeneous networks can retain their native consensus, privacy, governance, and execution models while participating in a common message lifecycle and verification framework.

    Source: §29 · p. 15

    XIM cannot make a compromised source ledger truthful, and gateway attestations inherit signer and key-management risk.

    Source: §28 · p. 15

Abstract

from arXiv · show

Distributed ledgers, privacy-preserving institutional networks, and conventional payment systems increasingly need to exchange authenticated messages and settle assets across heterogeneous trust domains. Existing interoperability systems typically optimize for one of three concerns: application-level abstraction, cross-chain message transport, or synchronized execution within a related ledger family. This paper proposes XIM, the XDC Interledger Messaging Protocol, a chain-agnostic protocol for transporting canonical messages across heterogeneous networks while allowing each communication lane to select an explicit verification policy. XIM separates message semantics from transport, verification, execution, routing, asset identity, and compliance metadata. Its cryptographic state is represented by deterministic message identifiers and commitment roots, while an append-only transition log provides auditability and replay protection. XIM introduces a Universal Asset Identifier (UAID), a pluggable adapter interface, lane-scoped security policies, and an optional policy-aware route graph for multi-hop settlement. XDC Network can serve as a coordination and settlement domain without requiring every XIM message or route to transact through XDC. We specify the protocol model, state machine, message encoding, commitment structure, verification modes, failure semantics, security assumptions, threat model, implementation architecture, and an incremental deployment plan. The design targets public blockchains, permissioned ledgers, institutional networks, and authenticated financial-system gateways, with particular attention to stablecoins, tokenized assets, trade finance, and ISO 20022-compatible payment workflows.

1 Introduction

As financial infrastructure spreads across networks with different execution, finality, privacy, and governance models, point-to-point bridges do not scale and a universal consensus system would require networks to abandon their native models. XIM instead treats interoperability as authenticated message exchange, with a canonical message and lane-specific verification policies.

1 Introduction

  • XIM separates transport, verification, routing, execution, and settlement so a compromise in one component should not automatically grant authority over the others.Each source–destination lane selects a verification policy suited to the connected systems’ value, finality, and trust characteristics.Source: §1 · p. 2

1.1 Contributions

  • The contributions combine a canonical message envelope, commitment-oriented state, and a cross-domain lifecycle with acknowledgement, timeout, refund, and terminal-failure semantics.The envelope is independent of source-chain transaction format; commitment state uses message hashes and Merkle roots rather than global replication of foreign-chain state.Source: §1.1 · p. 2
  • Lane-scoped policies support native proofs, light clients, zero-knowledge proofs, threshold attestations, trusted-hardware attestations, and hybrid verification.XIM does not mandate one consensus algorithm or cross-chain proof mechanism.Source: §1.1 · p. 2, §1 · p. 2
  • XIM separates economic asset identity from chain-specific token addresses through UAID and provides pluggable adapters for chains, institutional networks, and authenticated legacy gateways.Source: §1.1 · p. 2
  • An optional policy-aware route graph supports multi-hop settlement using cost, latency, liquidity, security, privacy, jurisdiction, and finality, while independent risk monitoring can rate-limit or pause a compromised lane.Source: §1.1 · p. 2

1.2 Non-goals

  • XIM is not a general-purpose Layer-1, does not require global replication of connected-ledger transactions, and does not claim trustless interoperability without independently verifiable source evidence.It also does not define universal legal finality or require XDC as an intermediate asset or route hop.Source: §1.2 · p. 2

1.3 Conventions

  • The convention keywords MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY follow BCP 14 only when written in all capitals.H(·) denotes a collision-resistant hash function and ∥ denotes byte-string concatenation.Source: §1.3 · p. 2

2 Related Work and Design Context

XIM frames interoperability as authenticated messaging between independently governed networks, with lane-specific verification rather than a shared execution environment. Its model defines the networks, asset identities, canonical messages, and identifiers used at that boundary.

2 Related Work and Design Context

  • XIM distinguishes its canonical-message and state-transition boundary from API gateways, cross-chain messaging, light-client protocols, and institutional networks.Its related-work discussion draws concepts from these families while defining its own protocol boundary.Source: §2 · p. 3

3 System Model

  • Communication lanes connect independently governed networks and are identified by their endpoints, protocol and adapter versions, and verification policy.Deployments may include observers, verifiers, routers, executors, risk monitors, and gateways; roles may be combined while remaining logically distinct.Source: §3 · p. 3

3.1 Trust Domains

  • Each network retains responsibility for its own consensus and finality, while the destination controls execution; security claims are therefore lane-specific.The lane policy specifies evidence required for the destination to accept a source assertion.Source: §3.1 · p. 4

4.1 Network Identifier

  • NetworkID names a trust domain and should change when a fork or re-genesis materially changes that network’s security identity.The identifier must remain globally stable for a given trust domain.Source: §4.1 · p. 4

4.2 Universal Asset Identifier (UAID)

  • UAID identifies an economic asset independently of its ledger representation; it does not establish equivalence unless issuer and conversion policy do so.For example, native USDC representations may share an issuer-level identity, while a wrapped token should be classified distinctly unless redemption equivalence is verified.Source: §4.2 · p. 4

5 Canonical XIM Message

  • Canonical XIM messages use deterministic serialization and carry network, transaction, party, action, asset, amount, nonce, expiry, proof, and policy fields.The message schema also includes compliance, privacy, and route policy hashes.Source: §5 · p. 5

5.1 Message Identifier

  • A destination rejects a previously consumed message_id, providing replay protection independent of destination-chain nonce behavior.The domain separator binds the protocol name and major version.Source: §5.1 · p. 5

5.2 Action Types

  • The protocol defines action types for this version, as listed in Table 3.The supplied passage identifies the table’s scope but does not specify its individual action types.Source: §5.2 · p. 5

6 Message Lifecycle and State Machine

XIM models messages through ordered nominal states and exceptional terminal outcomes, while commitments summarize message state without requiring replication of foreign-chain data.

6 Message Lifecycle and State Machine

  • State transitions are monotonic unless an explicit compensating transaction creates a new message; XIM avoids treating irreversible cross-ledger execution as rollbackable.Figure 1 distinguishes the nominal lifecycle from exceptional terminal states, and Table 4 lists evidence required for nominal transitions.Source: §6 · pp. 5–6, Figure 1 · p. 6, Table 4 · p. 6

7 Commitment Structure

  • Commitment roots summarize message state without replicating complete foreign-chain data, using a message_id-keyed Sparse Merkle Tree as the baseline.Other authenticated dictionaries are allowed if they preserve equivalent inclusion, non-inclusion, and update-verification properties and identify their commitment type.Source: §7 · p. 6
  • Batch roots may be checkpointed to XDC or another coordination ledger; XDC offers a common audit and dispute anchor but is not required for every deployment.Source: §7 · p. 7

8 Append-only Transition Log

XIM records message-state transitions in an append-only log and makes verification a lane-specific security boundary. Adapters expose network operations but must preserve XIM field meanings.

8 Append-only Transition Log

  • Strictly increasing, contiguous sequence numbers support deterministic state reconstruction, institutional audit trails, incident analysis, and reconciliation.Sensitive source documents should remain off-chain and may be referenced by cryptographic commitments.Source: §8 · p. 7

9 Verification Framework

  • Each lane binds to a VerificationPolicy, and execution cannot rely solely on a Router’s assertion that a message exists.Policies should account for message value, and governance must specify policy upgrades and treatment of in-flight messages.Source: §9 · p. 7

10 Adapter Interface

  • Adapters expose network identification, observation, finality, proof, execution, and fee operations; mappings must be explicit, versioned, and testable.Changes to address interpretation, finality, or asset semantics require a new adapter version and should receive lane-governance approval.Source: §10 · p. 8

11 Routing

XIM’s optional routing layer selects among eligible lanes, while an optional intent layer describes outcomes without fixing a path. The design also addresses asset semantics, privacy, and legacy financial gateways.

11 Routing

  • Routing models networks and settlement domains as a directed graph, weighting eligible edges by normalized fee and latency plus risk.Edges failing hard requirements such as jurisdiction, privacy, verification strength, value limits, or deadlines are removed before optimization; destination verifiers independently enforce policy.Source: §11 · pp. 8–9

12 Intent Layer

  • An intent specifies a desired economic outcome without binding the requester to a network path, and may compile into one or more XIM messages.The optional intent layer does not change the underlying messages’ security validity.Source: §12 · p. 9

13 Stablecoin and Tokenized-Asset Semantics

  • For issuer-mediated asset movement, XIM prefers native burn/mint or equivalent issuance over lock-and-mint wrapping to avoid accumulating bridge custody risk.Verification may include issuer attestations; destination execution must enforce applicable transfer restrictions committed to by the compliance policy hash.Source: §13 · p. 9

14 Privacy Model

  • XIM can carry hashes for payload, compliance metadata, and privacy policy while encrypted or selectively disclosed data travels through authorized channels.Hashing low-entropy data alone does not provide privacy; sensitive metadata should be encrypted, salted where appropriate, or committed in a way that resists dictionary attacks.Source: §14 · p. 9

15 ISO 20022 and Legacy Financial Gateways

  • A gateway can map an ISO 20022 pacs.008 instruction to a payment intent while preserving a cryptographic reference to the original message.XIM can authenticate the gateway’s assertion but cannot independently prove facts held only in a bank’s private system unless the bank exposes verifiable evidence.Source: §15 · pp. 9–10, Figure 2 · p. 10

16 XDC Coordination and Settlement Role

XDC may provide coordination and settlement services for XIM, but messages need not transit through it. The section also outlines possible contract components and qualifies security and liveness claims by policy assumptions and system availability.

16 XDC Coordination and Settlement Role

  • XDC can serve as a checkpoint, coordination, fee, collateral, or settlement domain, without requiring every XIM message to transit through it.It may be used where its execution cost, finality, liquidity, and institutional integrations make it an efficient settlement domain.Source: §16 · p. 10

17 Reference Smart-Contract Interfaces

  • Potential XDC-native components include message, verifier, asset, and adapter registries, a router, and a risk manager.The reference message registry supports committing, verifying, settling, acknowledging, and querying message status.Source: §16 · p. 10, §17 · p. 10

18 Security Properties

  • XIM’s stated security properties are targets subject to the explicit assumptions of the selected lane verification policy.The cited table is described as an informal summary of target properties.Source: §18 · p. 10, Table 6 · p. 11

19 Threat Model

  • The threat model includes a summary of principal threats, mitigations, and residual limitations.For asset-moving lanes, uncertain finality, verifier availability, or risk status should lead XIM to halt or delay execution; liveness depends on source, verifier, destination, and governance availability.Source: §19 · p. 11, §19.1 · p. 11, Table 7 · p. 11

20 Atomicity and Multi-leg Settlement

XIM distinguishes settlement models because messaging alone does not ensure atomicity across unrelated systems. Its operational guidance covers risk controls, governance, and latency and throughput trade-offs.

20 Atomicity and Multi-leg Settlement

  • Across unrelated consensus systems, XIM distinguishes native atomic execution, conditional cross-domain settlement, and coordinated non-atomic settlement with compensating actions.Implementations must advertise the applicable model; XIM coordinates delivery-versus-payment but does not claim messaging alone eliminates principal risk.Source: §20 · p. 12

21 Risk Management and Circuit Breakers

  • Risk controls are lane-scoped and may include monitoring anomalies, emergency pauses for new executions, and stricter verification when thresholds are exceeded.Safe acknowledgement and refund paths may remain available during an emergency pause.Source: §21 · p. 12

22 Governance and Upgradeability

  • Governance controls verifier policies, adapter versions, asset entries, lane activation, limits, and emergency actions; historical messages must retain deterministic interpretation across protocol versions.Production deployments should use timelocks for non-emergency upgrades, multi-party authorization, transparent change records, and post-event review of emergency powers.Source: §22 · p. 12

23 Performance Model

  • End-to-end latency includes source finality, observation, proof generation and verification, routing, destination submission and finality, and acknowledgement.Threshold attestations may shorten proof generation but carry stronger trust assumptions; light-client or ZK lanes may reduce trust while increasing engineering complexity or proof latency.Source: §23 · p. 12
  • Batching k messages under one Merkle root amortizes checkpoint cost across those messages.Executors may batch destination submissions where destination semantics permit.Source: §23 · p. 13

24 Reference Node Architecture

The reference architecture separates durable, ephemeral, authenticated, and routing state, while XIM workflows carry verified instructions from source observation through destination execution and acknowledgement. The examples cover public-chain transfers, privacy-preserving institutional workflows, and ISO 20022 settlement.

24 Reference Node Architecture

  • The reference node can use separate stores for message metadata, caches, authenticated state, and routing, while the cryptographic commitment root—not the database engine—defines protocol state integrity.Figure 3 places the Risk Monitor as an observer of execution components independent of the Router.Source: §24 · p. 13, Figure 3 · p. 13

25.1 Ethereum to XDC Asset Transfer

  • An Ethereum-to-XDC transfer observes a source event after finality, creates a canonical message and required proof, then validates lane status and replay state before destination execution.The destination receipt is recorded as SETTLED, and an acknowledgement may be returned to the source application.Source: §25.1 · p. 13

25.2 Canton-connected Institutional Workflow

  • A Canton-connected adapter commits to an authorized event without publishing confidential transaction contents, using a cryptographic proof, participant or synchronizer attestation, or hybrid policy as available.The concrete adapter and proof policy must follow the deployed Canton integration’s capabilities and security model.Source: §25.2 · pp. 13–14

25.3 ISO 20022 to XDC Settlement

  • An authenticated gateway validates an ISO 20022 instruction, commits to its source-message hash, selects an eligible route, verifies gateway and HSM evidence, and maps settlement status back to the institution.The destination transaction identifier is bound to the XIM message; an eligible route may use native USDC on XDC or another approved rail.Source: §25.3 · p. 14

26 Formal Invariants

XIM specifies SHOULD-level invariants for execution, verification, commitments, lane authorization, event ordering, and asset mapping. The appendix also outlines a twelve-week implementation plan and a research roadmap for verification, assurance, adapters, routing, settlement, and commitments.

26 Formal Invariants

  • At-most-once destination execution and verification before execution are core SHOULD-level lifecycle invariants.The conditions require executed[d, m.message id] ≤1 and EXECUTING(m) ⇒ VERIFIED(m).Source: §26 · p. 14
  • Other invariants require accepted messages to match their deterministic commitment, execution to use an active lane policy, event sequences to increase monotonically, and transfers to use authorized destination assets.These are stated as commitment integrity, lane authorization, monotonic sequence, and asset-mapping conditions.Source: §26 · p. 14

27.1 Staged Minimum Viable Implementation

  • The twelve-week staged plan is for a minimum viable implementation, and its pilot is intended to produce a reproducible benchmark report rather than substantiate current performance or security claims.The paper says those claims are not yet backed by measurements from the implementation.Source: §27.1 · p. 14, Table 8 · p. 15

27.2 Research Roadmap

  • The roadmap proposes replacing or supplementing bootstrap attestations with light-client or ZK verification on high-value public-chain lanes.It also calls for formal lifecycle specification and formal verification of critical Solidity contracts.Source: §27.2 · p. 15
  • The roadmap calls for a Canton adapter feasibility study with an explicit privacy and proof model, plus an ISO 20022 gateway mapping and institutional HSM profile.Source: §27.2 · p. 15
  • Further research includes a multi-route liquidity and policy engine, cross-domain conditional settlement and delivery-versus-payment, and possible Verkle or alternative vector commitments if their characteristics justify migration from SMTs.Source: §27.2 · p. 15

28 Security Limitations

XIM makes trust assumptions explicit and modular but cannot make a compromised source ledger truthful, and multi-hop routes compound risk. The discussion positions XDC as optional, while the conclusion calls for implementation and measurement before production use.

28 Security Limitations

  • A correct light client can faithfully prove an invalid economic state finalized by a compromised source, while attestation gateways inherit signer and key-management risk.Adapter, verifier, destination-contract, and asset-issuer software risks also remain; XIM aims to make trust assumptions explicit, modular, measurable, and isolatable, not eliminate trust.Source: §28 · p. 15
  • A multi-hop route is no stronger than its weakest economically relevant edge unless additional end-to-end verification is used, so high-value routes SHOULD minimize trust-domain transitions.Source: §28 · p. 15

29 Discussion

  • XIM’s canonical authenticated-message boundary lets heterogeneous networks retain native consensus, privacy, governance, and execution models, with trusted and auditable gateways available to non-blockchain systems.Source: §29 · p. 15
  • XDC can provide optional coordination, checkpointing, and settlement without becoming a mandatory routing layer.Applications can use XDC when its settlement characteristics, infrastructure, or ecosystem integrations fit a workflow’s requirements.Source: §29 · p. 16

30 Conclusion

  • Throughput, latency, security, and operational-resilience claims require implementation-stage validation through reproducible benchmarks, adversarial testing, audits, and formal analysis before production use.Source: §30 · p. 16

A Proposed XIM Protobuf Skeleton

The protobuf skeleton specifies fields for a versioned XIM message, including network and transaction identifiers, asset and amount, proof, and policy metadata. The accompanying API sketch and test-vector list describe interfaces and conformance checks.

A Proposed XIM Protobuf Skeleton

  • The protobuf skeleton assigns versioned fields to source and destination identifiers, sender and receiver, action and asset data, payload hash, nonce, expiry, proof, and policy metadata.Source: A Proposed XIM Protobuf Skeleton · p. 18

B API Sketch

  • The API sketch includes a transfer-intent example with source and destination assets, amount, beneficiary, fee, deadline, and verification class, plus endpoints for messages, routes, proofs, and assets.Source: B API Sketch · p. 18

C Test Vector Requirements

  • Conformance test vectors should cover canonical encodings and message IDs, Merkle proofs, replay rejection, policy upgrades, source reorganization and finality, verifier disagreement, lane pauses, and execution failure or compensation.The list also includes cross-language SDK conformance tests.Source: C Test Vector Requirements · pp. 18–19
  • The test-vector scope also includes source reorganization and finality, verifier disagreement and lane pauses, destination execution failure and compensation, and cross-language SDK conformance.Source: C Test Vector Requirements · p. 19
Loading 2609.39310v1…