Your withdrawal says pending

1. Internal review A risk system is still deciding whether to approve the request at all.
2. Signing and queueing Approved, and waiting its turn to be signed, usually as part of a batch.
3. Broadcast Announced to the network and sitting in the mempool, waiting for a block producer.
4. On-chain confirmation Mined, accumulating the blocks the receiving side insists on.

The interface shows the same grey label for all four. One question separates them: do you have a transaction hash yet? No hash means stage one or two, and the exchange still holds your request. A hash means stage three or four, and the wait now belongs to the chain. So the useful move is not to refresh the page. It is to answer that question, because in two of these stages waiting is exactly correct and in the other two something may need doing.

One status word, four different stages

Pending means the withdrawal has been requested and not yet completed, which covers everything from a risk check that started thirty seconds ago to a transaction already mined and waiting for its fifth confirmation.

Here are the four stages in order, with who controls each one.

The line between stage two and stage three is the important one. Everything above it is the exchange's decision. Everything below it is arithmetic about block production that nobody can hurry, including the exchange, including you.

How do I tell whether it is the exchange or the chain?

Look for a transaction hash. If there is no hash, the withdrawal has not left the exchange. If there is one, it has left, and the delay belongs to the network.

This is the single most useful diagnostic on the page and it takes ten seconds. Open the withdrawal record in your transaction history. A completed or broadcast withdrawal shows a long hexadecimal string, usually labelled TxID or transaction hash, often rendered as a link. A withdrawal still inside the exchange shows a blank there, or a dash, or nothing at all.

No hash means no transaction exists yet. The exchange has debited your balance and is holding the request. That is stage one or two.

A hash means a transaction exists and has been announced to every node on that network. At that instant the exchange loses the ability to stop it, reverse it or speed it up. That is stage three or four, and the place to look is a block explorer rather than the exchange's interface. Etherscan for Ethereum, Tronscan for Tron, mempool.space for Bitcoin. Paste the hash into the search box and you will see, in plain terms, whether the transaction is confirmed and how many blocks have passed since.

No hash, ask the exchange. Hash, ask the chain.

Why is my withdrawal sitting in review?

Because an automated risk score flagged something about this particular request, and either a rule or a person is now looking at it.

Every withdrawal is scored before it is approved. Most clear instantly and you never learn that the scoring happened. The ones that do not clear share a small set of characteristics, and knowing them helps you predict which of your own withdrawals will be slow.

• A destination address you have never used. First sends to a new address attract the most scrutiny, because address substitution by malware is a real attack and a new address is exactly what it looks like.
• An unusual amount. Unusual relative to your own history, not in absolute terms. A five hundred dollar withdrawal from an account that has only ever moved twenty dollars is anomalous. From an account that moves thousands weekly it is not.
• Anything recently changed on the account. A new device, a new login location, a fresh two-factor enrolment.
• Destination reputation. Exchanges screen the receiving address against known-bad clusters. A clean personal wallet passes without you noticing.

Manual review is where the multi-hour delays live. Automated review is measured in seconds. There is no way to tell from outside which one you got, which is genuinely annoying and is the main reason this stage feels arbitrary.

What does processing mean if there is no hash yet?

The withdrawal has been approved and is queued for signing, usually as part of a batch, and a transaction will not exist until that batch is built and broadcast.

This is the stage almost nobody knows about, and it explains most of the delays that make no sense otherwise. Exchanges do not sign a transaction the moment you click confirm. Private keys for the hot wallet live in a controlled environment, and requests are collected and signed in cycles rather than one at a time.

Batching exists for two reasons. It reduces the number of times the signing system is touched, which is a security property. And on chains where fees are paid per transaction rather than per output, sending to many recipients in one transaction is dramatically cheaper than sending separately, which is why the fee you were quoted is often lower than the cost of sending yourself.

What this means for you: a withdrawal can sit in processing for a while with nothing wrong. You are waiting for a cycle, not for a decision. The queue is also longer at busy times, so a withdrawal placed during a sharp market move will generally take longer than the same withdrawal placed on a quiet Sunday.

Some platforms will still let you cancel at this point, because nothing irreversible has happened. Once the batch is signed and sent, that option disappears permanently.

Once it is broadcast, nobody can intervene

The transaction is announced to the network, sits in the mempool with every other unconfirmed transaction, and waits for a block producer to include it.

Broadcast is the point of no return. The exchange has signed a transaction and released it. It now exists independently of them and will be included in a block sooner or later based on the fee attached and how busy the chain is.

On a congested chain, "later" can be a long time. This is normal behaviour rather than a fault, and the ethereum.org documentation on transactions describes the lifecycle clearly if you want the underlying model. The mempool is a waiting room, and transactions paying more get seated first.

Two things follow from this. Support cannot help, because there is nothing on their side left to do. And the explorer, not the exchange, is now your source of truth.

Why does it need a certain number of confirmations?

Because a transaction in the most recent block can still be undone by a chain reorganisation, and each additional block on top makes that outcome less likely.

A confirmation is just a block. One confirmation means your transaction is in the newest block. Six means five more blocks have been built on top of it. The receiving side picks a threshold and will not credit the funds until it is met.

The block interval sets the clock. Bitcoin targets a block roughly every ten minutes, so six confirmations is roughly an hour. Ethereum slots are about twelve seconds. Tron produces a block about every three seconds. That is why the same nominal wait feels completely different across chains.

Required confirmation counts are set per asset and per network by whoever is receiving, and they change. Exchanges publish theirs and revise them when network conditions or security assumptions change, so treat any number you read anywhere, including here, as an example rather than a constant. The deposit or withdrawal screen on the receiving platform is the authority.

One asymmetry worth understanding. The sending exchange usually marks a withdrawal complete at broadcast or at its own low confirmation threshold. The receiving exchange applies its own, often higher, threshold before crediting. So a withdrawal can read complete on one side and pending on the other for an hour, with nothing wrong at either end.

Why are my withdrawals blocked after I changed a security setting?

Binance's password-change instructions specify a 24-hour withdrawal suspension. Changing Binance Authenticator can suspend withdrawals for up to 48 hours. Follow the notice in your account; other security changes or risk reviews can have different conditions.

The reasoning is straightforward once you see it from the attacker's side. Someone who takes over an account immediately changes the credentials to lock the owner out, then withdraws. The hold breaks that sequence. It gives the real owner a window to notice the change notification and react before anything leaves.

A support request should not be treated as a way to bypass the countdown. If the hold continues after the stated period, or you did not make the security change, contact official support. Other security changes and risk reviews can have different conditions.

Plan routine credential changes for a day when you do not need to move funds. If you suspect someone has access to your account, secure it immediately, even if doing so delays a withdrawal.

Sources: Binance instructions for password changes; Authenticator changes, checked 2026-09-12. The notice in your account takes precedence.

Suspensions are per network, not per asset

Yes. Exchanges suspend deposits and withdrawals on individual networks during upgrades, node maintenance and periods of instability, and the suspension is per network rather than per asset.

This is easy to miss because the asset stays available. USDT withdrawals might be running normally on two chains and paused on a third. If your usual route is the paused one, the withdrawal screen may accept the request and then hold it, or the network may simply not appear in the list.

Announcements are published rather than pushed. Binance posts them to its announcement centre, and checking there before opening a ticket saves time. Upgrades on the chain side are usually scheduled in advance and the suspension window is stated up front.

If a network is suspended and you need the funds now, the alternative is another network, assuming the receiving wallet or exchange supports it. Check that it does before you send, because that mistake is more expensive than the wait.

Contact support only when there is no hash

Mainly in stages one and two, when there is no transaction hash. After broadcast there is very little support can do about the chain itself, and asking mostly moves your frustration into a queue.

The test again: no hash, and several hours have passed, and the account has no obvious security hold and the network is not suspended. That combination is worth a ticket. It means a request is sitting in review longer than review normally takes, and a human can at least confirm the case is open.

Give them the withdrawal ID from your history, the asset, the network, the amount and the timestamp. Do not send a screenshot with an address cropped out of it, because the address is one of the few things they need.

If a hash exists, do not open a ticket. Take the hash to the explorer for that chain. If the explorer shows confirmations and your wallet does not show the funds, the problem is at the receiving end, and that is where to ask. A related failure mode from the other direction is covered in the write-up on deposits that have not arrived.

Common questions

Four that come up repeatedly, with the honest answer rather than the reassuring one.