Rango
Rango is a wallet-routing interface with network-mismatch recovery
Rango is a cross-chain route interface that lets a wallet compare expected output, minimum output, fees, path, and estimated completion time before approval. Once the wallet signs, the selected network records the approval or swap transaction, while Rango tracks each route step through its request ID and transaction hash. If the wallet opens on the wrong network, switching back to the route's source chain and rebuilding the unsigned transaction restores the intended flow without creating an on-chain state change.
Two execution modes define the wallet flow
Two maintained execution flows determine what the wallet sees: a single-step transaction flow and a multi-step flow that requests one transaction per route step. The single-step path keeps a DEX swap, bridge transfer, and destination swap inside one submitted route when the selected integration supports aggregation. The multi-step path exposes successive transactions, which matters when an intermediate chain requires its own address, gas asset, or wallet confirmation. This distinction is notable because route quality alone no longer describes the signing burden; the displayed step count does.
Wallet prerequisites before a quote
Three prerequisite checks control whether Rango builds an executable route: source balance, network-fee balance, and a compatible address for every required chain.
On an EVM route, the source account needs the input token and native gas on the chain that will receive the signature. Ethereum uses chain ID 1, Arbitrum uses 42161, BNB Smart Chain uses 56, Avalanche C-Chain uses 43114, and Base uses 8453. Those identifiers distinguish networks even though all five accept the same 20-byte address shape. A matching hexadecimal address therefore proves address-family compatibility, not that the wallet has selected the correct chain or holds the required native asset. For example, ETH pays gas on Ethereum, while BNB pays gas on BNB Smart Chain.
Solana, Cosmos, TRON, Starknet, and Bitcoin use different signing and address models. A route that crosses those families needs the corresponding connected wallet, not an EVM address copied into every destination field.
Rango route data versus wallet transaction data
Zero blockchain state changes occur when Rango displays a route, because the preview remains quote data until a wallet broadcasts a signed transaction. The preview describes the input asset, destination asset, expected output, minimum output, fee entries, path, and estimated time. The wallet prompt contains the actual recipient contract, value, call data, gas fields, and chain context. Treat the refreshed wallet prompt as the execution record; a saved quote cannot replace it after route or network changes.
Which choices matter before confirmation?
Five choices deserve a final comparison before confirmation: asset contract, source network, destination address, minimum output, and the number of wallet actions.
Asset tickers do not identify contracts across chains. USDC on Ethereum is an ERC-20 token, while USDC on Solana uses a Solana mint address; selecting the wrong network produces a different asset record even when the ticker matches. Compare the contract or mint, then inspect the route path through named components such as 1inch, Stargate, or Wormhole. Fee entries also have two distinct treatments: native gas comes from the source wallet, while output-deducted fees reduce route output. The minimum-output field already reflects the chosen slippage boundary and belongs in the confirmation decision.
Rango applies a 0.5% slippage setting when the routing request omits one. A user-selected value replaces that default and changes which routes remain eligible.
Quote freshness and the five-minute boundary
Five minutes is the documented creation window for a Rango route, while the integration flow recommends creating the transaction within 1 minute.
Route code 1303 means that the quote has expired. A balance change, a destination edit, or a network correction requires a re-quote before signature because the transaction payload comes from the confirmed request. Code 1302 marks a material discrepancy between quoted output and transaction-creation output, while code 1304 means that no valid route remains. The 5-minute limit is an outer boundary, not a promise that pool reserves and gas estimates stay unchanged for that whole period.
No on-chain cancellation is needed for an expired unsigned quote. Re-entering the same inputs creates a new request ID and a new wallet payload.
Approval and execution as separate state changes
Two wallet signatures appear on an ERC-20 route when allowance is insufficient: one approval transaction, followed by one main swap transaction.
The approval changes an allowance for the route's spender contract; it does not move the selected swap amount through the route. Rango checks the approved amount against the required amount, and it requests the main transaction only after the allowance check succeeds. EVM networks, TRON, and Starknet use this separate approval branch in the documented flow. An approval that confirms for less than the required amount still leaves the main transaction unavailable. The next action is to create the approval again with the amount in the current Rango-generated payload.
Some bridge routes use a dynamically supplied spender, so the recipient in the latest approval payload matters. MetaMask or Trust Wallet should display that approval as a separate action from the later contract call.
What changes after the wallet submits?
One submitted transaction creates zero confirmed state changes until inclusion; after inclusion, the source network records either an approval or the route's main transaction.
The wallet returns a transaction hash, and Rango associates it with the request ID and current step. A successful approval changes allowance only. A successful main transaction transfers or calls contracts on the source chain; a bridge then produces destination-side activity under its own protocol. Until a main transaction hash exists, an unsigned prompt, rejected signature, or switched network has produced zero on-chain route transactions.
Status tracking exposes three states: running, success, and failed. Cross-chain completion needs the outbound destination transaction as well as a successful source receipt, because the source record alone does not prove delivery of the desired token.
Evidence for verifying each route stage
Five records separate an unsigned quote from a completed cross-chain route, and each record answers a different verification question for the wallet owner.
| Record | What it establishes | Standard count |
|---|---|---|
| Quote request ID | Selected inputs and route | 0 on-chain transactions |
| Approval transaction hash | Allowance change | 1 hash per approval |
| Source main transaction hash | Submitted swap or bridge call | 1 hash per transaction |
| Destination outbound hash | Cross-chain delivery | At least 1 outbound record |
| Indexed route-step status | Result for one route step | 1 status record per step |
| Minimum cross-chain proof set | Source submission and destination delivery | 2 chain-side records |
For EVM records, a transaction hash represents 32 bytes and is commonly written as 64 hexadecimal characters after the 0x prefix. Solana signatures use a different encoding, while Bitcoin identifies a transaction with a 32-byte transaction ID. Rango's status response can also classify the received asset as one of four outputs: desired output, input returned, middle asset on the source chain, or middle asset on the destination chain. Save the request ID beside every hash; the pair connects interface state to the chain records that actually settled. This pairing is especially useful when a bridge finishes after the source explorer first shows success.
A wallet history shows signatures; Rango's route record adds step and destination context.
Recovering from a wrong-network wallet state
One wrong chain selection is recoverable before broadcast because an unsigned transaction has changed zero balances, allowances, or contract state on any network.
The common setup error is an EVM wallet connected to a chain other than the route's source. The address looks valid, yet the wallet rejects the chain context or previews the wrong native gas asset.
Read the source network from the confirmed route, then switch the wallet to its canonical chain ID. Ethereum is 1, Arbitrum is 42161, BNB Smart Chain is 56, Avalanche C-Chain is 43114, and Base is 8453. Confirm that the selected account remains the intended source address after the switch. If the route also requires Solana or Cosmos, reconnect that wallet family rather than forcing an EVM account into an incompatible field.
Return to Rango and request a fresh transaction instead of replaying the payload that was built for the previous network state. Review the input contract, destination address, value, and gas token again. If the wallet never returned a transaction hash, this reset needs no recovery transaction because nothing reached a validator. If a hash exists, stop treating the issue as a network-selection error and verify that hash on the chain whose ID appears in the signed payload.
An account switch after chain correction also changes the source address, so rebuild the route one more time. Compared with manually editing raw transaction fields, regenerating the payload preserves the route's selected spender and destination.
How does Rango progress a multi-step route?
One indexed route step advances only after its required transaction set succeeds, after which Rango creates the transaction for the next step.
Step numbering starts at 1. The interface records each submitted hash against its step, polls until the state becomes success or failed, and proceeds only after success. If an intermediate step runs on Arbitrum and the next starts on Avalanche C-Chain, the wallet must change chain context and hold the native fee asset required there. A route with three executable steps therefore needs at least three main wallet signatures, plus any separate approval signatures.
Single-step aggregation asks for fewer wallet actions by bundling source swap, bridge, and destination swap behind one submitted transaction when the integration supports it. Multi-step execution exposes more checkpoints, which makes each intermediate asset and transaction independently visible.
Failure states, partial outputs, and recovery order
Four output classifications describe where value ended after a route problem: desired output, input returned, source-chain middle asset, or destination-chain middle asset.
A failed status does not by itself identify the final asset. Read the output token, output amount, source and destination explorer records, extra message, and any protocol diagnosis field together. Rango error 1204 means the submitted transaction hash is invalid or mismatched; error 1203 means the service could not retrieve the input or fee-token balance. Error 1301 stops a route when the quoted loss exceeds 18% of the input's USD value.
Recovery depends on location. If the input returned, rebuild from that asset on the original chain. If a middle asset remains on the source chain, route that exact contract from its present network. A middle asset on the destination chain calls for a destination-side swap, not another bridge from the original chain. Affected Wormhole routes expose a diagnosis flow for protocol-specific refund steps; use the existing transaction records so the action matches the recorded state.
Do not submit the original swap again while the first route remains running. Compared with a second route, status resolution preserves one unambiguous set of hashes.
Rango FAQ
Do I need native gas on every chain listed in a Rango route?
Native gas is required on each chain where the wallet must submit a transaction. A single-step route normally spends gas on the source chain, while a multi-step route can require native assets on intermediate chains. ETH pays gas on Ethereum and Arbitrum, BNB pays it on BNB Smart Chain, and AVAX pays it on Avalanche C-Chain. A destination chain that only receives bridged output does not require a user-funded transaction unless the route exposes another executable step there.
Is a fresh Rango quote required after changing the destination address?
A fresh route and transaction payload are required after changing the destination address. The destination participates in confirmation and transaction generation, so an older unsigned payload no longer represents the selected output account. Re-enter the source asset, destination asset, amount, and new address, then compare minimum output and fees again. If a transaction was already broadcast, changing the interface field does not redirect that transaction; its encoded destination remains fixed.
Does rejecting a wallet signature create an on-chain Rango transaction?
Rejecting an unsigned wallet prompt creates no on-chain transaction. The wallet returns no transaction hash, validators receive no broadcast, and balances and allowances stay unchanged. The route quote can still expire, so reopening the flow later should produce a fresh request and transaction payload. An approval that was signed in an earlier prompt is different: once confirmed, its allowance remains a separate state change even if the later swap signature is rejected.
When should a custom destination wallet be entered for a Rango route?
A custom destination wallet belongs in the route before confirmation when the output should arrive at an address other than the connected destination account. The address must match the destination chain's format and the intended token network. Changing it after transaction generation requires a rebuilt payload. For multi-step routes, Rango still needs wallet addresses for every chain that must sign, while the custom destination controls the final output recipient rather than every intermediate signer.
Why can the same token ticker represent a different route asset?
The ticker can remain identical while the contract or mint and network differ. USDC on Ethereum is identified by an ERC-20 contract, whereas USDC on Solana is identified by a Solana mint; the symbols alone do not make those records interchangeable. Compare the network, contract or mint, and decimal precision shown in the route. Selecting the correct token record prevents a valid-looking symbol from sending the route toward an unintended chain-specific asset.
Could destination tokens arrive before Rango shows a completed status?
Destination delivery and interface status are separate observations, so the token balance can update before the route view finishes its next status poll. Verify the destination transaction or token balance, then let the existing request continue to resolve. Do not submit a duplicate route merely because the screen still says running. The source hash proves only the first side; a destination-side record and the expected token contract establish that the bridge output arrived.
Where should I look when Rango reports a middle asset?
Look first at the output classification, received-token contract, amount, and chain attached to the existing route. A source-chain middle asset should be handled from that source network, while a destination-chain middle asset already crossed the bridge and needs a destination-side swap. Save the request ID and every transaction hash before rebuilding anything. Starting from the asset that actually arrived avoids repeating the completed bridge segment or selecting the original input by mistake.