Cross-Chain Execution

Overview

Cross-chain execution turns information from another network into state changes on the destination. A protocol may verify a message, source proof, solver commitment, or validator attestation, then submit a transaction that transfers tokens or calls application contracts. Execution is separate from message delivery. The destination transaction needs valid gas, contract permissions, current state, and successful function logic. Price movement or competing transactions can make a once-valid instruction revert or produce a different permitted outcome.

Applications should define execution bounds, deadlines, slippage, authorized targets, and retry semantics. Monitoring must capture destination receipts and events. Payment systems should recognize value only after the exact expected action executes and reaches the required destination finality. Paused contracts, depleted liquidity, delayed proofs, or destination failure should enter review rather than being reported as a completed cross-chain payment. Reliable operation requires separate status for every stage, timeout and replay protection, route-specific monitoring, and a documented recovery path.

The workflow should be modeled 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.

Relevant assumptions include the validator or signer set, multisignature policy, light-client or proof design, relayers, upgrade authority, rate limits, and liquidity providers. Being described as official does not eliminate the underlying trust and control assumptions. The security model depends on the exact verification route. Implementation note: Cross-chain execution completes only when the authenticated instruction produces the expected finalized destination-state change.