When a Cross-Chain Swap Expires, What Happens to the Funds?

When a cross-chain swap expires, the protocol’s deadline may stop a claim or make a refund available, but it does not move tokens by itself. The result depends on what the route locked on-chain and which contract or program enforces the timeout. A wallet showing “expired” can also mean only that a quote or transaction request is stale; the funds may still be locked, or the source transaction may never have been submitted.

That distinction matters because there is no single cross-chain swap expiration mechanism. In a hash time-locked contract (HTLC), a time condition governs when the locked asset can be reclaimed. In an intent-based route, an order deadline can end the opportunity to fill, while a separate protocol action handles the source-chain refund. The mayan bridge explainer covers the route’s stages in more detail; the key point here is that expiry changes the permitted next step, not the ledger state by itself.

What does the expiration deadline actually control?

The deadline controls whether a specified contract action remains valid; its meaning is protocol-specific. An HTLC combines a hashlock with a timelock. The hashlock allows the counterparty to claim funds by providing the secret whose hash was committed to the contract. The timelock gives the funder a refund path after its condition passes. On Bitcoin, a script can enforce a time-based spend condition with OP_CHECKLOCKTIMEVERIFY; on EVM chains, a contract can compare the current block timestamp or block number with a stored deadline.

In a two-leg HTLC swap, each chain has its own contract and timeout. The intervals are staggered: the leg the initiator claims first must expire later, leaving the counterparty time to use the revealed secret on the other chain. If the first claim never happens, each party waits for the relevant refund condition and submits a refund transaction on its chain. The contracts do not coordinate a global rollback. Each chain independently accepts a valid claim or refund under its own rules.

Other routes use a deadline differently. Mayan Swift is an intent-based auction route: a user creates an order, and a solver can fulfill it on the destination chain. The quote’s deadline limits the period for the order to be fulfilled. Mayan’s published flow describes a source-chain refund when no solver starts the auction before that deadline. This is not the same mechanism as two parties revealing an HTLC secret, and the order deadline should not be treated as a universal timeout for every route.

Does expiration automatically return the tokens?

No; expiration usually makes a refund possible, while a transaction or protocol message must still execute the refund path. Smart contracts run when called, and a Solana program runs when an instruction is submitted. If the source asset is held in an escrow contract or program, the refund function must verify that the order is eligible, has not already been completed, and has not already been refunded. It then transfers the asset to the refund address recorded for that order.

Who submits that action varies. Some systems let the user call the refund function directly; others rely on a relayer or a protocol message to trigger the source-chain refund. In Mayan Swift, the documented user flow exposes a REFUNDED status once the funds have returned on the source chain. That status is stronger evidence than a timer reaching zero: it records a refund outcome rather than mere eligibility.

Three states are useful to keep separate:

• Quote expired: the terms may no longer be executable. No funds moved if the source transaction was never confirmed.
• Order deadline passed: a fill may no longer be valid, and the protocol’s refund conditions may now be met.
• Refund confirmed: the source-chain transaction returned funds to the recorded refund address.

A user-facing timer can blur these states. A countdown reaching zero is not proof that a refund transaction has been included, and an interface or indexer can lag behind the chain. Check the source-chain transaction and the order’s on-chain status before treating the transfer as complete.

What can delay or prevent a refund?

A valid refund path can still take time because eligibility and execution are separate events. The source chain must produce a block or slot that satisfies the protocol’s condition; then someone must submit the refund call, pay any required network fee, and wait for confirmation. If the protocol requires a cross-chain message, that message also has to be observed and accepted before the source contract can act.

There are several edge cases. A destination fill may have completed just before the deadline while its status has not yet reached the tracker. A refund attempt can fail if the order is already fulfilled, the proof or message is invalid, or the transaction uses the wrong chain or contract. Refunds can also return less than the original input if the route deducts a disclosed fee or a source-chain transaction fee. A timeout does not guarantee a refund of unrelated costs, such as gas already spent on a failed transaction.

For a pending swap, first establish whether the source transaction confirmed. If it did, identify the route type and inspect its order or escrow status; then use that protocol’s documented refund path once its conditions are met. Keep the transaction hash, order identifier, and refund address available. If the source transaction never confirmed, there is no on-chain swap escrow to refund. Expiration is therefore best understood as a state transition boundary: it closes one route to settlement and may open another, but the chain records a refund only when that second action succeeds.