What is a memo or destination tag?
A deposit memo or destination tag supplies extra routing information that a receiving service may need to credit your account. The blockchain address identifies the on-chain destination; the extra field can identify a customer behind a shared address. It is not a password, private key or recovery phrase.
On the XRP Ledger, a destination tag can tell an exchange which customer should receive an internal credit. The ledger does not use that tag to maintain the exchange's customer balances: that mapping belongs to the service. Sending to the correct address therefore does not, by itself, prove that the correct exchange account will be credited.
This guide focuses on that missing-field problem. For the broader network, fee and confirmation checks, use the existing sending-crypto guide. Do not copy example addresses or tags from an article; obtain current instructions inside the verified receiving service.
XRP tags and Stellar memos are not one universal format
XRP Ledger destination tags are unsigned 32-bit integers. A receiving account can enable RequireDest, causing a payment without a destination tag to be rejected. That requirement only establishes that a tag is present; it is not a check that the tag belongs to your customer account.
An XRP X-address can encode a classic address and tag together. Do not assume every sending interface accepts that format or extracts it as intended. Follow the receiving service's supported format and confirm the final details. A separate source tag identifies information about the sender; it is not a substitute for the recipient's destination tag.
Stellar supports transaction memos with defined types, including text and numeric IDs. Stellar also documents muxed accounts as another approach to routing within pooled accounts. The important practical question is which format the recipient and sending interface support, not whether a blog calls every extra field a memo.
A field that is optional at the network level can still be required by a service. Kraken requires its supplied tag for XRP deposits. For XLM, its documentation distinguishes two routes: a supported muxed address starting with M incorporates the routing information and does not need a separate memo; its traditional shared G-address route needs the supplied numeric memo. Follow the current route shown in your account. These are provider-specific instructions, not a rule that every personal XRP or Stellar address needs the same extra field.
Read the receiving instructions before the sending form
Open the receiving account through its verified app or website. Select the asset and supported network, then read the deposit address, memo/tag label, value and any type requirement together. Check the minimum deposit, supported transaction method and current service status. Save a private record of those instructions for your own reconciliation.
Compare the full address and the exact requested field in the sender's final confirmation. Do not copy an exchange's sending address from transaction history as if it were your deposit address. Do not substitute an order ID, account email or a tag belonging to another account.
If the receiver requires a field but the sending interface has no place for it, stop and consult both providers' official instructions. A field marked 'optional' by the sender does not override the recipient's requirement. Equally, do not invent a memo when the receiver explicitly says none is needed.
A test deposit, if appropriate, must still follow all requirements, including the minimum after any deducted fee. A tiny transfer below the minimum may not answer the question you wanted to test. Wait for the actual receiving account credit, not just an explorer success message, before treating a test as successful.
- Asset and network are supported by the receiving service.
- Full address comes from current verified deposit instructions.
- Required memo/tag value and type match the final sending screen.
- Net deposit and transaction method meet the receiver's rules.
- A completed test is credited to the intended receiving account.
Five-minute practice: separate delivery from account credit
This is an offline, fictional exercise. Do not send funds. NETWORK-A and VAULT-A are teaching labels, not usable network names or addresses. In this invented service, customer Mina is assigned numeric tag 4821 and customer Leo tag 4822 at the same VAULT-A address. The service requires a tag and a net deposit of at least 10 UNIT.
Review three proposed records. A: NETWORK-A, VAULT-A, tag 4821, net 12 UNIT. B: NETWORK-A, VAULT-A, tag 4822, net 12 UNIT. C: NETWORK-A, VAULT-A, no tag, net 12 UNIT. Which matches Mina's instructions? A matches the stated identity and minimum checks. B points to Leo's fictional routing entry. C omits required information. Matching the address in all three does not make them equivalent.
Next consider D, which has the right network, address and tag but sends 10 UNIT with a 0.4 UNIT fee deducted from that amount. The net deposit is 9.6 UNIT, below the fictional 10 UNIT minimum. If a different service charged the fee separately, the recipient amount could differ; inspect the quote rather than assuming one fee convention.
Finally suppose A appears successful on the network explorer but the exchange balance has not changed. That establishes neither automatic credit nor a lost deposit. Compare the receiving service's confirmation and processing requirements, then collect the transaction evidence if its stated checks do not explain the delay. Change Mina's required tag to 4823 and repeat the comparison: even record A now fails the updated instruction.
What if you already sent a missing or wrong memo?
Do not keep sending additional transfers to try to repair the first one. Check the transaction on an explorer for the correct network and record its status, full destination, actual memo/tag, amount, transaction ID and timestamp with timezone. Compare these with the receiving instructions and your exchange deposit history.
Then contact the receiving service through its official support route. Explain whether the field was absent, mistyped or copied from another account, and provide the public transaction evidence through that private support case. A transaction ID can reveal financial activity, so avoid posting an account's full history publicly.
Kraken's recovery policy explains that unsupported networks, missing or incorrect memos and outdated addresses can create uncredited deposits, and that recovery is not always possible. The available procedure depends on the receiving platform and the specific transaction. A successful chain transaction does not guarantee that support can reverse, retrieve or assign it.
A promise of guaranteed recovery from a stranger is not a solution. Keep recovery phrases and private keys out of messages, forms and support chats. A legitimate investigation of public transaction details does not require those signing secrets.
Keep three separate completion checks
First, did the final transaction match the recipient's current network, destination and routing instructions? Second, did the network process the transaction as expected? Third, did the intended service account receive the corresponding credit? Keep those answers separate in your notes.
For repeat deposits, reopen the current receiving instructions rather than trusting an old screenshot or a saved label. Providers can change supported methods and deposit details. Retain enough evidence to reconcile the result, without exposing account credentials. The useful outcome is a verified account credit, not merely a familiar-looking address.
Sources & further reading
- XRP Ledger: source tags, destination tags and RequireDest
- XRP Ledger: classic addresses and X-addresses
- Stellar: transaction memos and their types
- Kraken: destination tags for XRP deposits
- Kraken: memos for XLM deposits
- Kraken: missing deposit checks
- Kraken: deposit recovery scope and limitations
Educational content. Examples are illustrative. Protocols, products and rules can change; consult the linked documentation for current details.