CONFIRMING is the single longest-dwelling status in the entire order lifecycle by design — a BTC deposit can sit there for 10-60 minutes and still be completely healthy, because the status isn’t measuring “is something wrong,” it’s measuring “has the network finished its job yet.” Most support tickets opened during CONFIRMING close themselves once the reader understands that this status, unlike TIME_EXPIRED, isn’t even capable of failing on its own — it can only advance or get overtaken by the deposit window running out.
What “Confirming” actually means in the order lifecycle
Every swap order moves through a fixed sequence of statuses: NEW → WAIT_DEPOSIT → CONFIRMING → EXCHANGING → SENDING → DONE. CONFIRMING sits right in the middle, and it’s the first status where your money has actually left your wallet and hit the blockchain.
Before it, WAIT_DEPOSIT means the order exists but nothing has arrived yet — you haven’t sent, or the transaction hasn’t propagated. After it, EXCHANGING means the provider has accepted your deposit as final and is executing the swap on their side, and SENDING means the output coin is on its way to your address.
CONFIRMING is different in kind from the terminal failure states — TIME_EXPIRED, FAILED, and REFUNDED. Those are exits from the lifecycle: the order stops and something (usually a refund) needs to happen. CONFIRMING isn’t an exit. It’s a wait.
“Confirming” isn’t a failure state — it’s a waiting state.
How long “Confirming” should normally take, per chain
Confirmation time is a function of two things: the source chain’s block time, and how many confirmations the underlying provider requires before treating the deposit as final. The second number varies by provider and by deposit size, so treat the ranges below as realistic windows, not guarantees.
| Chain | Typical block time | Realistic “Confirming” window |
|---|---|---|
| Bitcoin (BTC) | ~10 min/block | 10-60 minutes |
| Ethereum (ETH) | ~12 sec/block | Under 5 minutes |
| Monero (XMR) | ~2 min/block | 10-20 minutes |
| USDT (ERC-20) | ~12 sec/block | Under 5 minutes |
| USDT (TRC-20) | ~3 sec/block | Under 2 minutes |
| Solana (SOL) | Sub-second | Near-instant |
| Tron (TRX) | ~3 sec/block | Near-instant |
The exact confirmation threshold — is it 1 block, 2, or 10 — is set by the provider your order routes through, and it can flex based on deposit size. A $50 BTC deposit and a $50,000 BTC deposit may not need the same number of confirmations. Don’t treat the ranges above as a contract; treat them as “if you’re inside this window, nothing is wrong yet.”
Why it takes longer than the block time you expected
If ETH blocks land every 12 seconds, why does Confirming sometimes take a few minutes rather than 12 seconds flat? Because one confirmation almost never means one block.
Providers require multiple confirmations to protect against chain reorganizations — the rare case where a block gets replaced after the fact, which would un-happen your deposit. The deeper the reorg risk on a given chain, the more confirmations a cautious provider asks for. On top of that, your transaction has to be picked up by a miner or validator in the first place, and on congested networks with a low fee attached, that pickup itself can take longer than the raw block time suggests.
The blockchain doesn’t care that you’re impatient. Neither does the provider.
This is also why BTC dominates support tickets around Confirming specifically — its 10-minute block time means even 2 confirmations is 20 minutes best case, and mempool congestion regularly pushes that to 40-60 minutes for anyone who set a fee on the low end.
When “Confirming” is not a problem yet
You’re inside the normal range if:
- Your deposit is confirmed by the block explorer’s own count (even if the order still shows
Confirming— providers often wait for more confirmations than the explorer’s default view) - You’re inside the chain’s realistic window from the table above
- The order page still shows active time remaining in the deposit window
- There’s no wrong-network signal (see below)
None of these require action. Most Confirming orders resolve into Exchanging on their own, and opening a ticket at this stage doesn’t speed anything up — support can’t push a block through the network any faster than the network itself does.
When to actually start worrying
A few signals are actually worth acting on:
- The order’s deposit window is running low and your transaction still shows zero or partial confirmations on the block explorer
- The block explorer shows nothing at all matching your sent amount — this usually means wrong network, not slow confirmation
- You’re well outside the realistic window for that chain (e.g. an ETH deposit still unconfirmed after 30+ minutes with no visible mempool congestion)
If your deposit window closes before confirmation completes, the order moves to TIME_EXPIRED rather than staying in Confirming indefinitely — that’s a separate failure mode with its own recovery path, covered in why crypto swaps end up TIME_EXPIRED. Setting a refund address before you deposit is what makes that recovery automatic rather than a manual support ticket.
What to check yourself before opening a support ticket
Three checks resolve the overwhelming majority of “my swap is stuck at Confirming” questions before a ticket is even needed:
- Find the txid. Your wallet’s transaction history shows the outgoing send — copy the hash.
- Paste it into a block explorer for that specific network. Confirm the transaction exists, how many confirmations it has, and whether it’s even the right network (a Tron address won’t show up on an Ethereum explorer, for instance).
- Compare confirmations against the realistic window from the table above. If you’re inside the window, you’re fine. If you’re near the edge of your deposit window and confirmations are lagging, that’s when a ticket is worth opening — with the order ID and txid ready so support doesn’t have to ask.
What happens next: Confirming → Exchanging → Sending, or Confirming → TIME_EXPIRED
Two paths lead out of Confirming. In the overwhelming majority of orders, your deposit accumulates the required confirmations, the order flips to Exchanging, the provider executes the swap on their end, and Sending follows shortly after — payout lands in your wallet and the order closes as DONE.
The other path only opens if the deposit window closes before confirmations finish — a slow network, a fee set too low, or a genuinely congested chain. That produces TIME_EXPIRED, a terminal status with its own recovery process rather than a continuation of Confirming. Reading the rate-type guide before you swap is the easiest way to avoid that path in the first place — a floating rate gives slow chains more room than a tight fixed lock.
If none of this matches what you’re seeing, the FAQ and how it works pages cover the rest of the order lifecycle in more detail.