If either chain is congested, allow extra time before starting a cross-chain swap, especially when you need the funds by a deadline. A quick route may finish in minutes, while a route waiting for stronger confirmation or delayed transactions can take tens of minutes or longer; the source transaction appearing in your wallet does not mean the swap is complete.
What determines the waiting time?
A cross-chain swap typically waits on several separate events. The slowest step often sets the pace, and congestion can affect more than one step.
- Source transaction inclusion: the first chain must include your transaction in a block.
- Source confirmation: the bridge route waits until the transaction meets its required security threshold.
- Cross-chain delivery: a relayer or other protocol participants carry proof or a message to the destination chain.
- Destination execution: the destination chain processes the message and credits or swaps the asset.
Inclusion is different from finality. On Ethereum, blocks are proposed in 12-second slots, but its proof-of-stake system typically takes about 15 minutes to finalize a block. A route may use a different confirmation threshold, so that figure is a useful illustration of why “one confirmation” and “safe to act on” are not always the same wait.
Congestion usually affects the transaction queue: your transaction may wait longer to be included if its offered fee is less competitive with current demand. Once included, the route may still wait for its chosen confirmation level, then for delivery and destination execution. A cross-chain aggregator such as Rango Exchange can find routes across networks, but the route’s underlying chains and protocols still determine its timing.
How does a swap move from one chain to another?
Think of a swap from ETH on Ethereum to a token on another chain as a sequence, not as one exchange order. First, you authorize a transaction from your wallet. It may swap ETH for an intermediate asset, lock or burn that asset, or emit a message that a cross-chain protocol can verify.
Next, the route waits for the source event to satisfy its security rule. Wormhole Guardians, for example, observe messages and attest after a configured consistency level; stronger finality can add waiting time but reduces exposure to a source-chain reorganization. In IBC transfers, relayers submit packet and proof updates between chains, and the receiving chain writes an acknowledgement after processing the packet. Axelar uses its own cross-chain message and validator mechanisms. These routes therefore do not share one universal countdown.
After delivery, a destination transaction or contract action must execute. If the goal is a token swap, that can be a separate on-chain operation from the original wallet transaction. The final balance may appear only after this last step succeeds, even if the source transaction has long been marked confirmed.
If you are comparing routes, Rango Bridge is relevant as a way to handle cross-chain routing; the important timing question is which chain and protocol each proposed route uses, and what confirmation work happens between them.
What does a realistic estimate look like?
Use this illustrative Ethereum-source example, not a service guarantee: suppose congestion takes 8 minutes to include your transaction, the route waits for about 15 minutes of Ethereum finality, cross-chain delivery takes 3 minutes, and the destination swap takes 4 minutes to include and execute. The total is about 30 minutes (8 + 15 + 3 + 4).
Change any one of those inputs and the estimate changes. If the source transaction is included quickly and the route accepts an earlier confirmation threshold, the swap could finish sooner. If the transaction waits in the queue, the route requires stronger finality, or the destination chain is busy too, the total can stretch well beyond the example.
For a more grounded estimate, check the source transaction’s status and block time, then look for whether the bridge step is waiting on confirmations, a message, or destination execution. A source transaction marked “successful” answers only whether that transaction executed on its own chain; it does not prove that the other chain has completed the swap.
What should you do if it seems stuck?
Start with the transaction hash in a block explorer for the source chain. If it is pending, the delay is still at inclusion; if it succeeded, check whether the cross-chain message or destination transaction has appeared. This separates a slow source transaction from a later relay or execution delay.
An edge case is a packet or message that arrives but cannot complete because the destination action fails or times out. IBC’s packet flow includes acknowledgements and timeout handling, while other protocols have their own recovery rules. Do not assume a missing destination balance means the source funds vanished; check the route’s transaction states and use the protocol’s documented recovery path if a transaction has failed.
When a deadline matters, leave a buffer rather than planning around the fastest possible route. Rango Bridge can help with the routing task, but the transaction status on each chain is what tells you where the time is going.
Decision rule: start early enough to cover source inclusion, the route’s confirmation threshold, cross-chain delivery, and destination execution.