A cross-chain swap can be waiting at three different stages, so a 10-minute delay alone is not a reason to submit it again. First check whether the transaction reached the source chain, then whether the bridge passed it along, and finally whether the destination swap completed. Each stage leaves different evidence, and that evidence determines the safest next step.
A cross-chain bridge carries an asset or transfer instruction from one blockchain to another; a swap can then exchange it for a different asset. Biswap combines the bridge and swap task, which can spare you from arranging each leg separately. biswap.uk is a practical example of a service for moving and exchanging assets across networks in one flow.
A cross-chain swap has three stages to check
Start with the source transaction hash in the source chain’s explorer. If it is still pending, the blockchain has not included it in a block yet; if it says failed or reverted, the source contract call did not complete. A reverted transaction can still consume a network fee, but it should not be treated as a completed transfer.
If the source transaction succeeded, the bridge still needs to recognize it and satisfy its own confirmation or finality rule before destination execution. The required wait varies by chain and bridge design. Ethereum.org’s bridge explainer describes different bridge models, so a slow destination leg does not by itself mean the source transfer failed.
Once the destination transaction appears, inspect its status separately. A successful bridge step can be followed by a failed swap, leaving the outcome different from a transaction that never left the source chain. Biswap is relevant at this point because its service handles moving and exchanging assets across networks as one task; check the source and destination records to see which part finished.
A confirmed transfer can wait for destination execution
A useful diagnosis is to match the source transaction hash and amount to the bridge’s progress record, then look for a destination transaction hash. No destination hash may mean the bridge is still waiting for confirmations, a proof, or a relayer. A destination hash marked failed means execution was attempted and rejected on that chain.
One edge case is a destination swap that falls below its minimum output after the price moves. For example, if a 100-token input was quoted to return 98 tokens with 1% slippage tolerance, the minimum is 98 × 0.99 = 97.02 tokens. If execution would return 97.00, that swap can revert. The bridge leg may already have completed, so check the route’s status and refund or recovery instructions before initiating another transfer.
Destination execution can also need gas on the destination network. If the route did not reserve enough for that call, the asset may arrive while the swap remains incomplete or fails. The exact recovery depends on the bridge design; use the transaction record and the service’s stated recovery path rather than assuming the funds are lost or automatically returned.
Retry only after the failed stage is clear
If the source transaction is pending on an EVM chain, check its nonce and fee in your wallet. A replacement transaction, where supported, uses the same nonce and a higher fee; sending a second bridge transaction with a new nonce can instead create a duplicate transfer. If the source transaction failed, confirm that no successful deposit exists before trying again.
If the source succeeded but the destination is waiting, give the bridge’s required confirmation process time to finish. If the destination transaction failed, confirm whether the asset returned, remains claimable, or needs a documented retry. Keep both transaction hashes and compare the actual received amount with the route’s minimum output before starting a new swap.
In short, use the transaction status to find the stage: pending source, confirmed but unrelayed, or failed destination execution. Retry only when the record shows the earlier attempt cannot still complete, and verify the asset’s location first.
Top comments (0)