Cross-Chain Transaction

Overview

A cross-chain transaction begins with an action on a source chain and completes through one or more actions on a destination chain. A bridge may lock or burn an asset, verify the source event, and mint or release a corresponding asset elsewhere. A messaging protocol may transmit data that causes a destination contract to execute. Each chain records its own transaction and reaches consensus under its own rules.

Because the chains do not share one native state machine, the workflow is rarely atomic in the strict sense. The source step can succeed while the relay is Delayed Finality, the destination transaction fails, liquidity is unavailable, or verification pauses. Some systems use trusted signers, some use light-client proofs, and others use optimistic challenge periods. The term should therefore be accompanied by the specific bridge or interoperability security model.

Finality mismatch is central. A destination action should not rely on a source event with weaker assurance than the bridge assumes. Cross-Chain Confirmation Normalization can translate different chain states into an operational policy, but it cannot erase the underlying risk. Reorganizations, delayed finality, validator compromise, and message replay must be handled explicitly. Faster completion often means accepting additional trust or liquidity-provider exposure.

Payment systems should track a cross-chain workflow by a shared transfer identifier plus every chain-specific transaction ID, asset representation, amount, fee, status, and timeout. They need states such as source submitted, source confirmed, message verified, destination executed, refunded, or manually recoverable. A successful source transaction is not completed settlement. Reconciliation should confirm the correct destination asset and recipient and account for wrapped assets, slippage, bridge fees, and failed delivery.