Route an intent where a solver can deliver the requested asset on the destination chain. Compare executable output, total cost and fill time, then submit only while the quote and destination liquidity remain viable. This approach cuts avoidable hops, but a route is useful only if its promised fill can complete before the intent expires.
Executable liquidity means a solver can fill the exact outcome
Executable liquidity is destination inventory a solver can actually spend to meet your intent: the right token, sufficient size, and a viable transaction path to the recipient. A pool’s displayed TVL does not prove that a solver has inventory, can access it at the quoted price, or can execute the required swap before the deadline.
That distinction matters when omnichain applications coordinate balances or state across networks. Cross-chain messages can update application state, token supply and liquidity access as one system; separate multichain deployments may leave each chain’s pools and state independent. For an intent, the practical question is whether the destination can execute the specified outcome, not whether the asset appears somewhere in the network.
Route against the net destination result
Rank candidate routes by the amount the recipient receives after all costs, then use expected fill time and failure handling as tie-breakers. A low bridge fee can be outweighed by a costly destination swap, while a route advertising abundant liquidity can still fail if the solver’s usable inventory is below your order size.
For each quote, compare the same input amount, destination token, recipient and deadline. Include origin-chain gas, solver or bridge fees, destination swap price impact, destination gas if your action requires it, and any cost of moving inventory between chains. Fee and inventory conditions change with utilization and gas, so stale quotes are a poor basis for repeated routing.
In practice, I’d take the best route only if its minimum receive amount clears my required output and its estimated completion time fits the intent’s expiry. The site can be used as a way to discover and execute a route; the decision itself still comes down to those route-specific execution terms.
Use this sequence for each repeated intent
Run the same checks for each order. For a recurring 10,000 USDC transfer from Arbitrum to Base, for example, a direct solver fill may beat a cheaper-looking path that first bridges to a chain with no immediately usable Base inventory.
- Define the outcome. Fix the source chain and token, exact input, destination chain, output token, recipient and any destination call. If the recipient is a contract, confirm that its call can safely run with the amount and token the intent promises; a token transfer alone may not satisfy the application’s state requirements.
- Request fresh route quotes. Query candidates for that exact pair and size, and compare guaranteed or minimum output rather than an indicative mid-price. Treat a quote as short-lived: for a fast-moving or busy route, an illustrative 30–120 second freshness window is reasonable, but use the provider’s actual expiry and refresh before signing if it has passed.
- Check destination inventory and execution. Confirm the solver can fill the full amount and that the destination swap has enough depth at your minimum output. A 10,000 USDC order might fit a deep stablecoin pool but move the price materially in a thinner pool; split only if the added transactions and fees cost less than the price impact you avoid.
- Set slippage and expiry deliberately. Set the minimum output to the least you will accept after destination execution. As an illustrative starting point, a liquid stablecoin swap might use tens of basis points; volatile or shallow routes need a wider tolerance, which increases adverse-price exposure. Give the fill deadline enough time for origin confirmation, solver pickup and destination inclusion—often several minutes, with chain congestion determining the buffer.
- Submit once, then verify the fill. Review the signed chain IDs, token addresses, amounts, recipient, minimum output, deadline and any call data. After origin confirmation, track the intent through its destination fill event or status source; distinguish “submitted” from “filled,” and check whether expiry makes funds refundable or requires a recovery action.
Choose speed with an explicit failure trade-off
A solver can deliver quickly by fronting its own destination-chain inventory, then settle or rebalance later. That avoids waiting for a canonical bridge transfer before delivery, but it depends on solver participation, available inventory, correct destination execution and the settlement design. A route with fewer hops can still be worse if it has a thin fill market or an unreliable fallback.
Routing becomes an omnichain application concern when one action depends on coordinated state or liquidity across chains: the route must deliver tokens and let the application recognize the corresponding cross-chain state. Message-based systems such as an OApp architecture can support that coordination, but they do not make a failed destination call atomic with the origin transaction. Check what happens after a source deposit if the destination action reverts, arrives late or misses its deadline.
The main edge case is a quote that remains visible after the solver’s inventory has been consumed by other orders. Your transaction can confirm on the origin while no solver fills it at the expected speed. Size limits, exclusivity periods, deadlines and refund rules determine whether you wait, accept a changed quote, or recover funds; they are route parameters, not cosmetic metadata.
FAQ
Why can a route with high TVL still fail to fill?
TVL measures assets held in a pool, not inventory committed to your exact intent. The solver may lack the required destination token, the pool may not support the needed swap size at your minimum output, or competing orders may use the available balance first. Evaluate fillable size and execution conditions for your pair, not aggregate pool value.
Should I split a large intent into smaller orders?
Split when each smaller order materially improves fill probability or reduces price impact enough to outweigh additional origin gas, solver fees and operational overhead. Compare the same total input across one quote and several smaller quotes. Also account for partial completion: if only some orders fill before market conditions change, you may hold an unintended exposure.
What does the fill deadline protect me from?
The deadline bounds how long the solver has to deliver under the signed terms. A short deadline limits exposure to stale pricing, but can expire during congestion or delayed finality; a long one improves the chance of a fill while leaving your funds committed for longer. Choose a buffer that reflects both chain conditions and the route’s stated execution time.
What should I do when the destination fill is delayed?
First check the origin transaction and the intent’s current status; a confirmed source deposit is not proof of destination delivery. Then check whether the fill deadline has passed and what the route specifies for expiry, refund or retry. Avoid submitting a duplicate intent until you know whether the original remains fillable, since both could execute.
For frequent routing, keep a small record of quoted output, actual fill time and final received amount by route; it shows when a faster quote is costing you more than it saves.