Why your crypto swap expired (TIME_EXPIRED): causes and recovery

TIME_EXPIRED looks alarming, but it is structurally a refund trigger, not a loss event. On a non-custodial aggregator, your crypto never enters someone else’s vault: either it never left your wallet, or it bounces back to the refund address you set. The status simply means the deposit did not arrive in confirmed form before the order’s clock ran out. This guide covers the six real causes — low fees, slow chains, congestion spikes, fixed-rate locks, wrong networks, amount mismatches — and a five-step recovery sequence you can run in under two minutes.

What TIME_EXPIRED actually means on a swap order

Every swap order moves through a fixed state machine. While it is alive, the status walks NEW → WAIT_DEPOSIT → CONFIRMING → EXCHANGING → SENDING → DONE. When it dies, it lands in one of three terminal failure states.

TIME_EXPIRED specifically means the deposit window closed before your transaction reached enough on-chain confirmations for the underlying provider. It is a terminal status — the order will not progress further on its own. This is structurally distinct from FAILED (provider rejected the order or hit an internal error) and from REFUNDED (a refund has already been explicitly issued). TIME_EXPIRED is the “deposit did not arrive in time” bucket.

If you want the full status flow with screenshots of each step, see how it works. For now, the key fact is this: TIME_EXPIRED is a status on the original order, not a hold on your funds.

TIME_EXPIRED is a refund trigger, not a failure. On a non-custodial aggregator your crypto never enters anyone’s custody — either you didn’t send, or it bounces back to your refund address.

First check: did your funds actually leave your wallet?

Before chasing a recovery flow, find out whether you actually broadcast the deposit. Half of all “my swap expired” tickets resolve here.

• You opened the order but never sent. Your crypto is still in your wallet. The order just timed out idle. No recovery, no ticket — open a new swap.
• You sent and the transaction is still pending in mempool. The deposit may still arrive after the order expired. What happens next depends on the provider’s late-deposit policy — most refund automatically to the refund address you set; a few will let you continue at the current floating rate.
• You sent and the transaction confirmed before expiration, but the order still shows TIME_EXPIRED. Double-check the order ID — you may be looking at a different order, or the status is stale. A confirmed deposit inside the window should walk through CONFIRMING → EXCHANGING → SENDING.

The practical move: open your wallet, find the outgoing transaction tied to this order, copy the txid, and paste it into a block explorer for that network. Whether the tx is confirmed, pending, or dropped determines everything downstream.

The 6 real causes of TIME_EXPIRED

Almost every expired order traces back to one of six causes. Knowing which one applies to you tells you exactly how to recover and how to avoid it next time.

Cause 1 — Underpaid network fee

The single most common cause. You broadcast the deposit with a low sat/vB on BTC or low gas on ETH, the transaction sits in mempool for hours, and the order’s deposit window closes before the first confirmation. This is purely a fee-estimation miss — your wallet’s “economy” or “slow” tier was below what the network was actually clearing at the moment you sent. Use mempool.space for BTC or an Ethereum gas tracker for ETH and bias toward the fast tier when an order clock is running.

Cause 2 — Slow source chain by design

BTC has 10–60 minutes per confirmation. XMR needs 10 confirmations of 2-minute blocks for full settlement — 20 minutes minimum. ETH on a congested day can crawl from 1–3 minutes to 10+ minutes. If the provider’s window is shorter than your chain’s realistic settlement, expiration is statistically likely even with a generous fee. This is the case where the chain itself is the bottleneck.

Cause 3 — Network congestion spike

A sudden mempool spike — a memecoin launch, a CEX outage triggering withdrawals, a popular NFT mint — can push your transaction to the back of the queue even when you paid the suggested fee. This is the “I paid the recommended sat/vB and it still timed out” case. The fee was right at broadcast time and wrong by the time the next block was mined.

Cause 4 — Fixed-rate lock window expired

Fixed-rate orders carry a tighter lock — typically 10–30 minutes — than floating-rate orders. The lock is the rate guarantee window; if your deposit confirms after it closes, the provider cannot honor the locked rate and falls back to refund. The lock duration varies per provider, but it is always tighter than the floating window because the provider is carrying price risk. See the fixed vs floating deep-dive for the full rate mechanics.

Fixed-rate swaps expire more often than floating because the lock guarantees a rate, not a deposit window. On a slow source chain like BTC mainnet, the lock often closes before the first confirmation.

Cause 5 — Wrong network selected

You picked USDT (ERC-20) in the widget but sent USDT on TRC-20 to what looked like the same address. The expected network never sees the deposit; the order expires while waiting. This is structurally the worst cause because the recovery path is the messiest — the deposit landed on a network the order has no record for, and recoverability depends on whether the receiving provider operates a wallet on the network you actually used. Always re-read the network badge in your wallet’s send screen before confirming.

Cause 6 — Amount mismatch

You sent less than the minimum (amount_from floor), more than the maximum, or a number that does not match the order’s expected deposit. Many providers will hold and refund after support intervention, but the order itself flips to TIME_EXPIRED because the expected amount never showed up within the window. Fixed-rate orders are stricter here than floating — floating tolerates small over/under within provider limits; fixed often does not.

What happens to your funds in each scenario

Recovery mechanics differ based on what actually happened on-chain. Match your situation to the closest row below.

• You never sent. Nothing happened. The order is a UI artifact at this point. Start a new one — no funds to recover.
• You sent on the correct network, deposit confirmed late, refund address set. The provider either auto-refunds to the refund address or routes you through support. With a refund address pre-set this is mostly automatic — and that is the entire point of the refund-address habit. Expect the on-chain return within 1–60 minutes.
• You sent on the correct network, no refund address set. The funds are not lost, but recovery requires a support ticket with the order ID, deposit txid, and a destination address. This is slower — sometimes several days, depending on provider workload.
• You sent on the wrong network. Depends on whether the wrong-network address even decodes for the receiving provider and whether they operate a wallet there. Sometimes recoverable with help, sometimes not. Always contact the provider’s support immediately — do not wait.
• You sent the wrong amount. Typically refunded minus an on-chain fee for the return transaction. The order status does not update because the deposit did not satisfy the order — handle through support with the txid.

SwapZilla is a non-custodial aggregator: funds route between your wallet and the underlying provider’s deposit and payout addresses. We do not custody, so we cannot unilaterally “release” anything — recovery always involves the provider that issued the original deposit address. The FAQ covers this dynamic in plain terms.

How to prevent TIME_EXPIRED next time

A 30-second checklist that converts most expired orders into completed swaps.

• Set a refund address every single time. It is a one-field habit that converts a panicked support ticket into an automatic on-chain bounce-back. This is the highest-ROI move you can make on any aggregator.
• Use floating rate on slow source chains. BTC mainnet, XMR, ETH on a congested day — the floating window is more forgiving than the fixed lock. Do not pay for a lock that statistically expires before your deposit confirms.
• Pay an honest network fee. Use a current estimator (mempool.space for BTC, a gas tracker for ETH) and bias toward the “fast” tier when an order clock is running. The fee saved by going “economy” is rarely worth the cost of an expired order.
• Double-check the network before you hit send. USDT TRC-20 vs ERC-20 vs Solana is the single most common “I sent on the wrong network” mistake. The widget’s network badge tells you exactly which one the order expects — match it against your wallet’s send screen.
• Send the exact requested amount on fixed-rate. Floating tolerates small over/under within provider limits; fixed often does not.
• For five-figure swaps, prefer a fast source chain when feasible. Lightning, Solana, USDT-TRC20 settle in seconds and dodge most of the timeout categories. If the BTC mainnet path is the only option, price in the timeout risk.

The swap widget shows the network and rate type on every quote before you confirm — those two fields are where most timeout-causing mistakes get caught.

The single highest-ROI habit on any swap aggregator: set a refund address every time. It converts an expired order from a support ticket into an automatic on-chain bounce-back.

What to do right now if your order says TIME_EXPIRED

A five-step sequence you can run in under two minutes.

Step A — Determine whether you sent or not. Open the wallet you would have broadcast from. If there is no outgoing transaction tied to this order, stop: nothing is lost, open a new swap.

Step B — If you sent, copy the txid and check it on a block explorer. Note whether it is confirmed, pending, or dropped. This is the single piece of information any support flow will ask for first.

Step C — Check the order page for the refund address you set. If it was set and the transaction confirmed late on the correct network, expect an automatic refund within 1–60 minutes depending on the provider — the refund is on-chain and visible on the block explorer.

Step D — If no refund address was set, contact support with full details. Send the order ID, deposit txid, source amount, source and destination assets, and a source-chain wallet address you control. Do not open multiple tickets — one well-formatted ticket recovers faster than five panicked ones. The FAQ outlines the standard flow.

Step E — Do not resend the deposit to the same address. The order is terminal once it shows TIME_EXPIRED. Any second deposit lands on an address that no longer has an active order behind it, which makes recovery harder, not easier.

Edge cases people get wrong

A handful of misconceptions that show up in support tickets every week.

• “It has been an hour, can I cancel?” TIME_EXPIRED is the cancellation. There is no separate cancel action because the order has already terminated. You do not need to do anything to stop it.
• “Will I be charged for the expired order?” No. On a non-custodial aggregator there is no balance to charge. If you sent a late deposit, you may pay a small on-chain return-tx fee on the refund — that is blockchain economics, not a platform fee.
• “My deposit confirmed but the order is still TIME_EXPIRED.” Your transaction confirmed after the deposit window. The provider will usually auto-refund to the refund address you set. If you did not set one, see Step D above.
• “Can I extend the deposit window?” Generally no on aggregator flows. The window is set by the underlying provider and cannot be extended client-side. If you know in advance your deposit will land late, do not send — let the order expire idle and start a fresh quote.
• “I sent on the wrong network and the order expired.” Structurally the hardest case. The receiving provider has no record of the deposit. Recovery depends on whether the wrong-network address even decodes for them and whether they operate a wallet there. Contact support immediately — do not wait, and do not send anything else.
• “Does TIME_EXPIRED ever auto-recover into DONE?” No. It is a terminal failure status. Any post-expiry deposit becomes a refund flow, not a swap.