4 · Cross-Chain Model
Most cross-chain designs fail by treating all interaction as one kind of traffic. XChain draws a hard line between READ (no state change) and WRITE (state change) — one primitive distinction that the entire model hangs on. Most cross-chain needs are just verifying that "X happened on chain A" — a READ, over Interchain Queries (ICQ) — which is cheap and effectively unlimited. Only atomic state change is a WRITE, over IBC v2/Eureka + Interchain Accounts (ICA), and it is deliberately kept scarce.
Why a READ is nearly free
The asymmetry is not a fee schedule; it comes from what each operation has to do. A READ verifies an inclusion proof against a root the querying chain already tracks — the same root the Settlement Layer maintains through PAI. Nothing new has to be agreed on, no consensus round is opened, and no state is touched. The work is one proof verification, and that cost does not grow with the size of the state being read: proving that one event out of a billion is in a log costs the same as proving it out of a thousand.
Two hard rules make this safe rather than merely cheap. A READ MUST NOT change state, and a READ MUST be idempotent — so a retry is harmless, a duplicated query changes nothing, and a relayer replaying an old query cannot cause damage. That is precisely why the READ budget can be left effectively unbounded: an operation that cannot alter anything cannot be abused into altering something.
| Type | Mechanism | Cost | Budget |
|---|---|---|---|
| READ | ICQ — verify a proof against an existing root | Cheap (one verify) | Effectively unlimited |
| WRITE within a Cell | Shared sequencer (atomic inclusion) | Low | Most stateful traffic |
| WRITE across Zone/Region | XMP + ZK light client + pessimistic proof | High, async | < 0.1% |
| Global atomic WRITE | Settlement Layer (Tier T0) only; intent/solver underwrite | Very high | < 0.01% |
What a WRITE actually costs
A WRITE is scarce because it is genuinely expensive, and the price buys a specific set of checks. Its lifecycle is fixed: SendPacket → the message is written into the Outbound Message Merkle Tree → a relayer carries it with its proof → RecvPacket verifies the proof and the anti-replay nonce → the message executes → Ack or Timeout. Nothing here trusts the relayer: it carries bytes, and if it lies, corrupts or drops a message, the proof check fails or the timeout path fires. A relayer can delay a WRITE; it cannot forge one.
Three obligations are specified as MUST, which is what keeps the model from drifting as chains are added:
- The nonce MUST increase monotonically per (source, destination) pair — this is what makes replay structurally impossible rather than merely unlikely.
- Any WRITE that moves an asset MUST call
**UAC.checkPlacement**— so the 2-Domain boundary is re-checked on every transfer, not just at issuance. - Cross-region WRITEs MUST carry pessimistic-proof accounting — the mechanism that turns a remote failure into a bounded loss.
The reference data path — recording a "like" and proving it cross-chain without re-execution:
Figure 4 — The reference data path: append, anchor, and prove inclusion cross-chain.
What breaks, and what still holds
Cross-chain systems are judged by their failure modes, not their happy path, so here are the ones that matter — including the guarantee XChain deliberately does not make:
| What goes wrong | What happens | What still holds |
|---|---|---|
| The relayer goes offline or censors | The WRITE is delayed; eventually Timeout fires | No partial application: the message either executes with a valid proof or times out. Anyone can run a relayer, so censorship is a liveness problem, not a safety one |
| A message is replayed | RecvPacket rejects it on the nonce | The monotonic per-pair nonce makes replay impossible, not improbable |
| A chain is compromised and tries to withdraw more than it deposited | The pessimistic proof refuses the excess | Damage is contained to that chain's own share — this is exactly what acceptance criterion MVC-3 exercises against a simulated faulty chain (Run a Node) |
| Someone tries to move a high-value asset into the data Domain | UAC.checkPlacement rejects the WRITE | The Domain boundary is enforced on every transfer, not only at issuance |
| A cross-region WRITE half-completes | Not prevented. Atomicity across independent consensus zones has no trustless construction | Containment and economic underwriting bound the loss. This is stated as an unsolved problem, not papered over — see Open Problems |
The last row is the honest edge of this design. XChain does not claim global atomicity, because nobody has a trustless construction for it; what it claims is that a failure stays inside the region where it happened, and that the size of the loss is known in advance rather than discovered afterwards.
Takeaway: a separate chain proves the "like" happened with a single proof check — no stateful message, no re-execution. Cross-region atomic WRITEs are not promised to be all-or-nothing at the protocol layer; they achieve containment through pessimistic proofs and economic underwriting. A near-free read path is only safe, however, if value can never leak across the boundary it reads over — which is a security question, answered next.