Mayan finance lets you compare cross-chain swap routes before authorizing a swap

Mayan finance lets you compare cross-chain swap routes before any order is signed. The best fit is not always the route with the largest expected output: the source asset, destination wallet, minimum output, settlement mode, deadline, fee entries, and refund asset can all change whether a route fits the task. Read those terms together, keep the transaction unsigned while a mismatch remains, and commit only when the quoted destination and recovery path are both acceptable.

- updated

In short: A suitable route matches the intended output, applicable output floor or guarantee, deadline, wallet, and refund path before the source transaction is authorized.

Set the inputs that can redraw the quote

The source chain, input token, amount, destination chain, output token, slippage setting, and receiving address establish the request that each route must satisfy. Optional settings, including gasless execution and destination gas, can also affect route availability or quoted terms. Support for two individual networks or tokens does not establish support for every combination between them.

Compare routes generated from identical inputs. Changing the amount, slippage, destination address, fee configuration, or gas request creates a different decision, even when the token pair looks unchanged. Request fresh terms after such an edit and discard the earlier comparison. Otherwise, one route may appear stronger only because it answers a different request.

Check source readiness and destination compatibility

Readiness requires enough input balance, a receiving address valid for the destination chain, and the authority to sign from the source wallet. A normal source transaction also needs the chain native token for gas unless the selected quote supports gasless execution. An ERC-20 input may require an allowance before the swap transaction, but that approval does not execute the quoted route. Keep the swap unsigned until the destination address and source requirements are settled.

Five fields frame the route decision

Five quote fields expose the most important boundaries without relying on a route label or headline output alone.

Quote parameter Value to read Timing or outcome
expectedAmountOut Expected destination output An estimate in mode 2 and the fixed output in eligible mode 3 quotes
minAmountOut Signed output floor A mode 2 order cannot fill below this amount
swiftAuctionMode Mode 2 or mode 3 Distinguishes bounded variable output from eligible exact-out settlement
deadline64 Order deadline timestamp After the deadline, an unfilled order becomes refundable rather than fillable
refundRelayerFee Quote-specific refund cost Applies if the unfilled order needs an onchain refund action

Read the five rows as one route record. The expected amount does not replace the signed floor, and the deadline is not a promised completion time. A refund fee also matters before execution because it changes the cost of leaving an order that does not fill. Comparing isolated values hides those relationships.

What makes one quote better for this swap?

The better quote is the one whose execution and recovery terms fit the intended transfer. Compare expected output, protected minimum, price impact, deadline, fee entries, destination gas, and refund terms under the same request. A larger estimate may carry a lower acceptable floor or a deadline that leaves too little time to review and authorize the transaction.

Settlement mode changes the meaning of the displayed numbers. A mode 2 Swift quote protects minAmountOut while the final output cannot fall below that floor and may be higher or lower than expectedAmountOut. An eligible mode 3 quote treats expectedAmountOut as the exact output. Neither mode removes the need to check addresses, timing, and the asset returned if execution fails.

Route architecture changes the trade-off

Swift, MCTP, Fast MCTP, and Wormhole Swap reach the destination through different settlement mechanics. The route name therefore explains how value moves, while the live quote supplies the terms that belong to the individual order.

Swift uses an intent-based process. The source contract locks the input, and drivers compete to deliver output from liquidity they already hold on the destination chain. For ordinary transfers, the winning driver pays the recipient before later reimbursement from the source-side funds. Payload-enabled swaps instead stage the payout and complete it after the payload is validated. If the protocol converts the input into a primary locked asset first, a refund can return that converted asset.

MCTP, the Mayan-Circle Transfer Protocol, converts the source-side input to USDC and moves the USDC through Circle Cross-Chain Transfer Protocol. Drivers then compete to convert it into the requested output on the destination chain. Its quoted output and recovery conditions still determine whether it fits the request. Fast MCTP follows the same flow through Circle CCTP v2 but appears as a separate route in the quote.

Wormhole Swap sends value through the Wormhole Token Bridge and carries swap instructions through cross-chain messaging. Drivers compete on Solana, and the winning path uses an atomic swap before delivering the promised output. This mechanism differs from the destination-liquidity model used by Swift and the USDC-based transfer path used by MCTP.

Architecture alone does not establish the best outcome. Network support, available liquidity, the requested amount, and live execution conditions can change the candidates. Compare routes returned for the same request, then use the route mechanism to understand settlement and recovery rather than to predict an amount that the quote already states.

Guaranteed output changes which number matters

Guaranteed Price appears through quote eligibility rather than a setting you switch on. A mode 3 Swift quote fixes expectedAmountOut, so that value is the amount intended for delivery. Mode 2 keeps minAmountOut as the enforceable floor and leaves room between the protected minimum and expected output.

The guarantee covers output amount, not timing. An exact-out order can still pass its deadline without a driver fill and move to the refund path. Check swiftAuctionMode on every candidate because a route that qualifies for mode 3 in one request does not establish that another amount, asset combination, or later quote will qualify. Current Guaranteed Price eligibility is limited to supported same-asset transfers of USDC, USDT, or ETH; other same-asset transfers and cross-asset swaps do not qualify.

Costs and destination gas belong to the live route

Cost comparison begins with the delivered output and every fee returned with that quote. Source transaction gas, protocol charges, referrer fees, refund relayer costs, and price impact describe different effects. Price impact concerns the execution rate on the relevant market, while a fee is an explicit charge. Combining them under one percentage obscures what can change.

Destination gas is a separate delivery choice for supported routes. It can place native gas tokens in the receiving wallet for a later transaction, which may matter when that wallet has none. Adding or changing the request calls for a fresh quote because the output and fee record must match the selected gas amount. Do not hardcode a protocol fee or gas allowance when the route response provides the applicable value.

Authorizing the swap changes the available options

Before authorization, you can revise the amount, chains, tokens, address, slippage, and optional settings, then request another quote. After the source transaction or signed order enters execution, those values become conditions of that order. The destination cannot be edited in place, and a less attractive live quote cannot replace the terms already signed.

An ERC-20 approval, when required, is a separate permission and should be reviewed as such. The swap transaction or order signature commits the selected route. After that point, the valid actions narrow to tracking the existing order, confirming its terminal state, or following its refund path.

When should you stop instead of signing?

Remain unsigned whenever a route term does not match the intended delivery or an important recovery condition is unclear.

Stopping here leaves the request editable. Correct the input, refresh the quote, and compare the replacement on its own terms. A successful refresh does not repair an earlier signed order; it creates a new candidate that remains independent until authorized.

Completion and refund require different evidence

A route reaches the intended end state only when its terminal status and the relevant chain balances agree. Mayan Explorer can locate a swap through its source transaction hash or wallet address. A completed status should correspond with the expected destination delivery. A pending state calls for continued tracking, not an assumption based on elapsed time.

Every order carries a deadline after which it becomes refundable rather than fillable if no driver has completed it. A refunded status should correspond with value returning on the source side. For Swift, that return can be the primary locked asset when the route converted the original input before opening the order. Confirm the actual returned asset before planning another swap.

Later actions change the route criteria

A payment places more weight on an eligible exact-output quote, while a follow-on transaction may make destination gas useful. Payload-enabled application actions add their own route support and settlement conditions. Those later uses should influence the comparison before signing, yet they do not replace the terminal evidence for the swap itself. A completed cross-chain delivery also does not prove that a separate destination application will accept the asset or execute the next action.

Later actions change the route criteria: A payment places more weight on an eligible exact-output quote, while a follow-on transaction may make destination gas useful.; Payload-enabled application actions add their own route support and settlement conditions.; Those later uses should influence the comparison before signing, yet they do not replace the terminal evidence for the swap itself.; A completed cross-chain delivery also does not prove that a separate destination application will accept the asset or execute the next action.

View image file

Good to know

What changes when destination gas is added to a quote?

Destination gas becomes part of the requested delivery, so the revised request needs its own quote. It can help when the receiving wallet lacks the native token needed for a later transaction. Compare the new expected output, minimum output, fees, and gas amount against the version without that option. The setting does not establish that every route supports the same amount or that a later application will accept the swapped asset.

Does a mode 3 quote remove the refund deadline?

No, mode 3 fixes the eligible output amount rather than the completion time. The order still carries a deadline, and it can move to the refund path if no driver fills it in time. This distinction matters because exact-out settlement protects the delivered amount only when the swap completes. Read the deadline and refund terms even when expectedAmountOut is locked.

Why should the refund relayer fee be read before signing?

The refund relayer fee shows a cost that can apply if an unfilled order needs an onchain refund. It is part of the downside of committing to that route, even though the preferred outcome is successful delivery. Compare it alongside the deadline and possible refund asset. A strong expected output may be less suitable when the recovery terms do not fit the transfer.

When should an unsigned route comparison be refreshed?

Refresh the comparison after changing any input that defines the request or when the quote is no longer timely enough to authorize safely. Changes to the amount, chains, tokens, receiving address, slippage, destination gas, or fee settings can alter available routes and their terms. Treat the replacement as a new comparison. Do not combine an expected output from one quote with the minimum or deadline from another.

Is Guaranteed Price selected by increasing the slippage setting?

No, Guaranteed Price is not enabled by raising slippage or setting a separate toggle. Eligibility appears in the returned quote, where swiftAuctionMode value 3 identifies exact-out settlement. A mode 2 quote still uses minAmountOut as its protected floor. Check the field for each route because eligibility can differ between requests and does not remove the order deadline.

Where does a Swift refund land after the input was converted?

A Swift refund returns on the source side, but it can return the primary locked asset instead of the token originally supplied. Swift may convert the input before opening the order, typically into USDC or ETH. If the order later refunds, that converted asset is what the sender receives. The possible return asset should therefore be acceptable before the route is signed.

Are price impact and protocol fees measuring the same thing?

No, price impact and protocol fees describe different costs. Price impact reflects how execution affects the rate available for the requested trade, while a protocol fee is an explicit charge associated with the route. Source gas, referrer fees, and refund relayer fees are separate again. Read each item from the same live quote so the comparison does not hide one cost inside another.

Do route names predict the final amount without reading quote fields?

No, a route name describes settlement architecture rather than the exact result for an individual request. Swift, MCTP, Fast MCTP, and Wormhole Swap identify distinct route types, but amount, liquidity, network support, and live conditions still shape each quote. Use expectedAmountOut, minAmountOut, settlement mode, deadline, and fee entries to compare outcomes. The route type then explains how execution and recovery proceed.