Cross-Chain Contract

Overview

A cross-chain contract integrates with interoperability infrastructure to coordinate state beyond its local network. Source contracts may lock assets or emit instructions, while destination contracts authenticate messages and execute application logic through an approved router, gateway, or verifier.

Contract state is local even when the application appears unified. Address formats, deployed code, upgrades, roles, and token representations can differ by chain. A compromised remote contract or messaging endpoint can affect the local contract if authorization is too broad. Developers should allowlist source domains and senders, validate message schemas, enforce nonces and idempotency, cap value, and provide pause and recovery controls. Audits must cover every deployment and the protocol connecting them, not one contract in isolation.

Paused contracts, depleted liquidity, delayed proofs, or destination failure should enter review rather than being reported as a completed cross-chain payment. Production support needs separate status for every stage, timeout and replay protection, route-specific monitoring, and a documented recovery path. The process should be represented as a multi-stage operation: source authorization, source inclusion and finality, message or proof production, relay, destination verification, destination execution, and destination finality. Completion of an early stage does not prove that value or instructions reached the destination.

Security depends on the exact verification route. Review should identify every dependency, including signers, validators, proof verification, relayers, administrative keys, liquidity providers, and emergency limits. Official status alone does not reduce the technical, governance, or liquidity dependencies involved. Settlement consideration: Cross-chain contracts coordinate local state through authenticated remote messages, requiring strict domain, sender, replay, and value controls.