A cross-chain swap can remain pending after its source transaction confirms because confirmation only proves that the source chain accepted the deposit. The decisive condition is whether the swap service has observed enough confirmations to safely process it; after that, routing, swap execution and a separate destination transaction still have to complete.
What does “confirmed” prove?
A confirmed source transaction records the deposit on its own blockchain; it does not prove that the next chain has received anything. A cross-chain service must detect the deposit, verify its destination instructions and decide that the source transaction is unlikely to be reversed before it acts.
For a thor swap service, that changes the task from manually arranging each leg to monitoring one cross-chain route. The route still depends on source-chain confirmation rules and destination-chain execution, so a wallet’s “confirmed” label may precede the service’s “processing” state.
Confirmation thresholds vary by chain and by the value at risk. Bitcoin blocks average about 10 minutes, but the Bitcoin Developer Guide describes six confirmations as a common conservative threshold for accepting payments; some services use fewer for smaller or faster flows. On Ethereum, a transaction can be included in a block well before that block is finalized, as ethereum.org explains. A status tracker may therefore be waiting for a service-specific threshold, rather than stuck.
Which stage is actually holding the swap?
First, open the source transaction in its own chain explorer and check its status, block height, confirmation count and exact output. Then compare the amount and destination instruction with the swap record. A wallet’s local activity view is not enough: it may show a transaction as sent while the chain has not included it.
After the deposit qualifies, the service’s observers must agree that it is valid. The route then applies the swap instructions, sources liquidity, calculates the output after price impact and fees, and schedules a destination-chain transfer. That transfer gets its own transaction hash and confirmation cycle. A swap can be progressing normally even when the destination wallet balance has not changed yet.
Use the last completed stage to narrow the cause. No source confirmation points to source-chain congestion or a transaction that was replaced or dropped. A confirmed deposit with no processing state points to observation, confirmation threshold or mismatched instructions. A completed swap with no destination hash points to execution or outbound scheduling; a destination hash that is still pending points to congestion on the receiving chain.
What should you do if the delay continues?
Match the source transaction hash, deposited asset and amount against the route’s record, then check whether the source transaction is still canonical. On an EVM chain, look for a successful receipt and the block number; “pending” can mean the transaction has not landed, while a failed receipt means its contract call reverted. On Bitcoin, a low-fee transaction may wait for a miner or be replaced, and a shallow confirmation can disappear in a reorganization.
If the source transaction is confirmed but the route has not advanced, preserve the hash and compare the deposit instruction exactly, including any required memo or destination address. A small amount sent to the wrong instruction can be harder to recover than a delayed transaction. Do not resend the full amount just because a tracker has not updated: if the first deposit is later recognized, the second transfer may create a second swap.
For example, say a BTC deposit shows one confirmation after roughly 10 minutes, while the route still says pending. Before: the wallet says “confirmed,” but there is no destination transaction to inspect. After: the source explorer shows one canonical confirmation, so the likely remaining wait is the route’s confirmation threshold; check again as blocks arrive. If the BTC transaction is replaced or disappears, treat that as a source transaction problem, not a slow destination payout.
A thor swap route can involve different source and destination chains, so the same wait time should not be expected for every pair. A BTC-to-Ethereum route can wait on Bitcoin confirmations, then on service-side processing, then on Ethereum inclusion; a route involving a fast chain may shift the bottleneck to liquidity, outbound scheduling or a congested destination. I would use the missing transaction hash to decide which chain or stage to investigate, rather than infer failure from elapsed time alone.
When is it a delay, and when is it a failure?
Call it a delay while the source transaction remains canonical and the route has not passed its expected processing window. Treat it as a likely failure when the source transaction reverted, was replaced, paid a different amount or omitted a required instruction, or when the destination transaction itself failed. A destination hash with a failed receipt is different from no destination hash at all: the first is an on-chain execution failure; the second means no destination transaction has been observed yet.
Once the route reports completion, verify the destination transaction in the destination chain’s explorer and check the recipient address and token contract. A successful transaction can still deliver a different net amount than the initial estimate because pool pricing, slippage and network costs affect the result. Keep both transaction hashes and the route identifier until the expected asset appears.
- Check the source transaction’s canonical status, amount and confirmation count.
- Use the last completed route stage to locate the bottleneck.
- Do not resend until you know whether the first deposit can still execute.
- When a destination hash exists, verify its receipt and recipient on that chain.