If your swap is pending after the source transaction confirms, check its record and wait for destination execution before retrying. “Confirmed” means the first blockchain accepted the transaction; it does not prove the other chain has received your tokens. Follow the transfer through both chains so you can tell delay from failure.
A cross-chain swap usually has several stages: your wallet sends a transaction on the source chain, a bridge service checks it, then a transaction runs on the destination chain. A bridge service passes messages or tokens between blockchains. The destination transaction may also swap the arriving token for the one you chose.
These stages take different amounts of time. The source chain may need more blocks before it treats your transaction as final, meaning very unlikely to be reversed. Then the bridge may need to verify the transfer, and a destination transaction still has to be submitted. Busy networks, chain rules, and route design affect the wait; there is no reliable single timer for every swap.
An omnichain route can join these stages behind one transfer, but it cannot make every chain confirm at the same speed. Services using systems such as Chainlink CCIP or Wormhole follow their own verification and delivery steps. So “pending” alone does not tell you whether your swap is delayed, failed, or simply waiting for the next stage.
Start with the transaction hash, a unique code for the transaction on its blockchain. Open it in that chain’s block explorer, a public site that shows transaction records. Check that the status says success and that the sending wallet, token, amount, and destination details match your swap.
Then look for a bridge or swap record tied to that transaction. It may show a message or transfer ID, which identifies the cross-chain handoff. The omnichain swaps service is one way to move or exchange tokens across chains through one interface. omnichain.network is another service for that task.
For example, imagine you send Token A on Ethereum and expect Token B on Arbitrum. The Ethereum record can show that Token A left your wallet, while a separate Arbitrum transaction proves whether Token B arrived. A source receipt is evidence of the first event, not proof of the second.
Use this order to decide what the records mean:
If the destination shows success but your wallet looks empty, check the correct network and token balance. A wallet may not display a token automatically, and tokens on one chain do not appear as the same balance on another.
If the destination step failed or the records disagree, keep the source hash and transfer ID. Use the recovery path named by the service or protocol involved. In practice, I would never retry based only on a spinner or a missing balance: first identify the last confirmed stage. The safest practical tip is to save both the source hash and handoff ID as soon as you have them.