Completed in withdrawal history does not replace checking whether the recipient credited the deposit. First establish whether the transfer was internal or went through a blockchain. An internal transfer requires the service's history and operation ID. An on-chain transfer requires the network, TXID, successful execution, correct destination details and the receiving exchange's deposit conditions. If those stages are satisfied but the deposit remains uncredited, the receiving platform should investigate. For example, Bybit directs users to the recipient exchange with the completed withdrawal's TXID.
The purpose is to locate the missing stage, not repeat the transfer. Your route depends on what you establish:
| Established state | Next step | Who can investigate |
|---|---|---|
| The transfer was internal to one service | Find the operation using its internal ID and verify the recipient account | That service's support |
| No on-chain record is found on the correct network, or execution failed | Recheck the full TXID and send the withdrawal details to the sender | The platform handling the withdrawal |
| The transaction is pending or below the required confirmation threshold | Check execution status and the receiving exchange's requirement | Do not treat the network stage as complete; contact the sender about a submission problem |
| A successful transfer matches the details and requirements, but no credit appears | Check deposit history and the account identified there; provide the evidence | The receiving platform |
1. Establish what was completed
Open the operation details at the sender. Save its type, status, ID, asset, amount, timestamp with time zone and recipient. For an on-chain transfer, also record the selected network and full TXID, the blockchain transaction identifier. Completed without the name of the screen does not distinguish a finished withdrawal from a credited deposit.
If the operation is labelled an internal transfer using an account or UID, start with the appropriate section of the service's history. Verify the recipient and the account you are signed into when checking receipt. A missing TXID is not inherently a problem here: Bybit's internal transfers, for example, do not go through a blockchain and have no TXID. If the recipient is wrong or the credit is missing, retain the internal ID and contact that service's support. There is no reason to continue searching the blockchain for this operation. Bybit's internal and on-chain transfer history.
Do not confuse this with Internal Transactions on Etherscan. That is a category of Ethereum execution data, not an exchange's internal account transfer. The explorer also separates regular transactions and ERC-20 token transfers. Etherscan's address sections.
If the transfer type is unclear, ask the sender to identify it using the operation ID. A missing TXID alone proves neither that funds were sent on-chain nor that they were lost there.
2. For an on-chain transfer, verify the network and execution result
Open the explorer link in the withdrawal details, or search the full TXID in an explorer for the selected network. An identical address format on different networks does not make them the same network. Match the network named in withdrawal history before interpreting the record.
The result determines your next action:
- Record not found. Confirm that you copied the complete TXID, selected the correct blockchain and are investigating an on-chain withdrawal. If the record still cannot be found, provide the withdrawal ID and TXID to the sender's support. Do not yet assume a recipient crediting delay: successful transmission has not been established.
- Pending. Successful execution is not yet established. Follow this transaction's status; if a platform withdrawal delay needs investigation, contact the sender with the same TXID. Do not create another transfer to “speed up” the first.
- Failed / Fail. Do not treat the transfer as successful. Ask the platform that handled the withdrawal to investigate the withdrawal result and the funds on its side.
- Success. Continue to the recipient, token and deposit requirements. Successful execution alone does not prove that the intended asset reached the intended destination or was credited by the exchange.
Read separate status fields together. In the Tron format described by Binance, CONFIRMED + FAIL does not mean a successful transfer to the recipient: confirmation and execution result are different properties. The result must be SUCCESS. This is a specific explorer example, not a universal set of labels for every network. Binance: checking a blockchain transaction's result.
For a USDT transfer on TRON, read Energy, Bandwidth and TRX charges in the receipt; those charges do not show whether an exchange credited the deposit.
3. Match the actual transfer to the deposit instructions
Open the recipient's deposit page for the intended asset and network. Compare its instructions with the blockchain record:
| Detail | Required match |
|---|---|
| Network | The network used must be supported for this deposit |
| Recipient | The actual transfer destination must match the deposit details |
| Token | For a token, verify its contract on that network; the ticker alone is insufficient |
| Amount | Use the amount actually transferred, not just the withdrawal request amount |
| Memo / tag / comment | A required additional identifier must be present and correct |
For a token, inspect the token-transfer record: its recipient, asset and amount. A top-level To field or the existence of a TXID alone does not establish the intended token transfer. Etherscan, for example, lists ERC-20 Token Transfers separately from ordinary ETH transactions. Understanding Ethereum transactions. Network, contract and memo checks are also covered in OKX's missing-deposit guidance.
If you find a mismatch, stop attempting your own fixes. Open the receiving platform's official procedure and specify the discrepancy: network, contract, address or memo. It can assess whether recovery applies to its service; that does not give it control over an arbitrary external address or establish that recovery is possible. Sending a new transfer with correct details does not repair the previous one.
4. If the transfer is correct, identify the recipient's unmet condition
A successful blockchain record and a deposit credit are separate stages. Check these conditions on the receiving exchange's deposit page and in its history:
Confirmations. Compare the actual count with the requirement for this asset and network. If it is below the threshold, the next step is to wait for that specific condition to be met. There is no universal confirmation count or processing time across exchanges. Bybit, for example, publishes the requirement on the selected deposit page. On-chain deposit FAQ.
Minimum amount. Compare the minimum with the amount actually received. Do not send a “top-up” assuming separate deposits will automatically combine. The recipient's rules determine that. In particular, the Bybit and OKX guides warn that deposits below their minimum are neither credited nor returned. If the condition was missed, clarify the applicable rule with the platform instead of making another transfer by guesswork.
Deposit availability and transfer method. Check whether the platform accepts the asset on that network and supports the method used to send it. Suspended deposits or wallet synchronization delays can explain a missing record, but a general status does not establish the cause of your case. Check the recipient's instructions for resumption and required action; contact its support if the situation is unclear. OKX: correct transaction details but no visible deposit.
As a secondary reference, Yieldo's network-status overview separately shows deposit availability and known suspensions. It is a limited summary of platform data, not a complete list of every asset/network pair or a TXID checker. A missing row does not mean deposits are open; an unknown status is not an enabled status. The data also does not establish the state at the time of your transfer. The receiving exchange's instructions take precedence.
Account checks and destination account. Look for a request for additional information in deposit history. Complete it only through the official interface. If the deposit is already marked Completed at the recipient, open its details, identify the account type credited and check that balance. For example, Bybit shows that account type in Details. This differs from Completed appearing only at the sender. If a credit record exists but the funds are not visible or available, ask the recipient's support about account crediting or availability, rather than resending funds through the network. Bybit's deposit history.
5. Send the evidence to the side that can investigate the missing stage
The sender investigates an internal operation, a missing valid on-chain record or failed execution. The recipient investigates an uncredited successful transfer, deposit requirements, incorrect deposit details and eligibility for official recovery.
Prepare one support packet:
- Sending and receiving platforms, transfer type and operation ID.
- For on-chain transfers, the full TXID and a link to the record on the correct explorer.
- Asset, network, recipient address and memo/tag where required.
- Actual amount, timestamp with time zone and screenshots of the statuses.
- A brief account of your checks: whether execution succeeded, the confirmation count and which details matched or differed from the deposit instructions.
For example, Binance provides a self-service application for some missing deposits into your own Binance account. It requires a confirmed successful transfer and may request additional evidence. This is an example of an official route, not a universal recovery tool; eligibility, fees and the outcome depend on the case. Binance: self-service recovery.
Open support through the app or official website. Your packet must not include passwords, verification codes, a seed phrase or private keys. Do not give them to a “helper” in a private message or sign an unrelated transaction to check a public TXID. A TXID is public but links an address to its history: share the packet where needed rather than posting it indiscriminately. Binance's seed-phrase security guidance.
Your diagnosis is complete when the credit is located in the appropriate account, or the missing stage is identified and its evidence has been handed to the responsible party. Then follow the support case and its stated next action. A new transfer, a different network or a “compensating” payment does not repair the earlier record, and submitting a case guarantees neither recovery nor a particular resolution time.