What “Pending” Means in a Cross-Chain Swap

A pending cross-chain swap means the source transaction has not yet produced a completed destination transfer. The label can cover several different steps: a source-chain confirmation delay, protocol processing, or a destination-chain transaction waiting to be signed or confirmed. It is a status shown by a wallet or tracker, not a universal protocol state. To understand what is happening, identify which chain has the funds and which transaction is still outstanding.

THORChain offers one example of the mechanics. Its Bifrost chain clients observe transactions on connected chains, then report them to THORChain, where the state machine processes valid deposits. A swap between two non-RUNE assets uses liquidity pools linked through RUNE internally; the user sends one asset and receives the other. The linked thor swap explainer goes deeper into routing and verification. For a pending swap, the key distinction is whether the source deposit has been observed, the swap has been processed, or the outbound transaction has been broadcast.

Why does a cross-chain swap stay pending?

A swap stays pending while a required step has not reached the protocol’s acceptance condition. The source-chain transaction may still be unconfirmed, or the protocol may be waiting for enough confirmations before treating the deposit as valid. Confirmation requirements vary by chain and can depend on the deposit. A reorganisation can also undo a transaction that looked confirmed in a wallet, so protocols wait before acting on some deposits.

After the deposit is accepted, protocol processing and destination delivery are separate steps. In THORChain, the state machine executes a valid swap against its pools and creates an outbound transaction. Network nodes must sign that transaction through the protocol’s vault system before it can be broadcast on the destination chain. That outbound may then need confirmations of its own before the receiving wallet or tracker shows completion.

Some swaps also execute in stages. THORChain streaming swaps divide a deposit into smaller sub-swaps at intervals, aiming to reduce price impact on each part. The remaining amount can therefore be pending even though part of the swap has already executed. A destination chain with congestion, a protocol signing delay, or outbound transaction throttling can add time after the swap itself has run.

How can you tell which step is waiting?

Check the source transaction first, then look for protocol and destination records. Use the transaction hash from the wallet to open the source-chain explorer, and confirm that the transaction is successful and sent to the intended protocol address. A wallet’s “submitted” label alone does not show that the protocol has observed or accepted the deposit.

Then check the protocol’s swap tracker, if available. Compare the input asset, amount, destination address, and any memo or route details against the transaction you sent. The status wording varies by interface, but the evidence to look for is consistent:

• Source transaction: Confirm it succeeded on the chain where you sent funds.
• Protocol observation: Check whether the protocol recorded the inbound transaction and accepted it for processing.
• Swap execution: Look for an execution record, including whether a streaming swap has remaining sub-swaps.
• Destination transaction: Find the outbound hash and check its status on the receiving chain.

If the tracker shows an outbound hash, use that hash on the destination-chain explorer. A broadcast transaction can still be awaiting confirmation there. If no outbound hash exists, the delay is earlier in the process, or the protocol has not yet released the destination transfer. These checks locate the wait; they do not guarantee when the next step will happen.

What can cause a swap to fail or return funds?

A failed swap can result from an invalid deposit, a missing or incorrect routing memo, an unavailable market, or a price limit that the swap cannot meet. The exact handling depends on the protocol. In THORChain, a swap with a minimum-output limit can return all or part of the inbound amount if its sub-swaps cannot meet that limit. A refund is itself an outbound transaction, so it may take time and incur destination-chain costs.

Do not send a second deposit just because the first still says pending. If both deposits are accepted, both may execute. First verify the source transaction, tracker record, and any protocol-documented recovery path. Be especially careful with destination addresses: a protocol can only send to the address specified in the swap, and an incorrect address may not be recoverable.

When should you treat a pending swap as complete?

Treat it as complete when the destination-chain transaction has succeeded and the output is visible at the intended address. A protocol execution record means the swap logic ran; it does not by itself prove that the destination chain accepted the transfer. Likewise, a source transaction confirmation proves only that the input was recorded on its chain.

For beginners, the most useful mental model is a sequence of independently verifiable events: source deposit, protocol acceptance, swap execution, outbound signing and broadcast, then destination confirmation. A pending label tells you that the interface has not marked the whole sequence complete. The transaction hashes and tracker records tell you which step remains; until the destination transfer succeeds, the swap is not settled from the recipient’s point of view.