Protocol thesis
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.
Core concepts
Together they let independent ledgers and institutional networks exchange value and instructions without sharing a single consensus system.
A deterministic interledger envelope independent of source-chain transaction formats, with domain-separated message IDs for replay resistance.
Supports native proofs, light clients, zero-knowledge proofs, threshold attestations, TEE attestations, and hybrid verification.
Message hashes, sparse Merkle roots, and append-only transition logs provide auditability without global replication of foreign-chain state.
UAID separates economic asset identity from chain-specific contract addresses and representation risk.
Routes are constrained by jurisdiction, asset support, privacy, verification strength, value limits, liquidity, deadline, and finality.
Lane-scoped monitors can rate-limit, pause, or downgrade compromised lanes without globally halting unrelated routes.
Reference architecture
Detect finalized source events and construct candidate XIM messages.
Map authenticated financial instructions and APIs into XIM semantics.
Evaluate source evidence against the lane verification policy.
Select eligible direct or multi-hop settlement paths.
Submit verified destination actions and record receipts.
Detect anomalies and apply lane-scoped circuit breakers.
Illustrative workflows
From public chains to private institutional ledgers and ISO 20022 payment instructions, each workflow keeps verification explicit end to end.
An adapter observes source finality, builds proof evidence, commits the message, verifies on XDC, executes settlement, and emits an acknowledgement.
Authorized gateways commit to private institutional events while preserving selective disclosure and avoiding public replication of confidential transaction data.
A gateway authenticates financial instructions, creates a settlement intent, verifies HSM-backed evidence, executes destination settlement, and returns reconciliation output.
Security posture
Every lane declares how its messages are verified, so risk can be assessed and contained lane by lane.
Destination acceptance requires source evidence satisfying the selected lane policy.
Consumed message IDs cannot execute twice on the same destination security domain.
A compromised or anomalous lane can be paused without globally halting unrelated lanes.
State transitions are reconstructible from authenticated commitments and event records.
Where it applies
Implementation roadmap
XIM is a research preview. The next stage is implementation, public test vectors, reproducible benchmarks, adversarial testing, audits, and formal analysis before production use.
XIM v0.1 schema, NetworkID/UAID format, state machine, lane policy model, and test vectors.
MessageRegistry, VerifierRegistry, RiskManager, replay protection, and event model.
XDC and Ethereum observers/executors, deterministic encoding, and threshold-attestation bootstrap.
SMT library, batch roots, TypeScript/Go SDKs, and REST/gRPC API.
Rate limits, lane pause, key rotation, monitoring, chaos/failure tests.
Ethereum–XDC testnet message transfer, asset-transfer demonstration, and benchmark report.
FAQ
By Atul Khekade, Ritesh Kakkad, Wanwiset Peerapatanapokin and Behnam Mohammadkhani, XDC Network Research & Engineering.
Content adapted from the XIM protocol site.