A Memo or Tag can be the information that tells a platform which customer should receive a deposit. The blockchain transaction may succeed at the right address while the customer’s account remains uncredited. Whether you have already sent the transfer determines what you can still change.
Before sending: check the receiving instructions
Open the recipient’s current deposit instructions for the asset and network. If the recipient is another person, ask them to provide those instructions from their receiving account. You need the receiving address and any required Memo, Tag or Destination tag together.
- Select the asset and network on the receiving side.
- Copy the receiving address into the sending form.
- Copy the required tag separately and compare its complete value after pasting.
- Check what the confirmation actually contains before submitting.
When a sending wallet marks a tag “optional,” that describes what the wallet will allow. It does not cancel a receiving platform’s requirement. An address and a tag are separate fields; a QR scan filling the address does not prove that it supplied the tag too.
The memo box is empty. Can I invent a string?
No. Use the exact value supplied in the recipient’s deposit instructions. If those instructions do not require a tag, leave it blank. If the recipient requires one but your sender has no way to include it, resolve that mismatch with the sending service before proceeding.
A dummy 0, an order number or your own UID is not a replacement. The Tag shown on your own deposit page is for other people paying your account. When you send to someone else, use the value supplied by their receiving account.
Read an address and tag as one set of instructions
Suppose a receiving platform supplies one shared address and a customer-specific tag. In this hypothetical example, the address tells you where to transfer the asset, while the tag tells the platform which account should receive the credit. Copying an address from one set of instructions and a tag from another does not produce a verified destination.
When receiving details arrive in separate messages, ask the recipient to confirm that they belong together for the same asset, network and account. A screenshot showing only the tag, without enough context to identify the deposit instructions, leaves that question open. The same applies when you have saved several accounts for one person.
| Receiving instruction | Sending form | Decision |
|---|---|---|
| A tag is required | The exact tag is present | Check the remaining fields and confirmation. |
| A tag is required | The tag is blank or different | Correct it before submitting. |
| A tag is required | No tag field is available | Ask the sending service which supported flow carries it. |
| No tag is required | The form insists on a value | Resolve the conflicting instructions; do not guess. |
A warning acknowledgement is also worth reading in full. A sender may ask you to confirm that the destination does not need a tag. Selecting that acknowledgement while the recipient’s page requires one would leave the underlying mismatch unresolved. It is not an alternative way to supply the missing information.
A tag identifies the account; a network identifies the chain
Some platforms use a shared deposit address for many customers. The tag supplies an additional identifier so the platform can allocate a payment to the intended account. It does not change the selected network or convert the asset.
This creates two separate checks. The actual sending network must be supported by the recipient, and the required account identifier must be supplied. A correct tag cannot repair a wrong-network transfer. Equally, selecting the right network does not compensate for an omitted tag.
When investigating a missing deposit, verify the network before concluding that the tag caused the problem. Look at the original sending record and the recipient’s deposit instructions. If the network itself differs, the wrong-network guide explains the next questions to ask.
Recognizing the field without relying on a coin list
| Label | Examples | Check |
|---|---|---|
| Destination tag / Tag | XRP deposits | The complete recipient-supplied value |
| Memo | ATOM or EOS deposits | The supplied characters, preserving their format |
| No tag requirement | Depends on the asset and destination | Confirm that the receiving instructions do not ask for one |
These examples are a way to recognize the terminology, not a permanent rule that every transfer of that asset needs a tag. A platform deposit and a personal wallet can have different requirements. Recheck when the recipient changes platform, account or deposit instructions.
An address-book entry also needs review. Confirm that it saved the required tag as well as the address and that both still match the current destination. A familiar contact name alone does not prove its stored details are still correct.
Do not confuse a public tag with an account credential
A required deposit tag is information you provide to a sender so a payment can be allocated. A password, authenticator code or recovery phrase is not a deposit identifier. A person helping you understand a tag does not need those secrets to inspect the public transaction or explain which field is missing.
The field names can look similar while serving unrelated purposes. A transaction-reference box on a support form asks about a payment that already exists. A Memo field on a sending form supplies information for the payment you are about to create. Your account UID identifies a platform user. Copy each value only into the field that asks for that identifier.
Retain the full value from its source. If the form reformats what you pasted or refuses the characters, check its explanation before proceeding. Do not shorten the tag, change text into a number or append a note to make it look more familiar. A human-readable message such as “payment for order” is not equivalent to the recipient’s generated identifier.
After sending: what a successful transaction proves
A successful blockchain transaction shows the transfer executed on that network, not that the receiving platform credited it to the right customer. With no tag, the platform may be unable to identify the intended account. With a wrong tag, the payment may even be associated with somebody else.
Does a missing Memo or Tag bounce the coins back by itself?
Do not expect an automatic return. A platform may require a recovery application. An approved recovery can have its own return arrangement, which is different from the original transaction reversing automatically.
The official Tag/Memo recovery guide lists eligibility, required information and possible limits. It also distinguishes deposits into the platform from withdrawals sent to another platform. For an external recipient, contact the receiving platform rather than assuming the sender can assign the deposit.
Missing and incorrect tags can therefore have different outcomes. In particular, a value that belongs to another user is not simply an unallocated deposit waiting for your name to be added. Describe what you actually entered when requesting help.
Separate three possible findings
First, the transaction may show no tag where the receiving platform required one. That supports a missing-tag description, provided the asset, network and address also match. The application should say the value was omitted, rather than supplying the correct value as if it had been transmitted.
Second, the transaction may show a different value. Keep both values in the evidence: what should have been sent and what was actually sent. The receiving platform will decide whether it can associate or recover that payment under its rules. Do not describe a wrong value as blank just because both prevented your account being credited.
Third, the tag may match and the deposit may still be missing. In that case, check execution status, the asset, minimum-deposit conditions and the receiving service’s other requirements. A tag matching your instructions is useful evidence, but it does not establish that every other deposit condition was met.
These findings help route the request. They do not let a sender assign the payment to an account after the transaction has executed. The receiving platform’s own process is needed for any supported correction or return.
Prepare one clear recovery request
Start with the sending record. If there is no TxID, check whether the transfer is still processing, failed or was processed internally. An internal record is not a blockchain hash. Do not invent one or use the receiving address in a field asking for a TxID.
For a broadcast transaction, use the explorer for the actual sending network. Record its status, destination and the tag it contains, if displayed. Then gather:
- The asset, actual network, amount and sending time.
- The TxID and a link to its transaction record.
- The receiving address and the tag that should have been supplied.
- The tag actually supplied, or a clear statement that it was omitted.
- The sending record and any further evidence requested through the official recovery form.
Translate the records into the application’s fields
Start from the form’s labels, then locate each value in its original record. A TxID is not the sending address, receiving address or platform withdrawal-order number. The amount requested may be the amount deposited rather than the amount initially entered before a fee deduction; compare the transaction record with the form’s wording instead of assuming they are equal.
If the form rejects an amount, check its decimal and separator instructions. If it rejects an identifier, confirm that you copied the complete transaction hash for the correct network. An error message is a reason to identify the mismatch, not to submit several approximate values until one is accepted.
The official recovery guide lists situations such as mismatched transaction details, an incorrect sender address and an existing application among reasons a request may not submit. Check the specific reason shown. An existing application should be traced through its reference rather than treated as proof that the original transfer has disappeared.
Hypothetical example: the form asks for the sender’s address
Assume you sent from an exchange and omitted the required tag at the recipient. Your personal deposit address on the sending exchange is not automatically the blockchain address that exchange used to send the withdrawal. If the recovery form asks for the sending address, inspect the original transaction or ask the sending platform to identify it.
The distinction matters because an approved return may go back to the original sending address under the recovery service’s rules. You should not replace that address with your preferred personal address merely because it is easier to recognize. Ask how the return will be handled and what evidence the original sending platform will need to credit your account.
For a self-custody send, your wallet transaction provides the relevant source record. For a platform send, use the platform withdrawal record together with the public transaction. In either case, the correct application values describe what happened; they are not instructions to invent a new history for the payment.
If I missed the memo, will a second send with the tag fix the first?
No. A correct tag on a new payment applies to that new transaction. It cannot add a tag to the earlier transaction. Investigate the original payment using its own record.
Check recovery eligibility and fees before relying on a return. Some transactions cannot be recovered. If an approved recovery returns funds to the original sending platform, you may need that platform to identify and credit the return as a further step.
Track the application and the money separately
If your evidence only shows a shortened address or tag, open the transaction details or use the copy control to obtain the complete value. A cropped screenshot can hide the very difference being investigated. Preserve the original record and provide the details requested by the official form; do not edit the screenshot to make the intended tag appear in place of the transmitted one. When a wallet or platform display does not expose the tag, state that limitation and ask support where to obtain the relevant transaction detail rather than asserting that a hidden field was blank.
Keep a short record of the original TxID, application reference, requested evidence and most recent response. If the outcome is a return, add the return TxID separately. The original deposit and the return are different transactions and may have different amounts once an official recovery charge is applied.
Check the actual credited asset and quantity at the end. If a return has executed but the sending exchange has not credited it, give that exchange the return reference and the original withdrawal reference together. Reopening the recipient’s missing-tag application may not address this later crediting stage.