Cross-chain limit orders should wait for destination funds

A cross-chain limit order should check its price condition after the bridge delivers the destination asset, because those funds cannot be swapped before they arrive. Rango’s API documentation describes a cross-chain route as a source-chain swap, a bridge transfer and a destination-chain swap; an order adds a price condition to that last step.

That sequence separates moving funds from deciding when to trade them. For a practical walkthrough of the transfer steps, see how to complete a Rango Bridge transfer end to end. The limit condition then needs to account for the amount actually received, which can differ from the initial quote after fees or route execution.

When should the destination swap run?

It should run only after the destination chain confirms that the bridged asset has arrived and the limit condition is met. A source-chain transaction confirms that the transfer started; it does not prove the destination funds are ready to trade.

An implementation can track the bridge message or destination transaction, then evaluate the order against the available balance and current executable price. Rango documents a status check for tracking cross-chain transaction progress, including whether the outbound transaction on the destination chain succeeds. That status is one input to execution, not a promise that a particular price will still be available.

What should the limit price protect?

The limit should describe the minimum output the user will accept for the destination asset, after destination swap fees. A displayed market price alone is not enough: the amount available, pool depth, gas cost and route fees affect the executable result.

Before signing, the order should make these terms clear:

• The destination token and network where the order will execute.
• The minimum acceptable output, denominated in the destination token.
• Whether fees are included in that minimum or deducted separately.
• When the order expires and what happens to funds if it does.

Using a strict minimum gives the user price control, but a narrow threshold can leave the funds waiting. A looser threshold is more likely to execute while accepting a worse exchange rate. The better default for most users is an explicit minimum and a visible expiry, rather than an order that waits indefinitely.

What happens if the price never reaches the limit?

If the destination price does not meet the condition before expiry, the order should remain unfilled and return or leave the destination asset under the user’s control. The precise outcome depends on the order contract and bridge design, so the interface should state whether cancellation needs a transaction and which chain requires gas.

Expiry also needs to be measured from a useful point. Starting the clock when the user submits on the source chain can consume part of the order’s lifetime while the bridge is still processing; starting after destination receipt gives the user the full stated window, but requires the system to retain and monitor the pending funds.

What should users check before signing?

Check the destination network, token, minimum output, expiry and cancellation path in the signed order. Then follow the transfer until the destination asset arrives; a source transaction hash alone cannot show that the limit order is ready to execute.

The core trade-off is straightforward: waiting can protect the sale price, but it cannot guarantee execution. A sound cross-chain limit order makes the bridge leg, the destination price condition and the handling of an unfilled order visible as separate parts of one transaction flow.