Set one minimum result for the whole order. Then compare each cross-chain route against that same limit after fees and execution.
This matters when you split a frequent trade across networks to find liquidity. Separate price checks can each pass while the combined trade gives you less than you require.
Set the limit for the complete trade
A shared limit is a single minimum rate or output amount that every fill must satisfy together. It keeps a split order within your price rule even when its pieces land on different chains.
- Choose the asset pair and amount. State what you will spend and what you want to receive.
- Set a minimum net output. Count execution costs before deciding the least you will accept.
- Choose whether partial fills count. Decide if one completed piece is useful when the other cannot meet the limit.
- Set an expiry. End the order after a time that fits the asset’s volatility and your need for speed.
For example, say you route 1,000 USDC across two networks to buy token X. You require at least 970 X after fees. If one route returns 610 X and the other 380 X, their combined 990 X clears the shared limit.
If the second route returns only 350 X, the total is 960 X and fails the rule. A 610 X fill might still settle if you allowed partial fills, but only if the order defines how that piece is priced and paid.
Do not confuse this with a slippage setting. Slippage usually limits movement from a quote; a limit sets the worst rate you accept. For a split order, write the rule in the output token or as a minimum average rate across all accepted fills.
Compare routes after costs and settlement rules
Rank routes by the amount you expect to keep, not by the pool’s headline rate. Include pool fees, price impact, bridge or messaging charges, solver charges, and gas on every chain that needs a transaction.
A route can look cheaper but take longer if it waits for several transactions in sequence. Parallel fills may finish sooner, yet a slow or failed leg can leave the order partly complete. Check whether the design waits for every leg, accepts partial settlement, or refunds the remaining input.
The key edge case is a late fill after prices have moved. Each leg needs a local execution check, while settlement must also enforce the order-wide minimum. Without both checks and a defined failure path, one leg could execute at a poor rate while another never arrives.
Cross-chain messages coordinate actions on separate networks, where one transaction cannot usually roll back another. In an omnichain design, messages can coordinate application state and access to liquidity across chains; a multichain setup may keep separate state and pools. LayerZero’s OFT documentation describes token movement through burn or lock on the source and mint or unlock on the destination. ERC-7683 from the Ethereum Improvement Proposals describes a common way for solvers to read and fulfill cross-chain orders.
For an active trader, keep the workflow simple: compare the net quote, confirm that its minimum applies across all fills, then submit only while the quote remains useful. A shared limit can protect price, but it cannot guarantee a fill. Tight limits may leave an order waiting or partially filled, especially when liquidity is thin.
Is a shared limit the same as slippage tolerance?
No. Slippage tolerance usually measures how far execution may move from a displayed quote. A shared limit defines the minimum acceptable result for the whole order. For split routes, check that the limit includes all accepted fills and the costs you intend to count.
Should I allow partial fills?
Allow them when a smaller position still helps and the order clearly prices each piece against the same rule. Reject them when you need the full amount for a later trade or transfer. In either case, know what happens to unspent input if a remaining route fails or expires.
Why can the best quoted route be slower?
It may depend on a message or transaction that must finish before the next step begins. A route using liquidity on several chains can also wait on the slowest leg. Compare expected completion time alongside net output, and decide whether the extra wait is worth the saving.
What should I check before reusing a route?
Confirm the output token, fee treatment, partial-fill rule, and expiry each time; quotes and available liquidity change. The omnichain context helps explain how applications coordinate state and liquidity across networks. My practical tip: save your preferred minimum as a net output amount, then adjust it when the order size or market changes.