Skip to the article
Tokenbearing

Crypto protocols, markets and policy

A Cross-Chain Swap Can Stay Pending After Source Confirmation

A cross-chain swap can remain pending after the source transaction lands because bridge execution, destination swaps and status reporting run as separate steps.

Tokenbearing Editorial5 min read#99d49e

A Cross-Chain Swap Can Stay Pending After Source Confirmation

A cross-chain swap can stay pending after its source transaction confirms because confirmation on one chain does not complete the work on another. The source transaction may deposit or lock the input asset, while a bridge, relayer or coordinated sequence still has to deliver value on the destination chain. Until that process reports a terminal result, the swap is in flight.

The label “pending” can describe different points in that sequence. Before source inclusion, the transaction is waiting for its own chain. After inclusion, it may be waiting for the bridge provider to accept the deposit, satisfy its finality rules, execute a destination transaction or report the result to the interface. The exact stages and labels vary by route. For context on how a QuickSwap route fits into an integrator’s model, see how QuickSwap models cross-chain legs. That route detail matters because a cross-chain “swap” can be several dependent operations under one user request.

What does pending mean after the source transaction confirms?

It means the source transaction has landed, but the destination outcome has not yet been confirmed. A source-chain receipt proves that the source transaction was included and executed there. It does not prove that the destination chain received the assets or completed any swap there.

For a liquidity-based route, a relayer may observe the source deposit and fulfill the request by sending its own funds on the destination chain. The protocol then verifies the fill and repays the relayer later. User delivery and protocol settlement are separate milestones: the user may have received the destination asset before the relayer’s repayment is settled.

Other bridge designs relay a message or proof after source-chain finality, then execute a destination contract call. That path can remain pending while the bridge waits for its own finality threshold, message verification or destination-chain execution. A user interface may group several of these states under one word.

Which step can keep a cross-chain swap in flight?

The route’s active step determines what is still outstanding. A swap may require an approval, a source-chain token swap, a bridge transfer and a destination-chain swap. Later steps depend on the confirmed output of earlier ones, so the route cannot safely advance just because one transaction was submitted.

Common reasons for a nonterminal status include:

  • The source transaction is still waiting for inclusion, or it reverted before the deposit took effect.
  • The bridge is waiting for source-chain finality or has not yet processed the deposit.
  • A relayer has not filled the request, or a destination transaction is awaiting execution or confirmation.
  • The destination transfer completed, but the status service or wallet has not yet observed and displayed that result.

These are different conditions with different remedies. A reverted source transaction may leave the input in the sender’s wallet. A bridge failure may trigger a retry or refund process. A completed destination transfer can still appear pending if the application’s status view has not updated. “Pending” alone does not identify which condition applies.

How can you tell whether the swap completed?

Check the source transaction and the route’s destination status separately. First confirm the source transaction on its own chain’s explorer. If it reverted, the intended deposit did not complete. If it succeeded, look for the bridge or swap provider’s status, destination transaction hash and final recipient amount.

For API-based routes, use the provider’s status endpoint or transaction tracker with the source transaction hash and any route identifier the quote returned. Some trackers distinguish source pending, source confirmed, bridge pending, bridge filled and bridge failed. They may skip intermediate states between polls, so the absence of a particular status does not prove that its step never occurred. A destination transaction hash can also represent a retry or recovery action rather than final delivery.

Only a terminal success state, supported by destination-chain evidence, confirms delivery. Check that the destination transaction succeeded and that the intended recipient received the asset. The settled amount can differ from the quote when the route permits slippage. A source-chain success alone is not proof that the full swap finished.

What should you do while it is pending?

Use the route’s status record to identify the active step, then wait or follow that provider’s recovery path. Avoid submitting the same swap again just because the interface has not advanced: the original route may still fill, creating a second transaction rather than accelerating the first. If the source transaction failed, verify the wallet balance before retrying. If the bridge reports failure, check whether a retry or refund is still in progress.

The useful distinction is between source confirmation, destination delivery and protocol settlement. A cross-chain swap is complete for the user when the destination asset is delivered to the intended recipient and the route reports that result. Any later accounting between relayers and pools belongs to the protocol’s settlement process.