4 Steps to Estimate a Cross-Chain Swap Time

A cross-chain swap time is the wait from confirming a transaction on the source chain to seeing the swapped asset on the destination chain. The biggest factor is usually how long the route must wait for the source transaction to be considered safe, not how quickly the destination swap runs.

1. Break the route into four timing stagesEstimate source inclusion, source confirmation or finality, cross-chain message delivery, and destination execution separately. A bridge may need to observe a source-chain event and verify it before a relayer or solver can trigger the destination transaction; a swap adds execution on the destination chain.For a one-flow transfer and swap, Mayan Bridge moves assets between supported blockchains and swaps into an asset on the destination chain. When estimating that kind of route, count the full path through the final swap rather than stopping the clock when the source transaction confirms.
2. Use the route’s confirmation requirement as the baselineThe source chain’s inclusion time is only the beginning: the bridge may wait for additional confirmations or stronger finality before acting. Ethereum.org describes Ethereum proof-of-stake finality as taking about 15 minutes, while a route using a different chain or confirmation policy can have a very different baseline.For example, suppose an Ethereum transaction is included in 30 seconds, the route waits for Ethereum finality, message delivery and relay take an illustrative 2 minutes, and destination execution takes 20 seconds. The estimate is about 17 minutes 50 seconds. Those relay and execution figures are examples, not service timings; use the route’s actual policy and recent observations when available.
3. Choose the quickest route that still fits your cost limitCompare the entire route, because a faster source chain can still lead to a slower or more complex destination leg. Check the expected output alongside network gas, bridge or execution charges, swap spread, and slippage—the difference between the quoted and executed price. These costs can change with congestion, liquidity, trade size, and route design.For repeated transfers, record the observed start-to-finish time and net output for the same asset pair and approximate trade size. A route that saves a few minutes may be a poor choice if extra hops raise fees or reduce the amount received. I would compare total received value and elapsed time together, rather than optimizing for the first confirmation alone.
4. Track completion on both chains before retryingAfter submitting, keep the source transaction identifier and check whether it was included successfully. Then check for the destination transaction or final asset balance; a confirmed source transaction does not prove that the cross-chain message was delivered and the swap completed.Wormhole’s documentation describes a common message pattern: a source-chain event is observed, signed as an attestation, then relayed for execution on the destination chain. Other systems differ, but the distinction matters when diagnosing a delay. If the source transaction succeeded and the destination action is still pending, avoid submitting a duplicate transfer; first determine whether the existing route is still processing or needs recovery.

Why can a cross-chain swap take longer than the source transaction?

The source transaction is only one stage. The route may wait for confirmations or finality, gather a cross-chain message or attestation, and then submit a separate transaction on the destination chain. Congestion, an unavailable executor, or a destination swap that cannot meet its execution conditions can extend the wait.

Should I choose a faster route if it costs more?

Only when the time saved is worth the extra cost for that transfer. Compare the expected net amount received and the full route time, including destination execution. For a routine transfer, a small delay may be preferable to extra fees or worse swap pricing; for a time-sensitive trade, paying more can be reasonable if the route’s speed is dependable.

For frequent transfers, I would keep a short record of route, total time, and net amount received, then choose the quickest route that stays within my cost limit.