If a transfer seems to be missing, identify how it was processed before looking for it on a block explorer. Moving funds between your own platform accounts, sending to another platform user and making an on-chain withdrawal produce different records. The button labeled “Withdraw” is not enough to distinguish them.
Define the destination before opening a transfer form
Write down the result you want in plain terms. “Make my USDT available for a spot order” usually describes a change between your own account balances. “Pay another platform user” describes a recipient identified by that service. “Fund an address on a particular network” describes a blockchain destination unless the confirmation explicitly offers internal processing.
Those instructions can start from the same asset balance, which is why choosing by the asset alone does not work. They also have different completion tests: available balance in the target account, credit to another platform user, or execution on the intended network followed by any receiving-service credit.
A transfer does not necessarily exchange the asset. If you move USDT from Funding to Spot, the target is still USDT. If you need USDC instead, that introduces a separate conversion step. Keep that conversion separate in your plan and records rather than expecting a destination-account selection to change the token.
Moving between your own accounts
A platform may keep separate Funding and Spot balances. You can own enough of an asset overall while having no available balance in the account needed for your next action. For example, funds available in Funding may need to be transferred to Spot before placing a spot order.
Use the account-transfer control, select the asset and read both the source and destination. You are moving an existing platform balance; you do not need to supply an external receiving address. Confirm the amount shown as available rather than assuming the total asset balance can all be moved.
After submitting, check transfer history for the amount, direction and status. If you transferred to the wrong account, first check whether the funds are still available there. Funds committed to an order or another product may need different handling from an unused balance. Do not repeat a transfer simply because the original balance display has not refreshed.
Example: enough total assets, no available Spot balance
Assume, purely for illustration, that you hold 300 USDT available in Funding and no USDT in Spot. You want 80 USDT available in Spot. A completed 80 USDT account transfer would move that amount between those two balances; it would not buy another token or send money to another user. The numbers here describe a hypothetical account move, not a fee or an actual account.
Check the resulting account-transfer record first. If it says Funding to Spot and completed, inspect Spot with the USDT filter selected. Looking at the balance of a token you intend to buy later will still show no purchase, because the account transfer did not place a trade.
If the record instead names another destination account, inspect that account and its available amount before deciding how to move funds back. If the record is still processing, you do not yet have the completed movement described in the example. If there is no record at all, check whether the request was submitted rather than assuming it succeeded.
Finally, avoid reconciling through the headline total alone. Other trades, deposits or transfers made during the same period can also change balances. Match this transfer’s own source, destination, asset and amount; then use balances as a cross-check.
Does an internal transfer create an on-chain hash?
No. An account transfer processed entirely within the platform is not broadcast to a public blockchain. Use its platform record or internal transfer ID, not a block explorer.
Sending to another user is a different instruction
For a user-to-user send, the recipient may supply a platform ID, email address or phone number. Enter it in the supported user-send flow and verify the recipient information before confirming. Your own Funding-to-Spot transfer does not send funds to another person, even if both controls use the word “transfer.”
If I send to someone on the same platform by UID, do I pick TRC20?
No. In the user-ID sending flow, you identify a platform recipient rather than a blockchain destination. Check that the recipient and asset are correct, then read the confirmation for the selected processing method.
The same platform name does not guarantee that every account can use every transfer feature. If your account or the recipient’s account is ineligible, resolve the message shown in that flow. Switching to an on-chain withdrawal requires a new set of receiving instructions; the UID does not become a wallet address.
Confirm the person independently of the transfer method
A valid recipient identifier is not proof that it belongs to the intended person. Compare the identifier with the recipient’s own instructions and the confirmation details the service exposes. If a lookup shows a different recipient, resolve that before sending rather than assuming the service merely abbreviated the name.
If the recipient says “send to my exchange account” but also supplies an address from another wallet, ask which destination this payment should use. The phrase names a service, while the supplied address might name a different destination. You need one consistent instruction, not a choice between two guesses.
For recurring payments, label saved recipients with enough context to distinguish the platform-user destination from an on-chain address. When a recipient changes accounts, verify the replacement details as a new destination. An earlier successful send to the same person does not validate a new identifier.
If the recipient cannot be found or the service rejects the send, retain the exact prompt. It might require account-specific support. Do not alter digits, try a similar email address or substitute a blockchain address in an attempt to make the lookup succeed.
An address-based withdrawal can also be processed internally
This is the important exception to “a network dropdown means an on-chain transfer.” Some platforms recognize their own deposit addresses and offer an internal transfer after you enter the address and network. The confirmation can let you choose internal processing or a blockchain withdrawal.
The official internal-transfer guide documents both user-ID sending and address-based sending. It also explains that an internally processed transfer has an internal ID instead of an on-chain TxID. Read the final processing choice rather than inferring it from an earlier field.
Check the amount the recipient will receive and any fee shown for that choice. A statement about an internal transfer’s fee cannot be applied to the blockchain option on the same screen. Once you have confirmed one method, keep the resulting record so you can trace that actual transaction.
Read the confirmation as a complete instruction
Consider a recipient whose payment instructions explicitly require a transaction on a named blockchain, rather than simply a credit to a platform user. Even if the service offers an internal route to an associated address, confirm that the recipient accepts that route. The absence of an on-chain TxID may matter to their own reconciliation process. This is a question about the agreed payment endpoint, not evidence that one method is universally preferable.
Conversely, if the recipient specifically supplied a platform user ID, ask for supported on-chain receiving details before choosing a blockchain route instead. The fact that you can locate some address elsewhere in their profile does not make it the destination for this payment. When the two parties agree to change methods, capture the replacement instruction before submitting, then retire the unused draft so it cannot be accidentally sent later. Only the submitted transaction should be reported as the payment.
| Field | Question it should answer |
|---|---|
| Source | Which available account balance is being used? |
| Recipient | Which user or complete address will receive the transfer? |
| Asset and amount | What token leaves, and how much is deducted? |
| Processing method | Does the service say internal or on-chain? |
| Network and required tag | For an address-based instruction, do these match the recipient’s requirements? |
| Received amount | What does the confirmation say the recipient will receive after any displayed charge? |
If you change the processing method on this screen, reread the instruction. A previously inspected internal-transfer result does not approve a later blockchain selection. In particular, the amount received and the expected reference type may change. Use the final choice when you explain the payment to the recipient.
Choose the record that matches the processing method
| Transaction | Useful record | Next check |
|---|---|---|
| Your own account transfer | Transfer history | Source, destination, asset, amount and available balance |
| Internal user transfer | Internal transfer ID and recipient details | Status and the recipient’s corresponding platform record |
| On-chain withdrawal | Withdrawal status, network and TxID | Blockchain execution, then the receiver’s deposit requirements |
An internal transfer may appear in deposit or withdrawal history with an “Internal” label, depending on the platform. Its position in that history does not turn the internal ID into a transaction hash. Copy the reference that the record actually provides.
For an on-chain withdrawal, use the explorer for the selected network. A TxID appearing is only the start of the check: check whether execution succeeded. The receiving platform may still require additional confirmations or other deposit conditions before crediting its user.
Compare sender and recipient records without mixing identifiers
In the documented internal address-transfer flow, the receiving record can share the internal transfer ID with the sending record. If the recipient is checking deposit history, ask them to look for that internal reference and the asset, rather than searching a blockchain explorer for an ordinary hash.
For an on-chain send, the recipient’s platform may also assign its own deposit reference. That local reference and the blockchain TxID have different roles. Retain both when available: one helps the receiving service locate its account entry, while the other identifies the public transaction.
If two payments have the same amount, amount matching is not sufficient to tell them apart. Use the identifier and actual processing method, then compare the timestamps and their displayed time zones. A small test and a later transfer to the same destination are still separate records.
A displayed “completed” status should be read in context. A completed account transfer should be checked against the target account’s available balance; a completed on-chain withdrawal should be checked against execution and the recipient’s credit requirements. The word does not describe the same endpoint in every system.
When does a Memo need to be filled?
Follow the receiving instructions. Your own account transfer and the user-ID flow normally do not use a Memo. An address-based transfer can still require a Memo or Tag even if the platform processes it internally; do not omit a required tag on that basis.
The official guide explicitly retains tag requirements for relevant address-based transfers. If the recipient requires a tag but your selected flow has no way to enter it, ask the platform how that destination should be used before submitting.
If you chose the wrong method
Locate the original record and establish whether it completed. A transfer to the wrong one of your own accounts, a transfer to the wrong user and a withdrawal to the wrong blockchain address need different responses. Provide support with the actual reference and recipient, rather than opening with an assumed cause.
A completed transfer to another person cannot be treated like a balance you can simply move back between your own accounts. Likewise, sending a second amount on-chain does not correct an internal payment sent to the wrong recipient. Keep the two transactions separate if another payment is later needed.
A concise message for support
Describe the actual route and the missing result. For example, a hypothetical internal-send enquiry could say: “I selected the user-transfer option. My record shows completed with this internal reference, but the intended recipient cannot find a corresponding credit.” Attach the requested record through official support and provide the recipient details required by that service.
For a blockchain enquiry, replace the internal reference with the actual network and TxID, and state whether execution succeeded. For your own account transfer, identify the From and To accounts. These versions help support investigate the relevant operation without first correcting your terminology.
Keep cancellation, return and replacement separate. Cancelling an uncompleted request, receiving a return from another person and sending a replacement payment are different events. Establish the status of the original transaction before describing any later movement as its correction.
When the recipient gives you both a UID and a wallet address, agree which method this payment should use. An internal test validates that user destination only; it does not test the wallet address. If the original transaction went to the wrong network, continue with the recovery steps using its TxID and actual network.