Three checks before canceling an omnichain request

Before canceling an omnichain request, check its on-chain status, whether destination execution has begun, and what the route charges or refunds. A request can move through separate source-chain, verification and destination-chain steps, so a wallet’s “pending” label may not tell you whether the message can still be stopped.

Has the request left the source chain?

Check the source-chain transaction in a block explorer and confirm whether it is pending, confirmed or failed. Before confirmation, replacing or dropping a transaction may still be possible through the wallet or network; after confirmation, the request has been recorded and the route’s own rules determine what can happen next.

Save the transaction hash, destination chain, recipient and request or message identifier before taking action. These details help distinguish a transaction that never started from one waiting for a relayer or destination execution, and they are useful when checking the route’s status page or support guidance.

Has the message been verified or executed?

Check the message’s stage on the destination chain before treating a cancel button as a reversal. LayerZero’s documentation separates verification from execution: a verified message may still be waiting for the receiving application to run, while recovery actions such as skipping or clearing are protocol operations with specific permissions and effects.

A status tracker can show whether a transfer is pending, filled or expired, as Across’s deposit documentation describes. For a broader explanation of the checks involved, see this guide to omnichain requests. If destination execution is complete, a later source-chain cancellation cannot by itself undo the destination action; the application may need a separate transaction to reverse it.

What will cancellation cost, and what happens to the funds?

Read the route’s cancellation or recovery instructions and check the fee shown for the exact action. A retry, timeout, refund claim and message skip are different operations: one may attempt delivery again, another may return eligible funds, and a skip may advance message handling without executing the original request.

• Confirm which wallet or contract is authorized to cancel, skip or claim a refund.
• Check whether the route charges a new transaction fee and which chain requires it.
• Find the stated expiry or refund condition, and verify that the request meets it.

Across’s documentation, for example, says a deposit becomes eligible for a refund after its fill deadline passes without a fill, subject to its stated conditions. That is an expiry path, not an instant recall; other routes can use different deadlines and recovery rules.

When is waiting the better choice?

Wait when the source transaction is confirmed, the route still reports a live request, and its documented timeout has not passed. Repeatedly submitting retries or recovery transactions can add fees and complicate diagnosis, especially when the original message may still execute.

The practical rule is to act on the request’s current stage, not the wallet’s generic pending label: confirm where it is, determine whether execution has occurred, then use the route’s documented recovery path. The next step depends on that route’s status and permissions; until those are checked, whether the request can be stopped or refunded remains unconfirmed.