Four checks to make when a cross-chain swap is stuck

When a cross-chain swap stalls, trace it from the source transaction through protocol processing to the destination payout before retrying. THORChain’s developer docs break that path into confirmation, node observation, finality, outbound queueing and destination-chain confirmation. The route determines which chains to inspect; thor swap covers destination selection in more detail.

Did the source-chain transaction confirm?

Look up the transaction hash in the source chain’s explorer. A wallet showing “submitted” only means it broadcast the transaction; the explorer can show whether it was included, is still pending or failed. THORChain’s docs say inbound confirmation depends on the source chain, and that nodes observe the transaction after confirmation.

• Check that the hash is on the expected source chain.
• Confirm the transaction succeeded and has the required confirmations.
• Compare the sent amount and destination details with the swap record.

Has the protocol observed and processed the deposit?

Check the swap’s transaction status in the protocol’s tracker or the interface you used. THORChain’s developer docs distinguish an inbound transaction being observed from its confirmation count reaching finality; a confirmed source transaction can still be waiting at either step. If the tracker has no matching inbound record, check the hash and chain before contacting the interface’s support team.

Was an outbound transaction created?

If the swap has been processed, look for an outbound transaction hash and check it on the destination chain. THORChain’s docs say larger outbounds can be delayed in a queue, while its Bifrost documentation notes that a broadcast can remain pending or be dropped during congestion. A scheduled or pending payout is different from a failed swap: check the destination explorer and protocol status before taking further action.

Is there a refund or a route problem?

Check the status record for a refund, and verify the destination network and address against the original swap details. THORChain’s network-halt documentation says a signing halt can queue outbounds, while a trading halt can stop transaction processing and result in refunds. If the interface reports a refund, verify its transaction hash on the source chain; if neither payout nor refund appears, give support the inbound hash and status record.

Do not send a second swap just because the first one is slow. The transaction record and the last confirmed stage show whether to wait, investigate a missing deposit or follow a refund.