Mayan finance links route inputs to cross-chain swap execution and recovery

Route inputs define route-specific execution terms

A quote translates the requested asset move into one or more executable route records. Each record ties a route type to an expected output, a protected minimum, a deadline, and the costs or options that apply to that path. Changing the amount, either chain, either token, slippage, gasless setting, or destination-gas request can change the available routes or their terms.

Before the quote

Support must exist for the complete combination, not merely for each network or token in isolation. The source wallet needs the input balance and, unless the quote supports gasless execution, enough native token for the source transaction. A receiving address must also be valid for the destination chain. These conditions belong ahead of route comparison because a favorable output is irrelevant when the transaction cannot be authorized or delivered.

Review the selected route

The route record becomes the basis for the transaction or order that the user reviews. Swift expresses an intent that drivers compete to fill, while other route families carry value through different cross-chain mechanisms. The signed terms establish the output floor and the time boundary for that order.

The commitment boundary

Signing authorizes the source-side action. Depending on the token and route, that action may lock funds, use an existing allowance, consume a permit, or begin a transfer through the route’s underlying mechanism. You can refresh the quote before signing. After submission, a later quote does not rewrite the open order.

Verify the terminal result

Completion is an observable state, not an inference from elapsed time. Tracking distinguishes an order that is still progressing from one that completed or refunded. The destination balance and terminal status should agree before any follow-on action begins.

Check prerequisites before the first signature

Readiness depends on the chosen entry path. A connected-wallet swap requires a compatible source wallet, a destination address, sufficient input, and any source-chain gas or token authorization that the route needs. An ERC-20 input may require an allowance for the forwarding contract, although an eligible EIP-2612 permit can replace a separate approval transaction.

A permanent cross-chain deposit address follows a different path. It can receive a supported token without connecting the sender to the receiving application, then deliver the configured output token to the chosen destination. The deposit must also meet the live minimum for that source token; a smaller deposit can be detected without settling. That address is derived from its destination settings, so changing the receiving wallet, destination chain, or output token produces a different address. Validation should happen before the address is shown or reused.

Address format deserves an explicit check because a valid address on one network does not establish that it belongs to the intended recipient or chain. The source asset, amount, and destination details should match the order or transaction shown for signing. If the wallet shows different transaction data, the safe decision is to stop before authorization.

Which quote fields change the result?

The fields that change the economic result are the amount, asset pair, source and destination chains, slippage setting, route type, fee settings, and any destination-gas request. The receiving address changes delivery, while the deadline limits how long that particular order can remain fillable. Applications may return several route records for one request because each available path has its own output and execution terms.

Expected output is the route’s quoted estimate or promised amount under its mode. Minimum output is the floor encoded into the order. They answer different questions: one describes the anticipated delivery, and the other defines the lowest acceptable fill. A guaranteed-price Swift quote makes those values equal; other auction modes can finish above the minimum when competition produces a better fill.

Slippage may be supplied in basis points or resolved automatically for the pair. A wider setting can make execution easier during price movement, but it also lowers the protected boundary when the quote is built. Destination gas is another separate input. It requests some native token on the receiving chain for later transactions, subject to the route and the live maximum returned with the quote.

View image file

Three route families expose different settlement paths

Route names matter because they describe distinct settlement mechanics, not cosmetic versions of one transfer. Availability comes from the returned quote for the requested pair and chains. A route that appears for one combination may not appear after any of those inputs change.

Swift usually represents the intent-based auction path. MCTP fits routes that can use native USDC as the transfer asset, while Wormhole Swap follows the Token Bridge path. Compare each live record’s expected output, protected minimum, deadline, fees, and refund terms before selecting a route.

Minimum output sets the fill threshold

A signed order cannot fill below its recorded minimum output; it is refunded instead. This floor does not ensure that a driver will fill the order. It defines the lowest acceptable output before the deadline.

Expected output should therefore be read beside the minimum, not in place of it. In a guaranteed-price Swift mode, the expected and minimum amounts match, so the displayed amount is the delivery amount for a successful fill. In other modes, a successful auction can deliver more than the minimum. The signed floor remains the enforceable boundary.

A fresh quote can move both values because market conditions and route availability change. You can refresh before signing without opening an order. Increasing slippage solely to preserve an older expected output changes the protection level; it does not preserve the old market state.

Fees belong to the live route record

Total cost can combine several components with different recipients and timing. A route may expose a protocol fee, a source-chain transaction cost, a relayer component, or an optional referrer fee. A destination-gas request also changes what the route must deliver. Comparing only the headline output can hide a meaningful difference between otherwise similar records.

Protocol charges vary by route, so the returned fee fields are more dependable than a memorized percentage. Source-chain gas can also move before execution because it belongs to the network transaction. Refunds have their own relayer fee fields, which make the recovery cost visible before commitment. These values should remain paired with the quote that produced them.

The destination-gas maximum is likewise quote-specific. Integrations should read the live ceiling instead of hardcoding an example from documentation. Requesting no destination gas may leave the receiving wallet unable to make an immediate follow-on transaction, while requesting it is unnecessary when the wallet already holds enough native token.

Track a delayed swap through completion or refund

A delay does not identify a failure by itself. Every order carries a deadline, and an unfilled order becomes refundable after that point. Before the deadline, the order may still be in progress. After it, the order cannot fill and moves toward the source-side refund path.

Check the order status before choosing the next action. An in-progress state calls for continued tracking, a completed state calls for checking delivery on the destination, and a refunded state calls for checking the source wallet. Repeating the swap while the first order remains open can create a second commitment rather than repair the first one.

The returned asset can differ from the original input on Swift. If the input was converted into the route’s primary locked asset before the auction opened, the refund returns that converted asset. The refund is also an onchain action with a relayer cost. Both the possible return asset and refund-related fee belong in the pre-sign review, especially when time sensitivity makes a retry unattractive.

The next decision is to sign, refresh, or exit

A route is ready to sign only when its destination details, delivered asset, expected amount, minimum output, deadline, and fee fields match the intended transfer. If any field no longer fits, requesting a fresh quote preserves the option to compare again without opening an order. If no returned route meets the requirement, exiting is a valid end state.

Once signed, track that order to completion or refund using its source transaction or order identifier. Do not treat a newer quote as an update to it. The terminal state determines the next action: use the delivered asset, reconcile the returned asset, or prepare a separate quote with revised inputs.