Canonical messages
A deterministic interledger envelope independent of source-chain transaction formats, with domain-separated message IDs for replay resistance.
September 2026 · XDC Network Research & Engineering
The XDC Interledger Messaging Protocol
A verification-agnostic messaging and settlement fabric for heterogeneous ledgers, institutional networks, and financial rails.
CREATEDSOURCE_FINALVERIFIEDSETTLED
commitment_root
0x0e5f4b7c9d2a3f1e8b6c4a91…
Designed for public blockchains, permissioned ledgers, institutional networks, stablecoins, tokenized assets, trade finance, and ISO 20022-compatible payment workflows.
Protocol thesis
Interoperability as authenticated message exchange.
XIM does not force every connected network into a single consensus system. Instead, it defines canonical messages, deterministic identifiers, cryptographic commitments, replay protection, verification policies, execution semantics, and acknowledgements between independently governed trust domains.
Each source–destination lane selects an explicit verification policy appropriate to the value, finality, privacy, and trust characteristics of that lane.
Lane-scoped verification
Supports native proofs, light clients, zero-knowledge proofs, threshold attestations, TEE attestations, and hybrid verification.
Commitment-oriented state
Message hashes, sparse Merkle roots, and append-only transition logs provide auditability without global replication of foreign-chain state.
Universal asset identity
UAID separates economic asset identity from chain-specific contract addresses and representation risk.
Policy-aware routing
Routes are constrained by jurisdiction, asset support, privacy, verification strength, value limits, liquidity, deadline, and finality.
Independent risk controls
Lane-scoped monitors can rate-limit, pause, or downgrade compromised lanes without globally halting unrelated routes.
Reference architecture
Separation of routing, verification, execution, settlement, and risk.
Illustrative workflows
Built for cross-domain financial movement.
Ethereum → XDC transfer
An adapter observes source finality, builds proof evidence, commits the message, verifies on XDC, executes settlement, and emits an acknowledgement.
Canton-connected institutions
Authorized gateways commit to private institutional events while preserving selective disclosure and avoiding public replication of confidential transaction data.
ISO 20022 → XDC settlement
A gateway authenticates financial instructions, creates a settlement intent, verifies HSM-backed evidence, executes destination settlement, and returns reconciliation output.
Security posture
XIM does not eliminate trust. It makes trust explicit, modular, measurable, and isolatable.
Authenticity
Destination acceptance requires source evidence satisfying the selected lane policy.
Replay resistance
Consumed message IDs cannot execute twice on the same destination security domain.
Lane isolation
A compromised or anomalous lane can be paused without globally halting unrelated lanes.
Auditability
State transitions are reconstructible from authenticated commitments and event records.
Implementation roadmap
Twelve-week staged minimum viable implementation.
Weeks 1–2Protocol freeze
XIM v0.1 schema, NetworkID/UAID format, state machine, lane policy model, and test vectors.
Weeks 2–5XDC contracts
MessageRegistry, VerifierRegistry, RiskManager, replay protection, and event model.
Weeks 3–7First adapters
XDC and Ethereum observers/executors, deterministic encoding, and threshold-attestation bootstrap.
Weeks 5–8Commitments & SDK
SMT library, batch roots, TypeScript/Go SDKs, and REST/gRPC API.
Weeks 7–10Security & operations
Rate limits, lane pause, key rotation, monitoring, chaos/failure tests.
Weeks 10–12Pilot
Ethereum↔XDC testnet message transfer, asset-transfer demonstration, and benchmark report.
Research preview
Read the paper and help validate the next phase of XIM.
The next stage is implementation, public test vectors, reproducible benchmarks, adversarial testing, audits, and formal analysis before production use.