An exchange may not show a deposit immediately because sending, broadcasting, confirming, detecting, and crediting are separate stages. The fastest way to locate the delay is to start with the transaction hash, inspect it on the correct blockchain, and compare the verified on-chain data with the exchange order.
Key takeaways
- A wallet’s “sent” or “completed” label does not necessarily mean the receiving exchange has credited the deposit.
- If there is no transaction hash, the transfer may not have been broadcast to the network.
- If the transaction is pending, the exchange may wait for block inclusion and its required number of confirmations.
- A confirmed transaction can still be unmatched if the asset, network, token contract, destination address, or other order details are wrong.
- Do not send the funds again until you know what happened to the first transaction.
The minimum concepts you need
Transaction hash
The transaction hash, also called a TXID, is the identifier used to find a transfer on a blockchain explorer. It is stronger evidence than a wallet screenshot because it exposes the network record: sender, recipient, status, block, transferred asset, and other relevant fields.
Ethereum generates a transaction hash when a transaction is submitted, after which the transaction is broadcast and may enter a pool of pending transactions before a validator includes it in a block. [1]
Broadcasting
Signing authorizes a transaction; broadcasting sends it to blockchain nodes. A wallet can sometimes create or sign a transaction without successfully propagating it. If the hash cannot be found on several reliable explorers for the intended network, the transfer may exist only inside the sending application or one node’s local view.
Pending-transaction visibility is not perfectly uniform. For example, Bitcoin documentation explains that a mempool response represents one node’s view rather than a complete global list of every unconfirmed transaction. [2]
Confirmation
A confirmation begins when a transaction is included in a block. Exchanges normally apply their own deposit-confirmation policies according to the asset, network, operation, and risk controls. A transaction can therefore be visible on-chain but not yet eligible for crediting.
Ethereum distinguishes a pending transaction from one included in a block and later treats the containing block as justified and finalized. TRON similarly distinguishes transactions that are on-chain from those considered confirmed by its protocol. [3]
Network and token contract
A ticker is not enough to identify the transfer route. ETH is the native asset of Ethereum, while USDT is issued on multiple blockchains. Tether’s official documentation lists USDT implementations across several protocols and explicitly asks integrators to state which protocols they support. [4]
“USDT sent” therefore does not prove that the correct USDT network was used. The exchange order and the withdrawal screen must refer to the same blockchain. For token transfers, the contract shown by the explorer must also represent the expected token.
Detection versus crediting
Detection means the exchange’s monitoring system has associated an on-chain transfer with an order or deposit address. Crediting or completing the exchange is a later operational decision. A deposit may already be detected while processing remains subject to confirmation requirements, order conditions, or compliance checks. Those requirements depend on the operation and should be checked before creating an order.
The mechanism map: from wallet action to exchange detection
| Stage | Your action | What the application or exchange does | What happens on-chain | Observable result and check |
|---|---|---|---|---|
| 1. Order setup | You select the asset and available network, then copy the deposit details. | The exchange creates an order and associates it with an expected asset, network, address, and other required parameters. | Nothing has been transferred yet. | Check that the order is active and record its details before leaving the page. |
| 2. Transaction creation | You paste the recipient details into the sending wallet or platform. | The wallet prepares a transaction for the selected blockchain. | The transaction has not necessarily reached any nodes yet. | Compare the full destination address, asset, and network before approving. Do not rely only on shortened characters. |
| 3. Signing and broadcast | You authorize the transfer. | The wallet signs it and attempts to broadcast it. | Nodes validate the basic transaction data and may accept the transaction into their pending pools. | Obtain the hash and search for it on an explorer for that exact network. |
| 4. Pending state | No further action is normally required while the transaction remains valid and visible. | The exchange scanner may see an unconfirmed transfer but wait before displaying or processing it. | The transaction waits for inclusion in a block. | The explorer shows “pending,” “unconfirmed,” or no block number. |
| 5. Block inclusion | You continue monitoring the same hash. | The exchange scanner reads new blocks and looks for transfers to monitored addresses. | A block producer includes the transaction. | The explorer displays a block reference and a confirmation count or finality status. |
| 6. Validation and matching | You verify that the confirmed record matches the order. | The exchange checks the destination, network, asset, token transfer event, amount, and other order parameters. | The confirmed blockchain record remains independent of the exchange interface. | Confirm that the explorer shows a successful transfer to the exact deposit address using the expected network and token contract. |
| 7. Processing | You provide the order ID and hash if support review is needed. | The exchange applies its confirmation, operational, and applicable compliance requirements. | Additional blocks may build on the block containing the transfer. | The order status changes when the service has both recognized the deposit and completed its required checks. |
A realistic scenario
A user creates an order to send BTC to an exchange and copies the displayed Bitcoin deposit address. The wallet accepts the transfer and labels it as sent. The exchange order, however, still shows no deposit.
The user opens the wallet’s transaction details and finds a TXID. A Bitcoin explorer recognizes the TXID, shows the correct destination address, but reports that the transaction is still unconfirmed. This means the transaction was broadcast, yet it has not been included in a block. The absence of a credited deposit does not by itself indicate that the BTC was lost or that the exchange received spendable funds.
The correct next step is to monitor the same TXID rather than create a second payment. Once the transaction enters a block, the user can compare the confirmed recipient and other details with the order. The exchange can then detect the relevant block and apply its own confirmation and processing rules.
If the transaction remains pending, any fee-adjustment or replacement option should be used only through a trusted wallet’s documented process. Bitcoin transactions that support opt-in replace-by-fee can be replaced with a higher-fee transaction, which produces a replacement rather than an additional independent payment. [5]
Diagnose the delay step by step
1. Find the transaction hash
Open the withdrawal or transaction record in the sending wallet or platform. Look for a TXID, transaction hash, or explorer button.
- No hash: the withdrawal may still be queued internally, rejected, unsigned, or not broadcast.
- A hash is available: continue with an independent blockchain check.
- Only an internal reference is shown: ask the sending platform whether it is a blockchain TXID or merely its own request number.
Never share a seed phrase, private key, wallet backup, password, or remote-access code while requesting the hash. None of these secrets is required to locate a public transaction.
2. Use the explorer for the selected network
A valid transaction hash searched on the wrong explorer may return “not found.” BTC should be checked on a Bitcoin explorer. ETH and ERC-20 USDT belong on an Ethereum explorer when Ethereum was selected. TRC-20 USDT belongs on a TRON explorer when TRON was selected. Other supported routes require their corresponding explorers.
Do not infer the network from the USDT ticker alone. Use the network recorded in the withdrawal details and the exchange order.
3. Read the actual status
The explorer result generally falls into one of four useful categories:
- Not found: the transaction may not have propagated, the hash may be wrong, or you may be using the wrong network explorer.
- Pending or unconfirmed: the network knows about the transaction, but it is not yet in a confirmed block.
- Successful: the transaction was included and executed successfully, but its recipient and token details still need verification.
- Failed, reverted, dropped, or replaced: the intended transfer may not have occurred, even if a network fee was charged.
On Ethereum-compatible networks, a transaction receipt contains a status indicating success or failure. A failed contract call does not apply the intended state changes, so seeing a transaction in a block is not enough; its execution status must also be successful. [6]
4. Verify the destination address
Compare the complete on-chain recipient with the address displayed in the exchange order. Check character by character or use a trusted copy-and-compare method. Malware can replace clipboard contents, and phishing pages can display an attacker’s address.
If the blockchain shows a different recipient, the exchange cannot detect the transfer as a payment to its displayed address. Blockchain transactions are generally irreversible, so do not attempt another transfer until the source of the mismatch is understood.
5. Verify the asset, network, and token transfer
For native BTC or ETH, inspect the primary value transfer. For USDT, inspect the token-transfer section rather than looking only at the native-coin value. An ERC-20 USDT transfer, for example, is a smart-contract interaction and may show no ETH sent to the recipient even though a token transfer event records the USDT movement.
Confirm all of the following:
- the exchange order supports the network that was actually used;
- the on-chain recipient matches the order address;
- the explorer identifies the expected token contract;
- the token-transfer record shows the intended recipient;
- the transaction execution succeeded.
The service supports assets including BTC, ETH, and USDT, but that does not imply every network, pair, or direction is available. Check the current route before sending.
6. Check confirmations without guessing a deadline
If the transfer is successful and correctly addressed, inspect its current confirmations or finality state. The required threshold is a service policy, not a universal property of the asset. It can vary by network, operation, and risk conditions.
A pending deposit is therefore not automatically overdue just because another transfer was credited more quickly. Network conditions, fee selection, block inclusion, scanner synchronization, and review requirements can differ between transactions.
7. Compare the transfer with the order conditions
Even a confirmed payment may require manual matching if it differs from the order. Compare the asset, network, address, amount, and any identifier specifically requested in the order. Also check whether the order expired or changed status before the transaction arrived.
Do not create a new order and assume an old transfer will automatically attach to it. Deposit-address handling and matching rules are service-specific.
8. Prepare evidence for support
If the explorer shows a successful, sufficiently confirmed transfer to the correct address but the exchange still does not recognize it, collect:
- the exchange order ID;
- the transaction hash;
- the asset and network selected in the order;
- the sending and receiving addresses as displayed on-chain;
- the explorer status and block reference;
- the approximate time the transaction was broadcast.
Share only public transaction information through the exchange’s official support channel. Ignore private messages from people offering to “synchronize,” “validate,” or “recover” the wallet by requesting a seed phrase or an additional transfer.
Likely failure points and their visible signs
| Observed sign | Likely point of failure | What you can safely conclude | Next check |
|---|---|---|---|
| The wallet shows a request, but no TXID exists | The sending service has not broadcast a blockchain transaction | The exchange has no public transaction to detect yet | Check the withdrawal status with the sender |
| The TXID is not found | Wrong explorer, propagation failure, incorrect hash, or dropped transaction | You cannot yet prove an on-chain transfer | Confirm the network and obtain the exact hash |
| The explorer shows pending | The transaction is waiting for block inclusion | The funds are not yet confirmed at the destination | Monitor the hash and consult the wallet’s documented options |
| The explorer shows failed or reverted | Contract execution did not complete successfully | The intended ETH-token or USDT transfer may not have occurred | Inspect the receipt and token-transfer records |
| The transaction was replaced | Another transaction used the same spend or account sequence | The original hash may no longer represent the effective payment | Locate the replacement hash and verify its recipient |
| The transaction succeeded but the address differs | Incorrect address, clipboard substitution, or phishing | The exchange did not receive the funds at the order address | Stop sending and preserve all transaction evidence |
| The address matches but the network differs | The asset was sent on an unsupported or unintended chain | A familiar-looking address does not prove correct delivery | Ask official support whether recovery is technically possible; do not assume it is |
| The transfer is correct and confirmed, but the order is unchanged | Scanner delay, matching exception, order condition, or review | The on-chain evidence supports escalation, not an automatic promise of credit | Provide the order ID and hash to official support |
Where this model has limits
The same diagnostic chain works for ordinary BTC, ETH, and USDT deposits: establish whether a transaction exists, inspect it on the correct network, verify execution and confirmations, then compare it with the order. The specific fields differ because Bitcoin uses an unspent-output model, ETH is a native account-based asset, and USDT is commonly transferred through token contracts.
The explorer cannot reveal every off-chain process. It can prove that a particular blockchain recorded a transaction, but it cannot by itself prove that an exchange matched the deposit to an order, completed compliance checks, or approved a recovery request.
A successful transfer to a wrong network or address also does not prove recoverability. Recovery depends on whether the service controls the relevant keys, supports the network technically, and permits such handling under its operational and compliance rules. Additional fees, requirements, or outcomes must not be assumed.
Confirmation counts are not universal guarantees. Different networks have different finality models, while exchanges choose their own acceptance thresholds. Service policies and legal requirements may also differ by country and transaction direction.
Safe next step
Once you have the transaction hash and have checked the network, status, recipient, and token details, you can open the relevant exchange order and compare its deposit requirements. If the records match but the order remains unchanged, submit the hash and order ID through the service’s official support channel rather than sending a duplicate payment.
What you can now explain and verify
- You can distinguish signing, broadcasting, block inclusion, confirmation, exchange detection, and final processing.
- You can use a TXID to determine whether a transfer is absent, pending, successful, failed, dropped, or replaced.
- You can verify the full recipient address instead of trusting a wallet label or screenshot.
- You can identify the actual blockchain used for USDT and check the relevant token-transfer record.
- You can explain why a confirmed transaction is not automatically a correctly matched exchange deposit.
- You know which public evidence to provide to support and which wallet secrets must never be disclosed.
- You can avoid the most dangerous reaction to a delayed deposit: sending the same payment again before locating the first transaction.