Mayan finance shows which swap terms can change before settlement

Mayan finance uses the quote as the editable stage of a cross-chain swap. Before the order or source-chain transaction is authorized, the amount and route settings can be revised with fresh terms, while receiving and refund addresses can be corrected before execution. After submission, the signed minimum, deadline, and destination become execution conditions rather than settings to edit. The remaining choices are to track the order to completion, wait until it becomes refundable, or verify a returned source-chain asset.

- updated

The short version: A quote can be refreshed before authorization, while a submitted order must be tracked to completion or refund.

Assemble the quote before the first commitment

First, confirm that the selected chains, tokens, amount, route, and addresses describe the intended transfer before signing the swap transaction or gasless order.

Inputs that produce a route

A quote request combines the source and destination chains, input and output tokens, amount, slippage setting, and optional destination gas. The response can contain several routes with different execution terms. Support for each token or chain in isolation does not establish that the complete combination is available. Changing one input can alter the routes, expected output, protected minimum, deadline, or fees returned by the next request.

Authorization on the source chain

The source wallet needs the input balance and, unless the selected quote supports gasless execution, enough native token for the source transaction. For a non-gasless EVM swap, an ERC-20 input may require an allowance for the Mayan Forwarder; a gasless Swift quote can use a permit for the Mayan Swift contract instead. That allowance is separate from the swap authorization. It permits token movement up to the approved amount, while the later order carries the destination and settlement terms.

Delivery and refund addresses

The execution call identifies the destination wallet and, for supported Swift orders, may identify a separate source-chain refund address. Both addresses belong before the commitment boundary. A correct destination must match the destination chain, and any custom refund address must be valid on the source chain. If either address is wrong, stopping before submission remains the clean exit; changing a submitted order is not the repair path.

Three quote fields mark the settlement boundary

These fields define when a fill remains valid, which output is protected, and whether the amount is fixed.

Three quote fields mark the settlement boundary
Quote field Documented value Effect on settlement What must already exist
deadline64 A timestamp carried by the quote An unfilled order becomes refundable after this time A current route quote
minAmountOut The protected output amount A standard order cannot fill below this amount A selected route and output token
swiftAuctionMode 2 or 3 Mode 2 uses a minimum; mode 3 fixes exact output An eligible Swift quote

The three values must be read from the same quote. Combining the deadline from one response with the amount from another would no longer describe one executable order. On a Swift quote with swiftAuctionMode 3, expectedAmountOut is the exact settlement amount. That guarantee covers the output amount, not the time of delivery. An unfilled exact-output order can still reach its deadline and refund.

Fresh terms replace stale choices before submission

A revised request creates another possible order; it does not update an order that already exists.

Request fresh terms after changing any decision that affects execution:

Expected output, minimum output, fees, and the deadline can all differ in the replacement response. Compare the complete new route before authorizing it. The receiving address and any supported refund address also deserve a final review at execution time, even when they do not change the quoted price. A later quote has no effect on a transaction or gasless order that has already been submitted.

Which choices remain reversible after submission?

Before submission, the transfer can still be abandoned, requoted, or redirected; after submission, the tracked order retains its signed terms.

Before source submission

The transfer can be abandoned, requoted, or redirected only before the source transaction or gasless order is submitted. A separate ERC-20 approval may remain onchain even when the swap stops, because approval and execution are different transactions. The approval receipt therefore does not prove that Mayan received an order. Confirm whether the swap transaction or gasless order was actually submitted before starting another attempt.

While the order is in progress

An INPROGRESS status means the order has not reached a terminal outcome. Refreshing the quote, changing the wallet display, or preparing a second route does not amend it. The existing hash should remain the tracking key. Sending the input again can create another order rather than accelerate the first one, so do not resend solely because the order is taking longer than expected.

After a terminal state

A COMPLETED order has delivered its settlement outcome, while a REFUNDED order has followed its source-side return path. Neither state can be changed by obtaining another quote. A new transfer starts with new terms only after the terminal result has been reconciled against the appropriate chain records.

What proves that the swap has settled?

Settlement requires a terminal COMPLETED status that agrees with delivery on the destination chain.

A source transaction hash identifies a transaction to check, but only a successful chain receipt confirms source-side execution; neither one proves destination delivery. Gasless Swift execution can return an order hash instead of a transaction response; that identifier can still be used for tracking. The clientStatus field distinguishes INPROGRESS, COMPLETED, and REFUNDED. Match the terminal status with the destination recipient, token, and received amount before using the output in another transaction.

Payload-enabled Swift swaps require a separate destination check. The SDK forwards the payload bytes without validating or decoding them, so the destination logic must parse them. Payload delivery alone does not prove that the intended destination action succeeded. Verify both the terminal swap status and the resulting destination state rather than relying on the first cross-chain message or a loading indicator.

Refunds follow the source-side locked asset

A refund is the terminal path for an order that no driver fills before its deadline.

If Swift converted the input into its primary locked asset before the order opened, a refund returns that locked asset rather than the original input token. This distinction matters during reconciliation because the source wallet may show a different asset from the one first submitted. The quote also exposes the refund relayer fee, since returning funds is an onchain action rather than a free reversal.

Swift normally returns a failed order to the wallet that initiated it. A supported integration can provide a different valid source-chain refund address, subject to route and execution constraints. Gasless Swift orders from an EVM chain always refund to the swapper, and other route types ignore the Swift-specific custom address. The applicable exit path must therefore come from the submitted route, not from a preference entered after submission.

Reconcile the terminal state across both chains

The quote records the acceptance conditions, while chain activity shows which state changes actually occurred.

Completion evidence

For a standard Swift order, compare the received output with minAmountOut; the final amount may be higher. For an exact-output order, compare it with expectedAmountOut. The tracking status, destination address, token, and amount should describe the same outcome. A wallet interface can lag or hide an unfamiliar token, so a missing display entry alone does not overturn a destination transaction record.

Refund evidence

A REFUNDED status should correspond to a return on the source chain at the applicable refund address. Check the returned asset as well as the amount because Swift may have locked a converted asset before the auction began. Account for the quoted refund relayer fee when reconciling the balance. Nonarrival on the destination chain does not prove a refund until the tracker and source-side return show that terminal path.

Choose the next valid action from the observed state

The tracking state determines whether to wait, reconcile, or begin again with a new quote. Before submission, declining the authorization or replacing the quote is a reversible stop. While the order reports INPROGRESS, keep its transaction or order hash and continue tracking instead of creating a duplicate. A COMPLETED state leads to destination-side reconciliation. A REFUNDED state leads to source-side reconciliation, including the returned asset and relayer fee.

Choose the next valid action from the observed state: If no tracking record appears, first establish whether the source transaction was accepted or whether the gasless order produced a valid order hash.; Retry without waiting for a terminal state only after confirming that neither a source transaction nor a gasless order was submitted.; Once completion or refund is visible, any further transfer is a separate decision with a fresh deadline and newly reviewed terms.
Visual summary: Choose the next valid action from the observed state.

View image file

If no tracking record appears, first establish whether the source transaction was accepted or whether the gasless order produced a valid order hash. Retry without waiting for a terminal state only after confirming that neither a source transaction nor a gasless order was submitted. Once completion or refund is visible, any further transfer is a separate decision with a fresh deadline and newly reviewed terms.

Mayan finance questions, answered

Does an ERC-20 approval commit the quoted Mayan finance swap?

No. An ERC-20 approval authorizes its named spender to transfer up to the approved allowance. Standard swaps use the Mayan Forwarder, while a gasless Swift permit targets the Mayan Swift contract. It does not choose a destination chain, recipient, output token, minimum output, or deadline. The later swap transaction carries those terms. If the approval succeeds and the swap is never submitted, the allowance can still remain on the source chain, so it should not be treated as evidence that an order exists.

Where does a gasless Swift refund return?

A gasless Swift order from an EVM chain refunds to the swapper address that signed the order. The SDK rejects a different custom refund address for that case. For a regular Swift order, a valid source-chain refund address can be supplied when the integration supports it. Other route types ignore that option and return a refund to the swapper, so the quote type must be checked before relying on a separate address.

Is Guaranteed price available on every cross-chain swap?

No. The quote determines eligibility and exposes it through Swift auction mode 3. Eligibility covers same-asset USDC, USDT, and ETH transfers across supported chain pairs; cross-asset swaps use the expected-and-minimum model. An eligible quote fixes the output amount, not delivery time. If no driver fills the order before its deadline, the order follows the refund path instead of settling for less.

What happens if the tracker receives an order hash instead of a transaction hash?

Use the order hash as the tracking identifier when a gasless Swift call returns it. The Explorer API accepts it through the same lookup flow used for a source transaction hash, and its client status still reports in progress, completed, or refunded. Do not interpret the different identifier format as a failed broadcast. Match it to the signed order, then wait for a terminal status before choosing a recovery action.

Do route fees stay fixed after I refresh a quote?

No. A new quote is a new set of route terms, so its fees, expected output, protected minimum, deadline, and available route can differ from the earlier response. Compare complete quotes produced for the same intended transfer rather than copying isolated fields across responses. Once an order is submitted, the signed quote governs that order; refreshing the screen does not update its fee or settlement conditions.