Mayan auctions let drivers compete to deliver cross-chain swap outputs

Orders define the outcome drivers must deliver

An intent specifies the input asset, the destination token and chain, and the least acceptable output. The user doesn't need to design every underlying movement of funds. Drivers compete to satisfy the order within its signed conditions. A quote request returns available routes before execution. Each quote carries its own method and output terms. Selecting one establishes which mechanism applies; Swift auction fields don't describe every other method in the response. The expected return shown while choosing a route also remains distinct from an order's eventual delivery.

Where do drivers submit their Swift offers?

Swift drivers submit offers on Solana based on the output they can supply on the destination chain. The auction's location doesn't require the recipient's tokens to arrive on Solana.

Destination liquidity precedes source reimbursement

Swift separates the recipient's destination payment from the driver's recovery of locked source funds. Drivers supply destination liquidity upfront. Cross-chain verification and source-side release follow afterward, moving that wait away from an ordinary recipient.

View full-size image

The source contract locks the input, which may first be converted into the chain's primary locked asset. After fulfilment, destination data supports the later source-side unlock. Winning the auction alone doesn't release the locked source funds.

Payload-enabled Swift swaps stage the destination payout and complete it after a settlement step validates the payload. Their source unlock still waits for the cross-chain attestation. Zaps can attach destination actions to swaps, so a staged payout shouldn't be presented as already delivered.

When does the auction fix the received amount?

A Swift order fixes its received amount when the selected quote carries swiftAuctionMode equal to 3 , indicating Guaranteed Price.

Reading the settlement mode

Mode 2 preserves a minimum

With mode 2 , the driver must deliver at least minAmountOut . The eventual output usually sits near expectedAmountOut , and it can be higher or lower than that estimate. Competitive offers operate within the signed minimum; the displayed expectation isn't a fixed settlement amount.

Mode 3 fixes the output

Mode 3 makes expectedAmountOut the exact output for a successful fill. A payment can use that figure as a fixed received amount. The guarantee covers quantity, not completion time. An exact-output order still has a deadline and can expire unfilled.

Asset eligibility limits exact output

Guaranteed Price supports same-asset transfers of USDC, USDT, and ETH across supported chains. Other same-asset transfers and cross-asset swaps don't qualify. Eligibility also belongs to the individual quote: the same pair can return different settlement modes on different orders. Its previous mode doesn't establish the next order's terms.

The signed floor constrains competitive pricing

A mode 2 order can't fill below its signed minAmountOut . If drivers can't satisfy that requirement, a lower market price doesn't authorize a smaller fill. An unfilled order follows its deadline and refund rules.

Output fields also distinguish the minimum from the amount remaining after relayer fees. minReceived expresses that latter floor. Across route families, those fields shouldn't automatically be treated as interchangeable.

What ends a driver's opportunity to fill an order?

The quote's deadline64 marks the timestamp after which an unfilled order can no longer be filled and becomes refundable. It isn't an estimated processing duration. By contrast, etaSeconds and clientEta describe estimated settlement timing. A short estimate doesn't extend an expired order or promise delivery before expiry. The return of funds also requires an onchain refund action; reaching the deadline alone doesn't confirm that action has completed.

View full-size image

A refund follows the locked asset

A Swift refund returns the converted source asset when the input underwent a swap before the order opened. The primary locked asset is typically USDC or ETH. If conversion occurred, returning that asset doesn't reverse the earlier source swap into the original token.

Refund execution also carries a relayer fee the quote exposes before signing. refundRelayerFee and refundRelayerFee64 describe the fee; clientRelayerFeeRefund gives the total dollar value of relayer fees for the refund outcome. Neither a quoted output nor an expired deadline establishes the amount a completed refund actually returned.

View full-size image

Delivery records establish the final auction amount

A driver's offer describes a proposed delivery; the destination result establishes what arrived. The Explorer's toAmount records the actual delivered amount on completion, while the quote's expectedAmountOut describes the amount expected before execution.

For tracked swaps, clientStatus reports INPROGRESS , COMPLETED , or REFUNDED . A completed swap has delivered on the destination chain. A refunded order has returned funds. An in-progress order remains live and unfilled. These states distinguish an unresolved order from either terminal outcome.

The completedAt field records settlement time, allowing an application to replace its earlier estimate with the actual completion timestamp.

Auction pricing remains part of a specific route

A route can include protocol and integration fees alongside its competitive execution terms. The quote exposes protocolBps and referrerBps ; an integrator's referral fee adds to the protocol fee. Reading the selected quote avoids turning one stored rate into a universal charge. The success and refund relayer-fee totals describe alternative outcomes, so adding both would overstate the relayer cost of a successful fill.

Swift drivers fund destination delivery from their own capital. MCTP transfers USDC through Circle's CCTP, with drivers competing on Solana for orders requiring a destination swap. Fast MCTP uses CCTPv2 with the same auction flow. A Wormhole Swap route that includes a swap holds its auction on Solana, where the winner performs a flash swap and atomically supplies the promised output. That output goes directly to a Solana recipient or through the Wormhole Token Bridge to another destination chain. These mechanisms sit within Mayan's wider swap service. Their shared availability doesn't give them identical auction settings, fees, or payout behaviour. Keeping the selected route's terms intact lets a recipient distinguish a competitive estimate from a fixed amount.