Rango exchange

Exchange is rango’s Route From Quote Selection Through Output Checks

Exchange is rango’s operational path from a route preview to a signed, tracked, and checked cross-chain swap. The workflow fixes the source token, destination token, amount, wallet addresses, and slippage tolerance before it builds transaction data. A user then compares quoted output, minimum output, fees, route steps, and required signatures, signs only the selected transaction, follows its status, and confirms the actual token and amount received.

From route preview to a signed swap

Rango’s exchange workflow begins with source and destination assets, then turns the chosen quote into wallet-ready data and a trackable request. The initial response binds a request ID to token metadata, amounts, route nodes, fees, and timing estimates. That identifier carries the operation into route confirmation, transaction creation, and status checks.

A concrete walkthrough starts when a user enters an amount and selects both chains. Rango returns one or more paths through named venues, such as a source swap on Uniswap, a transfer through Stargate, and a destination swap. After the user picks a path, Rango confirms the selected wallets and checks prerequisites. It then creates either an approval request or the main transaction. The wallet signs and broadcasts that payload, returning a transaction hash that Rango uses to follow the route. The displayed path should remain unchanged between selection and transaction build; otherwise the fresh build deserves another comparison.

Only the built transaction reaches MetaMask or Trust Wallet; the earlier preview remains an estimate rather than an on-chain instruction.

Exchange quote costs before wallet confirmation

Rango quote costs separate output deductions from network fees that a source or destination wallet must already hold before signing. Route data defines 3 expense locations: FROM_SOURCE_WALLET, DECREASE_FROM_OUTPUT, and FROM_DESTINATION_WALLET. The distinction shows whether a charge reduces received tokens or consumes a native gas balance.

Network cost comes from the transaction’s gas limit and gas price on EVM chains, while bridge and swapper charges appear in the route’s fee entries. A deducted charge already lowers the quoted output; a source-wallet gas estimate doesn’t. Units matter here: 1 ETH equals 1,000,000,000,000,000,000 wei, and USDC uses 6 decimal places. Reading machine units as display units produces a false comparison, so the token’s decimal field belongs beside every amount. The quoted USD conversion is informational and moves with price, whereas token-unit arithmetic remains exact for that response (examined in practice ).

Which route details deserve the first comparison?

The first route comparison should weigh minimum output, expense location, required signatures, and route composition before the headline expected output. Rango also returns estimated time, amount restrictions, and path nodes, exposing whether 1inch, Jupiter, Osmosis, Across, or another integration supplies a leg. Two paths with the same expected output can differ because one deducts bridge costs and the other asks for more native gas.

In this hypothetical example, every changing input is assumed: the source is 2,000 USDC on Polygon, the quote is 1,990 USDC on Base, and tolerance is 0.5%. The minimum is 1,990 × 0.995, which equals 1,980.05 USDC. Source-chain gas remains separate because it leaves the wallet’s native-token balance. The concrete acceptance result is therefore 1,980.05 USDC on Base, not the expected 1,990 USDC.

A route with fewer signatures reduces user actions, while a higher minimum output defines the stronger settlement floor for that specific quote.

Route freshness and the five-minute creation window

Rango route freshness determines whether the selected quote still qualifies for transaction creation when the user moves from review to signing. Rango rejects transaction creation more than 5 minutes after the quote and identifies that condition with error code 1303. Creating the transaction within 1 minute reduces exposure to reserve changes and gas movement. If the wallet prompt sits open after the route changes, reject it, request fresh transaction data, and compare the new minimum output.

Matching assets, chains, and destination wallets

Asset identity in Rango combines a blockchain identifier with a native symbol or contract address, so identical tickers don’t establish equivalence. Ethereum uses chain ID 1, BNB Smart Chain uses 56, Polygon uses 137, Optimism uses 10, Arbitrum One uses 42161, and Base uses 8453. The connected wallet must match the source chain.

An EVM address contains 20 bytes and appears as 40 hexadecimal digits after the 0x prefix. That format alone doesn’t prove the selected network or token. An ERC-20 USDC contract on Ethereum and a USDC contract on Base represent balances on different ledgers, even though both tokens use 6 decimals. Rango’s route therefore needs the chain, token contract, source wallet, and destination wallet as separate values. Solana keys use a 32-byte public key, while Bitcoin destinations encode network-specific script information. Those address systems and their transaction formats aren’t interchangeable.

For a multi-chain path, the wallet map supplies an address for every signing chain, while a custom destination fixes the final receiver.

What exactly should the wallet confirmation show?

A wallet confirmation should show the intended network, recipient or contract, transferred value, transaction fee, and approval amount before any signature leaves the device. MetaMask presents EVM calldata and gas settings, while Trust Wallet formats the same request through its own interface.

The confirmation must correspond to the freshly created transaction, not merely to the earlier quote. On Ethereum, the chain ID separates a mainnet signature from an otherwise similar request on another EVM network. Solana wallets display public keys in base58, while Bitcoin signing presents UTXO inputs, recipient outputs, and change. Those formats aren’t interchangeable. For contract calls, the displayed recipient is normally the contract address, not the final token receiver shown in the quote. Match the wallet’s network, destination, value, and action type to the route before broadcasting. Anything left over is addressed in Rango exchange overview.

Approval and swap signatures on token routes

An ERC-20 route with an insufficient allowance adds an approval transaction before Rango provides the main swap transaction for signing. The approval authorizes a specific spender to move the token amount, while the later transaction executes the selected path. Native ETH doesn’t use ERC-20 allowance.

This approval path creates 2 distinct on-chain actions: first approval, then the swap. Rango checks the approval transaction separately and compares the current allowance with the required amount. After approval succeeds, transaction creation runs again and returns the main payload. A simple native-token path can need only 1 signature, but the route’s required-signature field gives the relevant count. Destination claims or later route steps add their own wallet requests. That field matters when a bridge requires an additional claim or when a multi-step path crosses incompatible wallet families.

An exact approval confines the allowance to the planned amount. An unlimited approval removes repeat approvals for that spender, yet the allowance stays active until it changes on-chain.

Transaction states across source and destination chains

Rango transaction tracking uses 3 status values - running, success, and failed - while every multi-step route numbers its first step as 1. A running or empty status calls for another status check; success and failure end that step’s polling cycle.

Reliable tracking keeps 3 pieces together: the request ID, transaction hash, and step number when the route has multiple steps. The request ID follows a UUID shape with 32 hexadecimal characters and 4 hyphens. An EVM transaction hash contains 32 bytes, displayed as 0x plus 64 hexadecimal digits. The source receipt proves that the inbound transaction reached its chain, while Rango’s status response connects it to any outbound destination transaction. Keeping them together prevents a destination receipt from being mistaken for an unrelated transfer with the same token.

Approval status runs on its own check because approval isn’t the main swap. Once a route step succeeds, the next step receives fresh transaction data and a separate signature request.

Output categories reveal where value stopped

Rango output categories distinguish the requested asset from a returned input or an intermediate token left on either side of a bridge. A cross-chain status response classifies received value into 4 output types: DESIRED_OUTPUT, REVERTED_TO_INPUT, MIDDLE_ASSET_IN_SRC, and MIDDLE_ASSET_IN_DEST.

A basic cross-chain operation can combine up to 3 internal phases: a source DEX swap, a bridge transfer, and a destination DEX swap. If the final phase doesn’t complete, the destination wallet might hold the intermediate asset even though the intended ticker never appears. Compare the response’s received token, contract, decimals, amount, and chain with the quote’s destination data. A successful label carries weight only when those output fields match the intended asset. The minimum output applies to the desired token, so an intermediate balance needs its own asset-aware interpretation.

What should you do when the received output differs?

A mismatched output should be traced by output type, request ID, transaction hash, route step, and the chain holding the received token. Start with the status response, then match each explorer record to the source, bridge, and destination phases. Don’t infer completion from the source receipt alone.

REVERTED_TO_INPUT points back to the original source asset, while either middle-asset category identifies the ledger where the route stopped.

If the status names a token that the wallet interface doesn’t list, add the exact contract on the stated chain and apply its recorded decimals. For a bridge action that requires intervention, use the diagnosis action returned with the route. Wormhole routes can require a manual redemption, while Celer cBridge exposes a refund request for qualifying transfers. The protocol action follows the existing transaction; it doesn’t start a duplicate exchange from the source wallet. A middle asset can require a new route later, but establish its recorded balance before any follow-on transaction.

Keep the 36-character request ID, every transaction hash, the output type, token contract, chain, error code, and trace ID together. Error 1202 identifies an input outside a swapper’s limits, 1302 marks a quote-to-creation discrepancy, and 1304 means routing found no valid path.

If no transaction hash exists because signing or broadcasting stopped, rebuild from a fresh quote. Once a source hash exists, continue tracking that operation before considering another transfer.

Exchange route construction under the hood

Rango route construction evaluates DEX, bridge, aggregator, and off-chain swapper nodes, then returns paths ranked by output, fees, and execution conditions. A maxLength of 1 restricts routing to a single step. Named integrations such as Uniswap, 1inch, Jupiter, Osmosis, Across, Stargate, Wormhole, and THORChain supply different liquidity or transport legs. Filters can restrict approved swappers or blockchains without changing the underlying signing sequence. The final route object preserves those nodes, the required signatures, amount limits, and minimum output for the user’s decision.

Exchange questions, answered