A cross-chain swap is pending: check both chains and the route

A pending cross-chain swap means the route has not yet reported its final outcome; it does not, by itself, show whether funds are still on the source chain or already committed to a message or destination step. Start with the source transaction hash and identify its on-chain status. Then check the route’s own tracker and the destination chain for the expected output or a refund. These are separate state transitions, and an app may compress them into one label.

What does pending mean for a cross-chain swap?

Pending describes the route’s reported progress, not a universal protocol state. The source transaction can still be in a mempool, included in a block, or finalized while the cross-chain message remains unprocessed. After that, a relayer, solver or destination contract may still need to complete its part. The names and guarantees vary by route.

Check the source transaction in the source chain’s explorer. Confirm that the hash matches the transaction you signed, that it was included, and whether execution succeeded or reverted. A wallet’s “submitted” message only confirms that it broadcast a transaction; it does not prove inclusion. On chains with probabilistic finality, inclusion can still be followed by a reorganization. On chains with protocol finality, a finalized block has a stronger settlement guarantee, but that does not mean the destination action has run.

A route tracker can clarify what is waiting after source execution. For example, Mayan’s swap SDK documents a tracker keyed by the source transaction hash and status values for in-progress, completed and refunded swaps. A mayan bridge overview explains the broader sequence when the tracker’s status alone does not show which step remains. Treat status labels as the route’s summary, then verify the relevant transaction or message on-chain.

Which records should you check first?

Check the source transaction, the route tracker and the destination chain in that order. This narrows the problem without assuming that one explorer can see the whole route.

• Source transaction: Verify the chain, hash, sender, token, amount, and target contract or program. Check whether execution succeeded and whether the transaction emitted or created the route’s expected deposit or message.
• Route identifier: Use the transaction hash or order identifier expected by the route’s official tracker. Confirm that it identifies the same swap, recipient, destination chain and output asset. An unrelated wallet address or token ticker is not enough to establish a match.
• Message or fulfillment: If the source step succeeded, look for the route’s message, attestation, solver fill or equivalent record, where the design exposes one. A source-chain success proves only that the source contract executed; it does not prove a destination transfer.
• Destination transaction: Search the specified recipient address and token contract on the destination chain. Confirm the actual token balance change or successful transaction. A displayed token name alone may be ambiguous because different assets can share a ticker.

For a smart-contract route, inspect the emitted events and the contract’s state rather than relying only on a wallet notification. For a solver-based route, distinguish the user’s source deposit from a solver’s destination fill; some systems pay the recipient before completing settlement between intermediaries. That can make the user-visible leg complete while a protocol-level settlement step remains outstanding. The route’s own documentation determines which record represents delivery to the user.

When is a retry safe?

Retry only after establishing that the first attempt cannot still produce the intended destination payment. A pending status is not that evidence. If the source transaction is still unconfirmed, replacing or resubmitting it can create a second attempt. If it succeeded and the route is waiting on message processing or fulfillment, a second swap can spend the input again while the first remains live.

A failed source transaction usually means its state changes were reverted, though network fees may still have been charged. A successful source transaction is different: the tokens may have been transferred into a contract or locked for the route even if delivery is delayed. In that case, look for the route’s documented refund or recovery path. Do not send a “recovery” transaction to an address supplied in an unsolicited message, and do not share a seed phrase or sign an unrelated approval to clear a pending status.

Some routes have timeouts, refund procedures or retry functions; others rely on relayers or solvers to resume processing. Those mechanisms are protocol-specific. Before invoking one, verify the exact contract or program, the transaction it references, the destination address, and the effect of the call. A timeout may only make a refund eligible; it may not return funds automatically. Likewise, refreshing a page or reconnecting a wallet cannot advance an on-chain step that has not occurred.

What should count as completion?

Count the swap as complete when the route reports completion and the destination chain confirms delivery to the intended recipient in the expected asset. The source transaction alone is not sufficient, and a route dashboard alone is not independent confirmation. If the destination transaction reverted, check whether the route specifies a refund or another terminal state before taking action.

Keep the source hash, route or order identifier, destination chain and recipient address together when seeking support. Share only public transaction data. If the route tracker and destination explorer disagree, preserve the records and check the route’s documented status semantics; an indexer can lag behind chain state.

Confirmed means the source transaction’s outcome is visible on its chain, and any claimed destination delivery is visible in the destination’s state. Unverified means the route tracker has not exposed the intermediate step, or the destination balance and transaction do not yet confirm delivery. Until that distinction is clear, “pending” is a status to investigate, not a reason to submit the swap again.