Jumper exchange Route Comparison and Output Confirmation

What turns an input into a completed exchange?

An exchange reaches completion when the quoted input is executed through the selected path and the requested output is confirmed on the intended network. The quote begins with a source network, source token, destination network, destination token and input amount. Those choices define what the routing engine can attempt. They do not promise that an executable path exists.

Before execution, the route describes each operation needed to reach the output. A same-chain swap may need one exchange step, while a cross-chain route may include a source swap, a bridge transfer and a destination swap. The wallet may also request a token approval before the exchange transaction. An approval authorizes spending up to the amount shown by the wallet; it does not itself perform the swap.

Before signing the displayed on-chain transaction, check the quote again if time has passed or the market has moved. A route with several steps can require more than one wallet confirmation, depending on how those steps are packaged. The source transaction must confirm before a bridge or destination action can produce the requested output.

A successful wallet prompt does not confirm that the exchange finished. The destination network, received token and final amount should match the completed transfer record and the wallet balance. For cross-chain activity, a successful source transaction confirms that the source action executed, while destination evidence shows what arrived.

Route parameters worth comparing

Route comparison works only when every candidate uses the same input amount and requested destination. Changing a token, network or amount creates a new quote rather than a fair comparison. The table identifies the fields that shape availability and the evidence each field contributes.

A theoretical connection is not the same as a live route. Liquidity, provider availability, amount limits, price impact and wallet conditions can prevent transaction data from being produced. A fresh quote is therefore stronger evidence than a broad claim that two networks or tokens are supported.

Same-chain swaps and cross-chain paths

Same-chain swaps use liquidity on one network and do not require a bridge transfer. They still depend on available liquidity, acceptable price impact, any required token approval and enough native gas for execution. A cross-chain transfer adds a bridge or another cross-network settlement mechanism. Confirmation must then be checked on both sides.

Cross-chain swapping may combine several economic actions. The input can be exchanged before bridging, after bridging or at both ends when the available path requires it. Each added swap introduces its own liquidity and slippage exposure, while the bridge contributes its fee, settlement time and operating conditions.

View full-size image

The routing layer aggregates quotes from decentralized exchanges and bridges before returning eligible paths. Routing may also present an intent-based path in which solvers compete to fulfill a defined output. That route class should still be judged by the quoted input, minimum acceptable output, costs, estimated duration and final settlement evidence rather than by its label.

Which quote best fits the exchange?

Choose the quote that best balances expected output, total cost, required transactions and estimated time for the same exchange. Highest estimated output does not settle the choice by itself. A route can show a stronger estimate while requiring more transactions, more gas or a longer bridge stage.

Expected output and minimum output answer different questions. Expected output reflects the quote at calculation time, whereas minimum output defines the lowest acceptable amount after the allowed slippage for the relevant swap. Price impact is separate from that slippage buffer: it estimates how the trade itself shifts the execution price from the current market price.

Increasing slippage does not preserve the quoted rate. It widens the range in which execution can proceed, which may reduce failures while accepting a worse result. A delayed quote should be refreshed because liquidity and exchange rates can change before signing. The new quote may choose another provider or step sequence even when all four asset and network selections remain unchanged.

Cost comparison should include visible provider fees, the service fee, estimated gas and any destination gas requirement. These items do not always use the same token. Estimated duration is another comparison field, not a deadline, because source confirmation, bridge processing and destination execution can progress at different speeds.

Approval, gas and wallet confirmation

Wallet prompts reveal what the next transaction authorizes, which network will process it and how much native gas it may consume. An EVM token approval can precede the exchange. The prompt should identify the token, spender and allowance; native assets do not need token approval. A network mismatch, insufficient spendable balance or insufficient gas can stop execution even when the routing engine found a path. Every later prompt should remain consistent with the quoted route.

What confirms that the exchange actually finished?

A completed exchange is confirmed by matching the route record with the destination transaction and the wallet’s received balance. The expected network and token identity matter as much as the displayed quantity. Tokens with similar names can have different contract addresses, so reconciliation should use the actual asset identity rather than a ticker alone.

Cross-chain progress can remain pending after the source transaction confirms. That state may mean the route is waiting for source confirmations, bridge processing or a destination transaction. Repeating the exchange at that point can create a second transfer, so status and transaction records should be checked before another submission.

A completed status can carry a more precise outcome. COMPLETED means the requested token arrived. PARTIAL means value arrived in a different token because a later conversion could not finish as planned. REFUNDED means the transfer failed and value was returned. Refund location and any claim action depend on the bridge used by the route.

Reconciliation compares what was quoted with what settled. Check the source amount, destination network, received token, received amount and every transaction identifier attached to the route. If the wallet does not display the asset, the destination transaction can show whether it arrived under a contract that the wallet has not listed.

Classify a mismatch before taking any new action. A pending transfer needs time or route-specific recovery, a partial completion leaves a different asset on the destination and a refund returns value according to the bridge process. The clearest successful endpoint is a route status of DONE with COMPLETED, supported by the destination transaction and the requested token in the receiving wallet.