How to Tell If a Chainflip Swap Is Stuck or Still Pending

To tell whether a Chainflip swap is stuck, check which stage has stopped: the source deposit, the swap itself, or the destination payout. A delay at one stage does not automatically mean the funds are lost, and retrying before checking can create a second swap.
- Use the source transaction hash to confirm the deposit was included in a block.
- After confirmation, check whether the swap was witnessed and whether a destination transaction exists.
- Retry only after you know whether the original transfer completed, is still processing, or is being refunded.
A cross-chain swap typically passes through three checkpoints: source-chain confirmation, protocol processing, and destination-chain broadcast. For a native-asset swap, Chainflip follows that pattern: Validators witness the deposit, the JIT AMM processes the trade, and the network signs and broadcasts an egress (the outgoing transfer). The Chainflip network is one way to make this kind of swap; the checkpoints also help explain delays on other routes.
Is the source deposit still waiting for confirmation?
If the source transaction is unconfirmed, the swap has not reached the protocol’s processing stage. Open the source chain’s public block explorer with the transaction hash and check whether the transaction is pending, included in a block, or dropped. A wallet’s “sent” message only means it submitted the transaction; it does not prove the network accepted it.
Confirmation requirements vary by chain and can change. Bitcoin transactions, for example, are often monitored for multiple blocks, so a deposit may need tens of minutes before it is treated as final; a faster block time does not always mean a faster protocol confirmation. If the transaction is included but has too few confirmations, wait and check again rather than sending the same amount a second time.
Has the deposit cleared, but no destination transfer appeared?
Once the deposit is confirmed, the protocol must witness it, execute the swap, then prepare and broadcast the destination transfer. Those steps are distinct: a completed trade can still be waiting for a signature ceremony or for a broadcaster to submit the transaction. Check for a destination transaction hash; if one exists, follow that hash on the destination chain’s explorer.
For example, suppose you send BTC to receive ETH. The Bitcoin deposit may confirm first, while the ETH transfer appears later because the protocol must process the trade and then broadcast on Ethereum. If Ethereum is congested, the egress can be delayed even though the BTC deposit and swap have progressed. Check the destination transaction’s status: pending means it has been submitted but not yet confirmed; a confirmed transaction means the recipient address should show the funds, subject to the token and wallet displaying correctly.
If there is no destination hash after the source deposit is confirmed, look for a swap status or protocol event tied to the deposit transaction. That helps distinguish “not yet processed” from “broadcast but not yet visible.” Keep the source and destination hashes together when seeking help through the service you used.
Does the status show a failure or refund?
A failed swap and a delayed payout call for different next steps. If the protocol reports a refund, check the specified refund address on the source chain and wait for the refund transaction to confirm. A refund is a separate on-chain transfer, so it may take time and can have network costs deducted.
If the destination transaction reverted or the transfer failed, do not assume that sending a new swap will recover the first one. Some failures require a recovery transaction or a refund process; the exact path depends on the chain and failure stage. Save the swap identifier, source hash, destination hash if present, and the exact status before contacting the service used to initiate the swap.
What should you do before trying again?
Retry only when the first attempt’s outcome is clear. A replacement deposit made while the original is still progressing can result in two swaps, while a deposit sent to an expired or incorrect destination setup may not be recognized as intended.
- Find the source transaction and confirm its block status.
- Check for protocol processing, a destination transaction, or a refund.
- Verify the destination address and asset before starting another attempt.