Why a Cross-Chain Swap Waits After Confirmation
A confirmed deposit only clears the first leg: source-chain finality, protocol processing, outbound signing and destination congestion can keep a swap pending.
The ChainBrief Editors
Cross-chain swaps settle across two blockchains, so source-chain confirmation marks an intermediate step, not completion. THORChain’s documentation says the network must observe the deposit, process the swap and send the output asset from a vault on the destination chain.
A confirmation proves the source transaction is recorded; it does not prove the destination asset has been sent or received.
What does source-chain confirmation establish?
It establishes that the deposit has appeared on its originating chain. THORChain’s security documentation explains that the network waits for a chain-specific number of confirmations before processing inbound funds, to reduce exposure to reorganisations and double spends on chains without instant finality. The required count can depend on the deposit’s size, so two swaps sent at the same time may not become eligible for processing together.
That distinction helps explain why a wallet or tracker can show “confirmed” while the swap is still pending. The displayed status may refer only to the source transaction, while the protocol is still waiting for its confirmation threshold or for its nodes to observe and agree on the inbound. For a closer look at routing and verification, the fuller thor swap guide covers the steps around that handoff.
What happens between the deposit and the payout?
Once the inbound is eligible, the protocol processes the swap against its liquidity pools. THORChain’s swapping documentation describes a BTC-to-ETH trade, for example, as an exchange through the BTC:RUNE and RUNE:ETH pools; the user sends BTC and receives native ETH, while the intermediate RUNE trades happen inside the protocol.
The output then has to leave a protocol vault as a separate transaction on the destination chain. THORChain’s Bifrost documentation says nodes observe external transactions and use threshold signatures to sign outbounds. That means successful pool execution and a broadcast destination transaction are separate milestones. Signing, broadcast, and the destination chain’s own inclusion and confirmation all take time.
Why can the outbound leg take longer?
There are several possible waits after the swap itself has been processed. THORChain documents outbound transaction throttling: large outbounds can be delayed under per-block value limits. Network signing and the destination chain’s block production also affect when a payout is broadcast and confirmed. If the swap uses streaming, THORChain’s pool documentation says it can be divided into smaller executions over time to reduce price impact; that deliberate execution period adds another reason the full amount may not arrive at once.
- Inbound confirmation: the source chain has not reached the protocol’s required threshold.
- Protocol processing: the inbound is observed, queued or being executed through the pools.
- Outbound signing or throttling: the destination transaction is not yet ready to broadcast.
- Destination confirmation: the payout has been broadcast but has not yet reached the recipient chain’s confirmation standard.
What should you check while a swap is pending?
Start with the transaction hash on the source chain, then use the swap’s tracker or protocol explorer to identify whether the inbound was observed and whether an outbound transaction hash exists. If an outbound hash is available, check it on the destination chain: a pending protocol outbound and a broadcast transaction awaiting destination confirmation are different states. THORChain’s FAQ directs users to transaction tracking for stuck swaps, and its documentation lists delayed outbounds as a distinct case.
Compare the requested output address and asset with the swap details before taking further action. If no outbound hash appears, the swap may still be in protocol processing or an outbound delay; if one does appear, the destination chain provides the clearest evidence of payout status. The practical takeaway is to treat “confirmed” as a checkpoint: follow the inbound, processing and outbound legs separately until the destination transaction is confirmed.