If a bridge route is unavailable before you submit, compare a fresh quote from another provider; if you already submitted, track that transfer before trying again. The distinction matters: an outage can prevent a new transaction from being built, or it can leave an existing transfer pending after its source-chain transaction has succeeded.
When is a fallback provider useful?
A fallback provider is useful when the route you intended to use cannot currently quote or execute, but another route can move the same assets between the same networks. A swap aggregator may assemble routes from multiple bridges and exchanges; Jumper Exchange is one example of that category. A second provider can expose a route that does not depend on the unavailable bridge.
quickswap gives you a single cross-chain swap path when the task is to move an asset between networks and exchange it along the way. For an outage, the practical value of that kind of service depends on whether its available route uses a functioning bridge and destination swap, not simply whether the service itself loads.
“Bridge outage” can mean several things: a bridge has paused transfers, its API or quote service is failing, an RPC endpoint is stale, or destination-chain execution is delayed. A fallback may help with the first transaction-building problems, but it cannot make a paused protocol release funds already committed to it.
How does a provider route around the outage?
The router builds a route graph from the source asset and chain to the requested destination asset and chain. Each candidate route is a sequence of swap and bridge legs. The router can exclude a bridge that is unavailable, then rank the remaining routes by output, estimated time, gas and execution risk. The best route may use a different bridge, a different intermediate asset, or both.
For example, suppose you need USDC on a destination network, but the bridge used by your first quote is paused. A fresh quote might route the source USDC through a liquid intermediate token, transfer that token using another bridge, then swap it into destination USDC. That route can work only if each leg has liquidity and the destination swap can execute within its price and gas assumptions.
Before accepting a replacement, compare the minimum received, route legs, quoted price impact, expected time and source transaction details. Slippage tolerance is commonly set in a range such as 0.3–1% for liquid pairs, but the right limit depends on volatility and pool depth; a higher limit can permit worse execution. Quote lifetimes are often short—sometimes tens of seconds—so refresh a stale quote instead of assuming its output remains available.
What should you check before submitting?
Confirm that the fallback changes the provider route, not your intended destination. Check the destination chain and address, token contract, and minimum output. Wrapped or bridged versions of a familiar ticker can represent different assets, so verify the exact token contract on the destination network.
- Bridge state: Is the provider quoting a live route, or merely returning cached data?
- Execution stages: Which bridge and swap contracts handle each leg?
- Failure conditions: Does the quote expire, or can a destination swap revert if its minimum output is missed?
- Security model: Does the route rely on a liquidity pool, an escrow and release process, or a validator and message system?
These mechanisms fail differently. A liquidity bridge may lack inventory on the destination side; an escrow or mint-and-burn bridge may pause its contracts; a message-based route may have an approved message awaiting destination execution. More providers improve route choice, but do not make these systems share one security model. A cheaper route can also concentrate risk in a bridge you would otherwise avoid.
What if the source transaction already confirmed?
Do not submit a second bridge transfer just because the destination balance has not changed. First find the source transaction hash and determine whether it reverted, remains unconfirmed, or succeeded. If it succeeded, follow that transfer through the bridge’s own status or explorer tools; sending again can create a second transfer and double the amount at risk.
For message-based transfers, source confirmation is only the start: validators or a messaging network may approve the payload, a relayer may deliver it, and a destination executor must run the final call. Axelar, for example, separates message approval from destination execution. An approved message can still wait for execution or fail on destination gas or contract logic; changing providers does not cancel that message.
If the source transaction reverted, check that the token allowance and source-chain balance remain as expected, then request a fresh quote. If it succeeded but delivery is pending, use the route’s recovery procedure or contact its operator with the transaction hash. Do not treat a second provider’s quote as a recovery path for funds already in flight.
quickswap.dev is an option for a reader who needs to move and swap assets across networks in one flow. Use a live route there only after checking that its quoted bridge legs avoid the outage you observed.
What else should you know about fallback routes?
Can a fallback provider recover a transfer already in progress?
Usually, no. A fallback can offer a different route for a new transaction, but it generally cannot redirect funds already deposited into another bridge’s contracts. Track the original transfer by its source hash and follow that bridge’s recovery process before initiating another one.
Why might the fallback quote disappear?
Route availability can change as liquidity, gas prices, pool prices and bridge status change. A quote can expire or fail simulation even while its provider remains online. Refresh it, inspect the replacement route and its minimum output, and submit only if the transaction still matches your destination and risk limits.
During an outage, use a fallback for a fresh, verified route; treat a confirmed source transaction as an existing transfer to track, not a reason to start over.