Start a crypto transfer with the receiving side's asset, network, address, and required extra information. Check that the net amount meets its minimum and that fees are covered. After sending, use the transaction ID (TxID) on the correct network to check execution and platform crediting. A matching address format or an existing TxID does not prove completion. Do not send if details conflict, the minimum is unmet, or signing content is unclear.
Entering 20 USDT does not always mean the other side receives 20; it might receive 19. Keeping the same address while choosing a cheaper network may also leave a platform unable to credit the deposit. Refreshing the page is unlikely to fix either problem. What needs checking is the full set of receiving conditions.
We will follow one hypothetical 20 USDT deposit from receiving details to reconciliation. You will see when to cancel, when to inspect only the original transaction, and why on-chain success does not replace platform crediting. Work through this route before considering the next amount.
Identify Which Transfer Route You Are Using
An on-chain send, an exchange withdrawal, and an internal platform transfer require different completion evidence. Some create a public blockchain transaction; others mainly update platform records. Using the wrong lookup method can make a pending request look like a completed on-chain transfer.
For wallet, address, and custody basics, see wallet transfer checks. This article examines deposit minimums and troubleshooting in more detail. Necessary conditions stay next to the steps, so completing this check does not require reading every other article first.
Separate On-Chain Sends, Withdrawals, and Internal Transfers
For a self-custody on-chain send, you approve and sign the transaction. An exchange withdrawal starts as a request to the platform and may pass through review, scheduling, and broadcast. A successful-request message does not necessarily mean a searchable blockchain transaction exists. An internal platform transfer may instead use a receiving account or another identifier without a separate TxID.
Identify the action before choosing the record to trace. An on-chain route needs its network and TxID; an internal route uses the service's transfer reference and receiving record. Do not resubmit an unbroadcast withdrawal merely because you cannot find it on a blockchain.
What Must the Receiving Details Include?
At minimum, establish the asset, network, receiving address, and any required Memo or Tag. A platform deposit also requires its minimum net amount, service status, and crediting conditions. Kraken's official “How to deposit cryptocurrencies,” dated August 19, 2026, lists the asset, network, address, extra information, and confirmations separately.
If transferring to your own wallet, establish control of the receiving account and prepare its recovery information. Seeing an address does not prove you will be able to send from it later. Use what your wallet backup covers to check sources rather than funding an account you cannot actually recover.
Match the Network and Token Contract as Well as the Address
The correct address is necessary, but the asset and network must also meet the receiving side's requirements. A sending interface accepting an address does not establish platform support for that deposit route, or that a same-name token is the intended asset.
A Matching Ticker Does Not Establish Network Support
USDT is a token issued by Tether. Check support and identification separately for each network. For the Ethereum-mainnet blockchain, Tether's official “Supported Protocols” can identify the relevant token contract: the address identifying that token's program. A token contract identifies the asset; it is not a substitute for the deposit address supplied by the platform.
Some networks share address formats, and the same key may even correspond to an identical-looking address. A platform may nevertheless offer different crediting support. A cheaper network available to the sender is not necessarily accepted by the recipient. Find a jointly supported route before comparing fees, rather than selecting the cheapest fee and trying to make receiving details fit.
Handle Memos and Tags According to the Receiving Requirements
A Memo or Tag is additional information used by some receiving methods to allocate a deposit. XRP Ledger's official “Source and Destination Tags” explains how destination tags can assign payments to individual customers at a shared address. Some X-addresses already encode the address and tag together, so a separate field is not universally required.
Copy all information required by the receiving page. Do not invent a zero, reuse someone else's tag, or skip verification because you scanned a QR code. If required information has no corresponding sending field, consult trusted official support instead of assuming it will be included automatically. The USDT example below assumes the receiving page does not require a Memo.
A 20 USDT Walkthrough: Check Whether You Can Send
Assume your wallet A sends USDT over Ethereum mainnet to address R supplied by platform M. M is a teaching label, with an assumed minimum received amount of 20 USDT, active deposits, and no Memo requirement. Amounts, thresholds, and fees below are teaching inputs, not any platform's current rules. Nothing was actually sent.
Step 1: Fix the Receiving Details for This Deposit
Open the verified receiving-platform entry point, select USDT and Ethereum mainnet, and obtain the deposit address for this transfer. Record the minimum received amount, extra-information requirements, and service status. R is only a label, not a usable example address. Actual transfers require the details from your own official deposit page.
Return to A, verify that the assets are on the same network and are the same token, and paste the full receiving address. Compare it in sections with the original and recheck the final confirmation screen. With hardware, check the trusted device display too. Do not choose a similar-looking address from an unfamiliar small incoming transfer in transaction history.
If M has suspended deposits or A holds assets only on another network, stop. Bridging requires separate support and risk decisions. Changing a network name in the sending interface does not automatically move existing assets between chains.
Step 2: Compare the Sending Amount with the Net Received Amount
Assume A holds 100 USDT and sends 20 itself, paying the network fee separately in ETH, Ethereum's native coin. If the transaction subsequently succeeds with no other deposit deductions, R receives 20 tokens and meets M's assumed minimum of at least 20. The separately paid ETH fee must not simply be subtracted from the USDT amount.
Now change one condition: send through another platform whose teaching rule deducts a 1 USDT withdrawal fee from the entered 20 USDT. Net receipt becomes 19, below the same minimum of 20. Cancel or revise the plan before sending. The 1 is not a current fee quote, and platforms do not all deduct fees this way. A separately added fee requires a different calculation.
This is why small tests still need a minimum check. A smaller amount does not ensure the recipient will process it. Kraken's “Cryptocurrency deposit is missing,” checked on October 27, 2026, includes deposit minimums in its troubleshooting. This example borrows that checking logic, not Kraken's actual thresholds.
Step 3: Prepare Network Fees and Inspect the Final Signing Request
Return to the self-send branch. Assume A also has 0.004 ETH and this example's maximum fee allowance is 0.003 ETH. That satisfies this funding check. Sufficient USDT does not establish sufficient ETH. The actual fee remains unknown. Gas measures chargeable execution work; see gas limits and actual charges for the distinction between the cap and final charge.
Finally check Ethereum mainnet, the correct USDT, R, 20 USDT, and fee conditions. Sending your own tokens differs from approving a third party to use them. If a straightforward transfer suddenly requests a large allowance for an unknown spender, reject it and investigate. “Only a test” is not a reason to approve content you do not understand.
After Sending, Follow the Same Transaction Through Each Layer
Trace the original transaction instead of using a second transfer to confirm the first one's outcome. The following branches assume submission. Each layer needs its own information before proceeding. With no actual broadcast, record not performed, not a successful deposit.
Step 4: Find the TxID on the Correct Network
Obtain the TxID from the sending wallet's history and look it up in a trusted Ethereum-mainnet block explorer. A block explorer reads public on-chain records. Looking up an ordinary transaction does not require connecting a wallet, entering a seed phrase, or approving a signature. There is no real TxID in this example; a teaching event label is not a searchable transaction.
For an exchange withdrawal without a TxID, first check whether the platform is still processing it. If a supplied TxID cannot be found, check the network and copied identifier, then contact the sending platform. Separate not yet broadcast from looking on the wrong network. A blank lookup is not a reason to pay twice.
Step 5: Verify the Token, Recipient, and Amount
Assume the transaction is included and executes successfully. Inspect token-transfer records for the USDT contract, actual recipient R, and 20 USDT. A token transaction may be sent to the token contract for execution. The outer transaction's recipient field is therefore not necessarily the final recipient of the tokens. Finding an address in one field is not enough.
ERC-20 is a common Ethereum token-interface standard. Its “Token Standard” defines token transfers and related events separately, providing the basis for checking transfer records. If the contract, quantity, or recipient differs, stop at troubleshooting. Do not substitute another same-name incoming token. A matching name or icon cannot replace contract identification.
Step 6: Check Platform Crediting After On-Chain Success
Once on-chain information matches the plan, return to M and check confirmations and crediting for that same deposit. This route is complete only when the platform credits 20 USDT under its rules. On-chain success, platform processing, and an available-balance increase can occur at different stages.
If it remains uncredited, keep the network, asset, TxID, receiving address, amount, and deposit-page requirements for official support. Do not assume a fixed number of minutes remains or send again just to see whether the platform reacts. Follow the platform's current confirmation and processing guidance.
If Funds Are Missing, Identify the Layer First
Not broadcast, pending, failed execution, and uncredited deposits require different responses. Locating the stage tells you whether to contact the sender, the recipient, or stop further actions.
Pending, Failed, and Uncredited Are Different States
Pending means still awaiting processing; inspect the original transaction and the wallet's handling options. For failed execution, inspect the reason. Ethereum.org's official “Gas and fees” distinguishes rejection before block inclusion from on-chain execution failure, where used resources may still incur a fee. If execution succeeded but the platform has not credited it, check the asset, network, minimum, extra information, and platform status instead. Do not confuse a failed transaction with delayed crediting.
If only the wallet display is temporarily missing an asset, verify the network and account first. Public blockchain records and a platform account balance are different sources. A screenshot showing zero is not enough to establish that funds were moved away.
A Second Transfer Does Not Fix a Wrong Network or Missing Information
Recovery after a wrong network, wrong address, or missing Memo depends on recipient control and service support. Another payment cannot guarantee recovery. Kraken's deposit guidance directs incorrect additional information to official support, but that does not mean every error or platform supports recovery.
If you find an outgoing transfer you never initiated, or previously gave recovery information to an unfamiliar site, the problem goes beyond a missing deposit. Stop new signatures and funding, then read responding to a compromised wallet. Do not disclose secrets to a supposed recovery service in a rush to complete the deposit.
Keep a Record of This Receiving Route
Keep the asset and network, when receiving details were obtained, net-receipt calculation, TxID, and final status so an issue can be traced to the same transfer. Recheck current official information next time. One successful small test validates that route on that occasion, not an address, service, or future signature forever.
This article teaches transfer decisions and reconciliation, not investment advice. M, its threshold, and the fees are hypothetical. Real transfers require service and network checks, and mistakes may be unrecoverable.