Cross-chain swap tracking: when to wait and when to investigate

Cross-chain swaps depend on separate blockchains and a protocol coordinating between them. THORChain’s developer documentation describes five stages to track: inbound confirmation, observation, confirmation counting, outbound delay and destination-chain confirmation.

Knowing which stage is still open helps distinguish expected settlement time from a transaction that needs investigation.

Which transaction should you track first?

Start with the transaction hash on the source chain, then follow the protocol’s record of that inbound transaction. A wallet may show the deposit as confirmed before THORChain has observed it or reached consensus on it. THORChain’s documentation says nodes independently observe inbound activity, and the transaction status exposes observation progress, including which nodes have seen it.

Once the protocol has processed the deposit, check for a planned outbound and then its transaction hash on the destination chain. These are separate events: a completed swap inside the protocol does not itself mean the destination network has confirmed the payout. For a closer look at route choices, the fuller guide to thor swap explains the trade-offs that affect execution. Keep the source hash, destination address and selected minimum output at hand when comparing records.

Why can a confirmed deposit still be pending?

Source-chain confirmation is only the first gate. THORChain’s delay guide separates the remaining progress into observation and consensus, confirmation counting for chains where reorganisation risk matters, outbound queueing, and confirmation of the payout on its destination chain. Each stage depends on different conditions: the source chain’s block production, node observation, the required confirmation depth, protocol workload and destination-chain activity.

Use the transaction-status endpoint or a tracker that shows stages rather than relying on a single “pending” label. THORChain documents status fields for inbound observation, confirmation counting, swap finalisation and outbound transactions. A status that has not advanced can therefore be more informative than elapsed time alone: it identifies which part of settlement is still outstanding.

When is waiting reasonable, and when should you investigate?

Waiting is reasonable while the relevant chain is still confirming the transaction, nodes are still observing it, a confirmation count remains, or the protocol has queued the outbound. THORChain says wait time varies with the assets, swap size and network traffic; its documentation gives a broad range from seconds to hours across transaction phases. Treat a quote’s estimate as a planning aid, not a guarantee that every stage will finish at that moment.

Check the record again if the protocol marks the swap finalised but no outbound transaction appears, or if an outbound hash exists but the destination chain has not confirmed it. Verify that the destination address is the one specified in the swap, and look for a refund or an explicit failure status before taking another action. Repeating a deposit while the first one is still progressing can create a second swap rather than accelerate the first.

A useful tracking checklist is:

• Confirm the source transaction on its own chain.
• Check whether the protocol has observed it and completed its required confirmation count.
• Look for swap finalisation, then identify the outbound transaction.
• Confirm the outbound on the destination chain or check for a recorded refund.

The practical rule is to wait on the stage that is actually pending, and investigate when the status record stops matching the transaction history. Cross-chain settlement is a sequence, so the source confirmation alone cannot establish that the swap is complete.