Rango
Rango routing connects swap output and execution time to the selected path
Rango routing selects swap paths across DEXs and bridges, with quoted output and estimated execution time shaped by each path. Comparing alternatives requires the same input asset, amount and destination asset. Liquidity, provider restrictions and required wallet actions can change which route is usable.
· updated
Bottom line: Additional signatures and intermediate-chain fee funding can make a higher-output route harder to complete within the intended timeframe.
Route Preview and Quote Refresh
Route selection normally begins with a quote; a stale preview needs a fresh quote before any swap transaction is signed. The preview describes a possible path for the requested assets and amount, using the pricing available when the request runs. Waiting can change both the amount offered and the available path. Get Best Route can return a preview without checking balances or fee funding; confirmation through that method requires prerequisite checks before transaction creation.
A fresh quote before signing doesn’t cancel or retry a transaction already submitted. An in-progress swap requires its own transaction status and continuation handling.
Aggregated Swaps and Multi-Step Paths
Aggregated paths combine supported operations, while multi-step paths expose separately executed route steps with their own wallet requirements.
Single-Step Aggregation
The Basic API returns a single-step route preview. A decentralized exchange (DEX) supplies token conversion; a bridge supplies the cross-chain transfer. Rango can combine a token swap and bridge transfer into one user-submitted transaction where the route supports aggregation. A combined path still has cross-chain processing to complete. Token approvals or receiving-network prerequisites can require additional setup before the main swap transaction.
Separately Executed Steps
The Main API can return alternative routes containing multiple steps. Intermediate chains expand the paths available for the requested conversion and introduce requirements beyond the initial transaction. A higher output estimate can therefore come with additional wallet involvement, depending on the chosen path.
Fee Funding Along the Path
User-signed transactions on intermediate networks need their required network fees. The available source balance alone doesn’t establish that every later transaction has funding. When prerequisite checks run, route validation compares required assets with each selected wallet’s available balances.
Signing Between Steps
Later route steps require their own transactions, created after the preceding step succeeds. Additional approvals or bridge-specific actions can increase wallet involvement. The visible number of route steps doesn’t establish a universal signature count.
Quoted Output and Additional Wallet Costs
Quoted output describes the destination asset the route expects to deliver, while separately funded fees affect the balances needed to execute it. Rango fees and provider charges matter here through their effect on output and wallet funding. Fee entries distinguish charges taken from the source wallet, deductions from output and charges taken from the destination wallet. A fee deducted from the quoted output has already affected that amount; subtracting it again understates the quote. The Basic API also reports expected output and minimum output as distinct quote fields.
A network fee paid in a different token can’t be subtracted directly from the destination-token quantity. Compare output in the same destination asset, then account for separately paid fees on a consistent basis. Additional network costs can consume the benefit of a higher output quote. Transaction creation can specify a gas limit above the quote’s estimate to allow execution headroom. That limit isn’t a statement of eventual gas consumption.
What Determines a Route’s Execution Time?
Route execution time depends on blockchain confirmation, bridge processing and any wallet actions the selected path requires. A short displayed estimate doesn’t establish a fixed arrival deadline.
Rango’s quote data expresses estimated execution time in seconds, and multi-step results include timing estimates for individual steps. These estimates help identify which part of a path carries a delay. A single-step route can include several underlying operations, so counting displayed steps doesn’t determine its duration. The bridge’s processing requirements remain relevant even when aggregation reduces the number of user-submitted transactions.
Wallet involvement affects elapsed time because later steps wait for their required transactions to be authorized and submitted. A quoted duration doesn’t establish how quickly someone will sign that transaction. Some multi-step results include minimum, average and maximum timing statistics; these values offer comparison context when present without imposing a hard completion limit.
Route-search latency is separate from swap execution time. Waiting for a quote happens before the transactions described by that quote begin.
Provider Filters and Intermediate Chains
Provider and chain filters define which paths Rango may consider before comparing their output and execution requirements. Rango routing requests can exclude specified swap providers from the eligible routes. Inclusion filters can also limit the candidate set. Chain restrictions matter especially for multi-step paths because an intermediate network may supply the conversion or bridge connection. Removing that network can remove the path, even when the source and destination remain supported. A filtered quote’s preferred route reflects the allowed paths and available pricing.
Transaction-type filters let an integration restrict the technical transaction formats it supports. Provider-group filters apply restrictions across related liquidity sources. These settings can affect both route availability and the best output within the allowed set. Embedded swap interfaces can carry their own liquidity-source restrictions, so an interface’s presentation doesn’t establish the full routing scope.
Output and Time at Route Selection
A route with a shorter time estimate is a viable choice only while its output and execution requirements remain acceptable. Suppose a route list offers a higher-output path and another path with a shorter time estimate. Both use the same input amount and the same source and destination assets. Their quoted amounts and durations can change; the requirement to fund the necessary transactions remains.
- Match the source and destination asset identifiers, including their blockchains, across both quotes.
- Compare expected output and any minimum-output protection supplied for the selected route.
- Separate output deductions from fees requiring additional source or destination balances.
- Account for intermediate-chain fee funding and later wallet signatures.
- Compare refreshed output and timing under the same provider restrictions.
If the refreshed output of the path with the shorter time estimate falls below the amount acceptable for the intended swap, its earlier estimate no longer supports that choice. The higher-output alternative remains a candidate only if its own updated quote meets the requirements. Main API route confirmation returns an updated route and wallet validation data. An
ok
value of true confirms route selection; the balance checks show whether required assets are available. Transaction creation follows only when the updated terms and funding checks permit it.
Slippage Tolerance and Price Impact
Slippage tolerance defines acceptable variation during execution, while price impact describes how a trade affects the pricing available from liquidity. Rango uses the requested slippage tolerance to filter unsuitable providers or routes. A tighter tolerance can reduce the eligible set. Increasing tolerance allows more execution variation, which changes the minimum-output protection associated with a quote. It doesn’t replenish liquidity or establish that a previously unsuitable path will become available.
For pool-based swaps, the input amount relative to available liquidity affects price impact. This can change the preferred route as trade size changes. The Basic API can return a high-impact warning and block transaction creation for an unsuitable quote. A high-impact warning requires reassessment before signing, even when the expected output appears competitive.
Confirmed Routes and Transaction Readiness
Route confirmation returns updated information for the chosen Main API request, so the preview’s amounts need another comparison before execution. A route selected from alternatives is confirmed using its request identifier and the wallets chosen for the involved chains. The returned validation data describes required balances and fees.
The Basic API’s transaction-creation response contains a final quote alongside transaction data or an error. Any supplied receiving-network prerequisite must be completed before the main source transaction is submitted. Route status and transaction creation describe different states, so both matter when assessing readiness. A Basic API response can contain an
OK
route and still report a transaction-creation error.
Practical questions about Rango routing
Which Units Does Rango Expect for a Routing Amount?
Basic API amount inputs use the token’s smallest units, while Main API routing inputs use human-readable token amounts. An integration must follow its selected endpoint’s format and the asset’s decimal precision. Comparing raw amount strings across APIs can misstate the input size and distort the output comparison, even when the selected asset is the same.
Does maxLength Limit Every Transaction a Route Requires?
maxLength limits the steps Get Best Route may return. It doesn’t impose a universal cap on approvals or every transaction inside a bridge step. Route metadata and transaction responses describe additional requirements. A shorter route can therefore involve another wallet action, and its step count alone doesn’t determine the time spent authorizing transactions.
What Does INPUT_LIMIT_ISSUE Mean for a Rango Quote?
INPUT_LIMIT_ISSUE means the requested amount doesn’t meet the selected quote’s amount restrictions. The returned limits identify the applicable minimum, maximum and whether a boundary is inclusive or exclusive. Those restrictions belong to that route. Applying one route’s limit to every alternative would misrepresent the options; a different amount needs its own output comparison.
Why Do Two Apps Using Rango Show Different Route Quotes?
Apps can send different routing settings or integration fees to Rango, producing different eligible paths and output quotes. Requests for the same token pair can also differ in input amount, slippage tolerance or quote time. Differences in API mode can also affect whether an app requests only single-step paths or multi-step alternatives.
Are Centralized Providers Included in Rango Routing by Default?
Centralized providers are disabled by default in the Rango API and require enableCentralizedSwappers to be enabled. Enabling them also requires the user’s IP address for compliance checks. A provider’s screening may hold funds for identity verification if a wallet is flagged as risky. Their routing eligibility therefore involves conditions beyond quoted output and speed.
Will a contract-based Swap Have the Same Eligible Providers?
Contract-based execution can have a different eligible-provider set because some protocols cannot accept calls from another contract. Rango’s contractCall option filters unsuitable providers. The integration must also respect any underlying protocol’s contract allowlisting requirements. An incompatible contract call can leave funds stuck, so a quote for regular-wallet execution doesn’t establish contract-call compatibility.
Can avoidNativeFee Remove All Gas Funding Requirements?
avoidNativeFee excludes swappers that charge service fees in native tokens; it doesn’t waive blockchain network fees. The setting can shrink the eligible route set because provider fee-payment designs differ. A selected route still needs the transaction funding its returned requirements specify, even after native-token service fees have been excluded from the candidate providers.
Why Can Finding a Rango Route Take Longer Than Expected?
Route discovery depends on live pricing responses from external providers, so slow or missing replies can delay a quote. That delay is separate from estimated swap execution time. Main API can report processingLimitReached when the search reaches its processing limit without finding a route. This warning describes route discovery and doesn’t establish that a blockchain transfer has begun.