How Message Passing Coordinates Cross-Chain Actions

Message passing coordinates a cross-network action by carrying a verified instruction from a contract on one chain to a contract on another, where the destination contract executes it.

The first attempt usually goes wrong at the handoff: the transaction succeeds on the source chain, but nothing appears to happen on the destination. That is because the source transaction does not call the other network directly. It publishes a message, waits for that message to become trustworthy, and depends on a separate delivery transaction to finish the job.

What actually crosses the networks

What crosses networks is an authenticated payload, not a live function call and not necessarily the asset itself. A typical message contains the source chain, the sending contract, the destination chain and contract, a nonce or sequence number, and instructions encoded as bytes.

Suppose a contract on Polygon Network records that a user deposited tokens and wants an action completed on Arbitrum One. The flow is usually:

1. The user submits a source-chain transaction, often approving tokens and calling an application or bridge contract.
2. The source contract emits a message through the interoperability protocol’s core contract.
3. Observers verify the source event and create a signed attestation after the chosen level of source-chain finality.
4. A relayer obtains that attestation and submits it to the destination chain.
5. The destination contract verifies the attestation, rejects a message already processed, decodes the payload, and performs the requested action.

Wormhole makes this concrete with a Verified Action Approval, or VAA. Its payload is accompanied by guardian signatures and identified by details such as the emitter chain, emitter address, and sequence number. The relayer transports that proof, but it does not get to rewrite the instruction. It can affect delivery time; the destination contract decides whether the proof and its contents are valid.

That distinction is the useful mental model: transport is separate from verification, and verification is separate from execution. A receiving contract should check the trusted source emitter and destination, verify the signatures, enforce replay protection, and only then call its application logic. If any of those checks are missing, a forged or duplicated message could trigger the same action twice.

How a message becomes a useful action

A message becomes useful when its payload describes a state change that the destination contract knows how to perform. It might say “release these tokens to this recipient,” “update this governance setting,” or “call this function with these arguments.” The message-passing layer carries the instruction; the application contract supplies the meaning.

Token movement is a good example because it exposes a common misunderstanding. In a lock-and-mint design, the source tokens are held in escrow and the destination contract mints a representation after receiving valid proof. In a burn-and-mint or burn-and-unlock design, the source supply is destroyed and the destination side releases or creates the corresponding amount. The message coordinates that accounting. It does not make an arbitrary token balance appear by itself.

The same message can coordinate a multi-step experience. A source transaction can deposit an asset, and the destination payload can instruct a contract to deliver it to a swap, lending, or staking position. If the call reaches a Uniswap Protocol deployment on Arbitrum One, for example, the destination contract still has to enforce the swap parameters, recipient, deadline, and minimum output. Cross-chain messaging gets the instruction there; it does not remove ordinary application-level slippage or authorization checks.

This is also where the route layer matters. If Paraswap is involved before or after the handoff, keep the asset movement separate from the message that tells the destination what to do. The next thing to inspect is the route and execution path.

The part that is not atomic

Cross-network execution is asynchronous, so “the message was sent” and “the action completed” are different states. The source transaction can finalize while the destination transaction waits for signatures, a relayer, destination gas, or a retry after a failed call.

This creates several practical checks. First, a protocol must decide how much source finality it needs before accepting a message; acting too early increases exposure to a source-chain reorganization. Second, the destination must record a message as consumed using a durable identifier such as source chain, emitter, and sequence, so repeated delivery attempts do not repeat the action. Third, a failed destination call needs an explicit recovery path. Some systems allow a message to be retried; none can roll back a source transaction simply because the destination ran out of gas.

For the user, this means the final status is the destination execution transaction, not merely the source-chain receipt. A bridge interface that shows “submitted” may only have completed the first half.

Where message passing fits

Message passing fits when the destination must respond to a specific fact or instruction from the source chain. It is especially useful for governance, cross-chain account state, token issuance, and workflows where bridging and a destination action should appear as one user journey.

The main alternative is a liquidity or intent-based route. That route can be faster when the desired result is simply receiving an asset on another chain: a solver or market maker fronts liquidity and later settles the source-side claim. The trade-off is that the user is pricing an exchange of obligations, with fees, spread, limits, and counterparty or settlement assumptions.

Message passing is the better fit when correctness means “execute this authenticated source instruction.” A liquidity route is often the better fit when correctness means “give me this destination asset quickly.” Neither removes network fees or execution risk. The decisive question is whether the destination needs a verified message, or only a balance.