OnionSwap
When a Bitcoin deposit sticks at zero confirmations
The order says awaiting deposit. You sent the Bitcoin forty minutes ago. Your wallet shows it as sent. Nothing is happening.
This is the single most common support ticket any swap service receives, and in the overwhelming majority of cases nothing has gone wrong with the swap at all — the transaction is sitting in the mempool because it did not pay enough to be mined. The fix is entirely in your wallet, not ours. Here is how to confirm that is what you are looking at, and how to unstick it.
First: confirm the transaction actually exists
Take the transaction ID from your wallet and look it up in a block explorer. There are three possible outcomes and they lead to completely different places.
Visible, zero confirmations. The transaction is broadcast and waiting. This is the fee problem this post is about. Nothing is lost, nothing is at risk, and the coins are still yours until it confirms.
Visible, one or more confirmations. Then the swap should have moved on. If the order page still shows awaiting deposit several minutes after the first confirmation, check that you sent to the deposit address on the order and not to something else — a saved address from a previous swap is the usual culprit. If the address matches, that is a real ticket: open one on the support page with the order ID and the transaction ID.
Not found at all. Your wallet built the transaction but it never propagated. Some wallets show a locally-signed transaction as "sent" before it reaches a peer. Reconnect the wallet, or use its rebroadcast function. If the wallet lets you abandon and rebuild the transaction, do that with a proper fee rather than trying to rescue this one.
Why the fee estimate failed
Wallet fee estimators forecast, and forecasts miss. The specific ways they miss are worth recognising because they tell you how long you are likely to wait.
You picked the "economy" tier. These options target confirmation within dozens of blocks, sometimes a day or more. They are appropriate for consolidating your own coins and inappropriate for anything with a clock on it, which includes every swap. The estimator is not wrong; it is answering a question you did not mean to ask.
The mempool filled after you broadcast. Fee estimates are a snapshot. An ordinal or inscription wave, a large exchange consolidation, or simply a slow run of blocks can raise the clearing rate several-fold within an hour of your broadcast. You paid a rate that was correct when you paid it.
Your transaction is unusually large in bytes. Fees are paid per virtual byte, not per bitcoin. A payment assembled from forty small inputs can be ten times the size of a simple one, so at the same sat/vB rate it costs ten times as much — and if your wallet let you set a total fee rather than a rate, the effective rate collapsed. This is why swapping out of a wallet full of dust is slower and dearer than it looks.
To decide whether to act or wait, compare your transaction's fee rate in sat/vB — every explorer shows it — against the current bottom of the next few blocks. If you are comfortably above it, wait: the next block probably takes you. If you are far below, you are not in a queue that is moving, and waiting is not a strategy.
Option 1: replace-by-fee
If the transaction signalled RBF when it was built, you can replace it with a higher-fee version. Most modern wallets do this from a right-click or a "bump fee" button on the pending transaction, and most enable RBF by default.
The critical rule when the recipient is a swap deposit address: change the fee and nothing else. Same amount, same destination. A replacement that pays the same deposit address is invisible to us — one of the two versions confirms, we see the deposit, the swap proceeds.
What not to do while an order is open:
Do not use "cancel transaction", which some wallets present next to the fee bump. That builds a replacement paying you instead of the deposit address. If it confirms, the order gets no deposit and expires; if it loses the race, you have paid twice.
Do not change the amount. Under- and overpayments are processed at the rate current when the deposit is seen, not the rate you were quoted, so an "adjusted" replacement quietly costs you the quote you were holding.
Do not send a second, separate payment to the same deposit address hoping one arrives first. Both will arrive. You have now made two deposits against one order and need a ticket to sort it out.
Option 2: child-pays-for-parent
If RBF was not signalled — some wallets still default to off, and hardware wallet flows sometimes drop it — you can push the transaction from the other side. Miners select by package: if you spend an output of the stuck transaction in a new one carrying a large fee, the only way to collect that fee is to mine both.
The catch is that CPFP requires an output you control, which in practice means the change output from the stuck payment. Spend it back to yourself at a high rate and the parent comes along. Size the child's fee to cover the shortfall of both transactions, not just its own — a wallet that offers CPFP explicitly will handle that arithmetic; if you are building it manually, aim the combined package rate a little above the current clearing rate.
If the stuck transaction had no change — you swept the whole wallet, or the change was dust that got absorbed into the fee — CPFP is not available to you. The only remaining party who can push it is whoever controls the other output, which here is us, and unilaterally bumping an incoming deposit is not something any exchange does.
Option 3: wait it out properly
Sometimes waiting is right. Mempools drain, usually overnight in the western hemisphere and reliably over a weekend. A transaction paying somewhat below the current clearing rate is often mined within a few hours with no action at all, and a fee bump you did not need is money spent for nothing.
Two things make waiting safe. Your transaction will not be dropped from most nodes for a fortnight, so there is no cliff at the one-hour mark. And a deposit that confirms after the order window closes is not lost — the order page carries a refund address, and a late deposit is resolved through a ticket with the order ID, either paid out at the rate current when it was seen or returned. What you lose by waiting is the quote, not the coins.
How to not be here next time
Set the fee for the next block, not the next day. The service fee is a flat 0.4% and the network fee is already reflected in your quote; the fee you choose on the sending side is a separate cost you control, and shaving it is the most expensive saving in crypto when a rate is ticking.
Leave RBF on. It costs nothing and it is the difference between a two-minute fix and a support ticket. There is no meaningful downside for a payment to a deposit address that is single-use anyway.
Consolidate on a quiet day. If a wallet is full of small inputs, merge them into one output when fees are low and swap from the result. You pay the size penalty once, at a cheap rate, instead of on every time-sensitive transaction.
Consider a faster chain for small amounts. Litecoin also needs one confirmation and its fees are negligible, so an LTC-funded swap avoids the whole category of problem when the amount does not justify Bitcoin's fee market. Monero deposits are different in kind — they need ten confirmations regardless of fee, and its fee market rarely congests the way Bitcoin's does.
None of this changes what the swap does once the deposit lands. One Bitcoin confirmation releases the payout, the order moves through confirming and sending to complete, and you can follow it on the track page with your order ID.