When a cross-chain swap is pending or appears to have failed, check the source-chain transaction first, then the swap system’s execution record, then the destination-chain transaction. Each explorer can confirm only the activity recorded on its own network; one green status does not prove the whole swap settled.
Which explorer verifies each leg?
Use the explorer for the network where a particular transaction was broadcast. A cross-chain route can involve two or more on-chain transactions plus an execution record maintained by the swap system, so there is no single universal explorer for every leg.
- Source leg: Search the sending wallet’s transaction hash on the source network’s explorer. Check the recipient or contract, asset, amount, and confirmation state.
- Execution record: Look up the transaction or route in the explorer or public status index for the system handling the swap. This can show whether the inbound was observed, the swap executed, or an outbound was scheduled.
- Destination leg: Search the receiving wallet’s address or the outbound transaction hash on the destination network’s explorer. Verify the asset and amount actually credited.
- Token detail: On account-based networks, inspect the receipt and token-transfer events. A successful top-level transaction can still fail to deliver the expected token if the relevant call reverted or the transfer was different.
For a BTC-to-ETH example, the Bitcoin explorer verifies the UTXO payment and its outputs; the route’s own record verifies execution; an Ethereum explorer verifies the eventual ETH or token transfer. A thor swap uses the same evidence pattern: identify the route’s actual networks, then match each leg to its own record.
What does each status actually prove?
A source transaction marked successful or confirmed proves that the network accepted that transaction at the displayed confirmation level. It does not prove that the swap system has observed it, that an internal trade ran, or that the destination payment was broadcast.
On Bitcoin, an unconfirmed transaction is still in a node’s mempool, not in a block. Mempool.space can show fee-rate competition and whether it sees the transaction, but mempools differ; absence from one explorer does not prove the transaction was never broadcast. The Bitcoin Developer Guide describes six confirmations as roughly an hour of accumulated proof of work, but a swap route may use its own confirmation threshold.
On Ethereum, distinguish transaction success from finality. Etherscan can show the receipt status and block inclusion; proof-of-stake finality depends on checkpoint votes, with epochs of 32 twelve-second slots. That makes about 12.8 minutes a useful normal-scale estimate for two epochs, not a guaranteed deadline. On Solana, the RPC commitment labels are more explicit: processed is freshest and reversible, confirmed has supermajority stake votes, and finalized is the strongest commitment level. Solana’s RPC documentation defines those levels.
How should you diagnose a pending swap?
Follow the evidence in order, recording transaction hashes, timestamps, asset amounts, and destination addresses. Confirm the explorer is on the correct network, especially where testnet and mainnet identifiers look alike; then compare the source transaction’s actual output with the expected inbound address and amount.
Say a BTC transaction has one confirmation, but the route record has not appeared. The funds may be included in a block while the swap system is still waiting for its required confirmations or for its observer/indexer to process the event. Check again after the route’s expected confirmation window; do not send a second payment just because the destination explorer is still empty.
If the execution record shows the inbound as observed but no outbound transaction hash, the delay is after source-chain settlement. If an outbound hash exists, move to the destination explorer: a pending transaction can reflect congestion or a low fee, while a reverted receipt or failed transaction is a different failure. If the destination transaction is finalized but the wallet balance looks unchanged, inspect token transfers and the recipient address rather than relying on the wallet’s display.
When is it safe to act?
Act on the earliest leg that has clear evidence of failure. If the source transaction reverted or was never broadcast, the swap did not receive that payment. If the source leg is confirmed but the execution record is absent, preserve the hash and verify the route’s required confirmations before retrying. If execution completed and the destination leg failed, use the route’s documented recovery path; repeating the original swap could create a second independent payment.
The evidence threshold depends on the source chain’s reorganization risk, the route’s confirmation policy, and whether a destination transaction has already been created. When comparing routes, a thor swap service is a practical example of a cross-chain service that moves and swaps assets across networks in one flow; the same leg-by-leg checks let you tell whether it is waiting on source confirmation, execution, or destination settlement. If the source chain is reorganizing or the route reports a terminal failure, decide differently: wait for canonical status or follow that route’s recovery process before sending again.