Deposit didn’t arrive: memos, wrong networks, and what’s recoverable

Check the explorer before anything else

Paste the transaction hash into the block explorer for the network you used, because everything you do next depends on whether the transaction is missing, pending or confirmed.

The transaction hash, sometimes labelled TxID or TxHash, is a long string identifying that specific transaction. If an exchange sent the funds, it is in the withdrawal history entry. If a wallet sent them, it is in the transaction detail. If a person sent them, ask that person for it, and do not accept a screenshot of a balance as a substitute.

Then open the explorer for the correct chain. Tronscan for Tron, Etherscan for Ethereum, BscScan for BNB Smart Chain, mempool.space for Bitcoin. Explorers are public and read-only. You do not need an account and you should never be asked for a private key or seed phrase by one.

If you have no hash, search the destination address instead. The explorer lists every transaction that touched it, and if yours is not there within the expected window, the transfer has not happened on that chain.

Three outcomes, three branches:

1. Nothing found. The transaction was never broadcast, or it went out on a different network than you think. This is a sender-side problem.
2. Found, still pending or unconfirmed. It has been broadcast and is waiting to be included or to accumulate confirmations. Waiting is the correct action.
3. Found and confirmed. The chain has done its job. Anything still wrong is now about routing, crediting or the destination, and the sections below cover each variety.

The transaction is not on the explorer. What now?

Nothing has left the sender yet, so the problem and the fix both sit on the sending side and the receiving service cannot help you.

An exchange withdrawal passes through internal stages before it is broadcast, and it can stall at any of them. Common holds: a security lock applied automatically after a password change, a new device login or a change to two-factor settings, typically lasting a fixed period; a manual review triggered by amount, destination or account age; a pending email or app confirmation nobody clicked; or the network being temporarily suspended for that asset. Those stages are the subject of a separate piece on withdrawals that say pending.

From a self-custodied wallet the failure is usually different. The transaction was signed and broadcast at a fee too low for current conditions and is sitting unconfirmed. On chains that support it, the fix is to resubmit the same transaction with a higher fee, or to cancel it by replacing it with a transaction to yourself using the same nonce. Both are wallet functions, not exchange functions.

One case looks like a missing transaction and is not. If the sender picked a different network from the one you are checking, the transaction is on the explorer for that other chain and perfectly healthy. Before concluding that nothing was sent, check the sender's record for which network it actually used, then look there. That reframes the whole problem as the wrong-network case below.

It confirmed on chain but my balance has not changed

Confirmation and crediting are two different events, and the exchange will not credit until the deposit has the number of confirmations it requires for that asset on that network.

That number is set by the exchange, per asset and per network. It is not a property of the protocol, it varies between venues for the same coin, and an exchange can raise it temporarily if a chain is behaving oddly. Both the requirement and your current count are usually shown on the deposit history row, which is the second thing to look at after the explorer.

Assuming the count is still climbing, the answer is to wait. A chain producing a block every few seconds will clear a requirement quickly; a chain producing one every ten minutes will not.

If the count has been met and nothing has credited, work through the smaller causes before assuming something is broken.

• Deposits suspended for that network. Exchanges pause a network during a chain upgrade or node maintenance and process the backlog afterwards. Announcements pages carry these. The funds are not at risk, they are queued.
• Below the minimum deposit. Many venues set a floor and do not credit amounts under it automatically. Sometimes support can, sometimes the amount is not worth the process.
• A required memo was omitted. The next section covers this in full.
• The asset or network is not one they credit at that address. Also below.

If none of those apply and the confirmations are comfortably past the requirement, that is the point to open a ticket, with the information listed above already in hand.

What is a memo, and what happens if I forgot it?

A memo, also called a destination tag, is a short identifier attached to a transaction that tells the receiving service which customer the funds belong to, and omitting it on an asset that requires one leaves the money sitting in the service's pooled account with nothing to route it by.

Some blockchains give each user a unique address and some do not. On the chains that do not, or where creating a new account carries a cost, an exchange uses a single deposit address shared by every customer holding that asset. The address identifies the exchange. The memo identifies you. Without it, the arriving funds are anonymous within the pool.

Assets that commonly require one include XRP, where it is called a destination tag, and XLM, EOS, ATOM, TON and HBAR, where it is called a memo, tag or comment depending on the interface. The deposit page will say so, usually in a red box that people scroll past. Tokens on Tron, Ethereum and BNB Smart Chain generally do not use memos, because each customer gets their own address, which is exactly why the habit of ignoring the field forms in the first place.

What happens mechanically: the transaction confirms normally, the explorer shows it as successful, the balance at the shared address goes up, and your account does not change. Nothing is lost and nothing is broken. What is missing is the label.

This is one of the more routinely resolved cases. Most exchanges run a manual recovery process for it, and for a listed asset on a supported network it usually ends with the funds credited. That is not the same as a promise. It needs a ticket with the full transaction details, it is worked by a human, it can take a long time, some venues charge a handling fee, and some decline below a minimum value. Anyone who tells you it will be resolved by a particular date is guessing.

A wrong memo is a harder problem than a missing one. If the value you sent belongs to another customer's account, the funds may have been credited to them, and unwinding that involves a third party who has no obligation to cooperate. Copy the memo from the deposit page each time rather than from a note.

I sent it on the wrong network. Is it gone?

It depends entirely on whether anyone controls a key for that address on the chain you actually used, which is the single question that separates a paid recovery from a permanent loss.

The setup is always the same. You selected one network on the sending side, pasted an address the destination issued for a different network, and the address field accepted it because the format was valid. Ethereum and BNB Smart Chain share an address format, so this happens between them constantly. The transaction is a normal, successful transaction on the chain you chose. It simply landed somewhere nobody is watching.

Case one: the destination is your own wallet. This is the good ending. If you control the seed phrase, you control that address on every chain in the same family. Add the network to your wallet, switch to it, add the token contract if the balance does not show automatically, and the funds are there. You will need a small amount of that chain's native coin for gas before you can move them, which is the only real obstacle.

Case two: the destination is an exchange, and it holds the key on that chain. Technically recoverable. The exchange can sweep the address using the same key material. Whether it will is a policy question rather than a technical one: many venues offer this as a case-by-case service, often for a fee, often only for assets they support on that chain, and often only above a minimum value. It is a manual operation on their side and it queues behind everything else.

Case three: nobody holds a key on that chain. The funds are unreachable. This covers sends to a chain the destination does not operate on at all, and sends to a contract address that has no mechanism to forward or return tokens. No ticket, escalation or legal letter changes it. The honest answer is that the money is gone, and the useful thing to do is stop spending effort on it.

If you land in case two, a recovery request is worth filing properly the first time. What it needs:

1. The transaction hash.
2. The network you actually sent on, named exactly as the interface named it.
3. The asset and the exact amount, to full decimal precision.
4. The sending address and the receiving address, both in full.
5. Timestamps: when you submitted it and when it confirmed, with the time zone stated.
6. The account it was intended for, and a screenshot of the sending side's withdrawal record.

Then wait, and expect the wait to be long. File once, keep the ticket number, and add information when asked rather than opening duplicates, which in most systems pushes you back down the queue.

Tokens the exchange has never listed

The transaction succeeds on chain and the exchange's software ignores it, because crediting an asset requires an integration that does not exist for a token they have never listed.

An exchange deposit address is monitored by processes configured for specific assets on specific chains. A token outside that set arrives at an address the exchange controls and is simply not seen. The same applies to airdropped tokens that appear at a deposit address you once used, which should be treated as lost by default.

Some venues will consider recovering an unlisted token on a chain they operate on, as part of the same case-by-case process described above, and some decline flatly because handling an uninspected contract carries its own risk for them. Both positions are defensible. Neither is something you can rely on before the fact.

The prevention is the same as everywhere else in this piece: take the deposit address from the destination's page for that exact asset, and read the asset name as carefully as the network name. The reasoning behind that habit is set out in the piece on choosing a transfer network.

Recoverability tracks control of the key

Confirmation waits and missing memos on listed assets are resolved routinely, wrong-network sends to an exchange are sometimes resolved for a fee, and sends to a chain nobody operates on are not resolved at all.

Setting expectations honestly is more useful than reassurance. The table is a summary of typical outcomes, not a commitment by anyone.

The pattern across the whole table is that recoverability tracks control of the key, not fairness, effort or how sympathetic the mistake was. If someone holds the key, there is a path and it is slow. If nobody does, there is no path and no amount of persistence creates one.

Which is why the four seconds spent checking the network dropdown against the destination's deposit page is the highest-value habit in this entire subject. I have made the memo mistake once and the wrong-network mistake once. Both were recovered, both took far longer than the trade they were meant to fund, and neither was interesting.