16 October 2026 · 4 min read

Deposits and withdrawals, the part that breaks first

Nearly a third of real exchange briefs are about moving money in and out. Confirmations, reorgs, stuck transactions and the sweep policy that quietly decides your costs.

Across hundreds of real exchange briefs, the feature mentioned most often is not the order book or the chart. It is wallets, deposits and withdrawals, in roughly three out of ten requests. That matches what actually happens after launch: this is the part that breaks first, and the part users notice immediately when it does.

Deposits are harder than they look

A deposit is not an event. It is a transaction that gets more certain over time, and your job is to decide when it is certain enough.

• Address per user, derived rather than assigned from a pool, so a deposit can be attributed without a memo the user will forget.
• Confirmations per chain, configurable in the console. One number for every chain is wrong on at least one of them.
• A pending state the user can see. Most support messages on a new venue are "where is my deposit", and a visible pending balance removes nearly all of them.
• Reorg handling. If the chain reorganises after you credited a balance, the credit has to reverse. This is the single question that separates developers who have run an exchange from developers who have built interfaces.

Withdrawals are where money leaves

Which is to say: this is the path that gets attacked.

• Policy before automation. Limits per user and per period, an approval step, and a hold on anything unusual. Approve by hand until you have watched the system behave.
• A hot and cold split, with only operational float in the hot wallet.
• Multisig release for anything moving out of cold storage.
• An audit trail. Who approved what, when, and from which account. You want this before you need it.

Every exchange incident that becomes public is, underneath, a story about key management and the withdrawal path. Almost none of them are about the matching engine.

The sweep policy nobody plans

Funds arrive at thousands of user addresses. Moving them into the hot wallet costs network fees, and how you do it decides whether withdrawal fees earn or lose money.

Sweep too often and you burn the margin in network fees. Sweep too rarely and you cannot cover payouts without touching cold storage. The sensible version is threshold based, per chain, reviewed when networks get busy, and visible in the console rather than buried in a config file.

Stuck transactions

They happen, and they are an operations problem, not a bug. A fee was too low, a nonce is out of order, a node is behind. What matters is:

• the operator can see which withdrawals are stuck, in one screen
• there is a documented way to rebroadcast or replace
• the user sees an honest status rather than "completed" on something that never confirmed

What to ask a developer about this

Three questions, and the answers tell you everything:

1. What happens if the chain reorganises after a deposit is credited?

2. Where is the sweep policy configured, and who can change it?

3. Show me the screen where an operator sees a stuck withdrawal.

A team that has shipped an exchange answers all three in a sentence each. How to pick a developer has the rest of that checklist.

Questions

What is deposit detection in a crypto exchange

Watching each chain for transactions to user addresses, attributing them to the right account, and crediting the balance once enough confirmations have passed. It runs continuously and has to survive the node restarting.

What happens if the blockchain reorganises after a deposit

The credit has to reverse. A correct implementation credits only after a confirmation threshold, keeps a pending state before that, and reconciles afterwards. A front end with a demo backend has no answer to this at all.

How many confirmations should an exchange require

It differs per chain and belongs in the console rather than the code, so it can be raised when a chain is behaving badly without a deployment.

What is a sweep policy

The rule for moving funds from user deposit addresses into the hot wallet. Threshold based and per chain, because sweeping too often burns network fees and too rarely leaves you unable to pay out.

Should withdrawals be automatic

Not at launch. Approve by hand until the system has been watched for a while, then automate within limits, keeping an approval step for anything unusual.

Why do withdrawals get stuck

Usually a fee set too low, a nonce out of order, or a node behind the chain. The fix is operational, so what matters is that the console shows stuck withdrawals clearly and offers a documented way to rebroadcast.