A crypto deposit memo or destination tag identifies the intended customer when a receiving service shares one blockchain address among multiple accounts. The address gets the payment to that service; the required memo or tag tells its systems whom to credit. Copy both from the receiving account's current deposit instructions. A successful network transaction alone does not prove that your exchange balance was credited.
Get the reference from the receiving account
“Memo” and “destination tag” describe routing fields used by different networks and services. They are not generally two extra references you must supply together. Follow the receiving platform's exact field name, value and format rather than adding your own message.
A service can give two customers the same deposit address and different references. Coinbase documents this shared-address arrangement and says the receiving platform determines when a tag or memo is required. Its guidance also notes that private self-custody wallets generally do not need these references. That is a common arrangement, not permission to ignore the current recipient's instructions. Coinbase's destination-tag and memo guide.
Open the intended receiving account, choose the asset and deposit network, and obtain the address and any required reference together. For example, OKX's documented deposit flow shows the address and applicable tag, memo or comment after the asset and network are selected. This is a venue-specific workflow; your account's available routes may differ. OKX deposit instructions.
A correct reference cannot fix a wrong blockchain or an unsupported asset. Use the separate wrong-network versus wrong-address checks to verify that route. Establish the address's provenance as well: the address-poisoning checklist explains why a familiar-looking entry in transaction history is an unreliable source for a new destination.
A required tag does not verify the customer
On XRP Ledger, destination tags are unsigned 32-bit integers whose meanings are assigned by applications above the ledger. The tag can tell an exchange which customer should receive an internal credit. It does not create a separate on-ledger customer account. XRP source tags describe the sending side and have a different purpose; copying a prior transaction's source tag into a new destination-tag field is not a reliable way to find your deposit reference. XRP Ledger's source and destination tag documentation.
XRP Ledger provides a Require Destination Tag setting. When enabled on the receiving account, a payment without a tag is rejected. However, the ledger cannot check whether a supplied tag belongs to you, another customer or nobody in the service's database. A syntactically valid wrong tag can therefore pass this particular check. XRP Ledger's required-tag tutorial.
A memo's type can matter too. Stellar's official SDK distinguishes numeric ID memos from text memos; it validates IDs as unsigned 64-bit values and text against a 28-byte limit. A sequence of digits displayed as text is not the same memo variant as an ID containing those digits. Use the type specified by the receiver instead of choosing whichever looks similar. Stellar's memo implementation reference.
Do not invent a placeholder such as zero when the receiving service requires a reference you cannot find. Likewise, a sender's “optional” input label says nothing about the receiving service's attribution requirements. Stop at that mismatch and resolve the instructions before submitting.
Some address formats include the reference
An XRP X-address can encode a classic address and tag together. Stellar's M-address similarly represents an underlying G-address and an ID. These are documented formats, not evidence that every exchange or wallet supports them. XRP address-and-tag encoding, Stellar muxed-account reference.
Use the format the receiving service supplies and the sender explicitly supports. If one side expects separate fields, do not strip an encoded address down to a base address and discard the routing information.
Follow four receipts through a shared-address ledger
Consider a hypothetical XRP deposit example. One fictional exchange uses a shared address. Tag 48217 maps to account A; tag 48218 maps to B; tag 99999 has no mapping. For this example, Require Destination Tag is disabled, allowing the missing-tag payment to reach the shared address.
All four payments below are assumed validated and delivered in full. Amounts are received XRP, with no deposit deductions, refunds, trades or unrelated movements. The table tracks only these receipts, not the exchange's complete wallet balance. The exchange's illustrative internal process places unmatched receipts in an unassigned bucket.
| Receipt | Destination tag | XRP received | A credited, cumulative | B credited, cumulative | Unassigned XRP |
|---|---|---|---|---|---|
| T1 | 48217 | 120 | 120 | 0 | 0 |
| T2 | 48218 | 80 | 120 | 80 | 0 |
| T3 | Missing | 35 | 120 | 80 | 35 |
| T4 | 99999 | 15 | 120 | 80 | 50 |
The shared address received 120 + 80 + 35 + 15 = 250 XRP. The initial attribution record reconciles as 120 + 80 + 50 = 250 XRP: account A, account B and unassigned receipts.
Suppose A sent T1, T3 and T4, intending to deposit 170 XRP. A sees only 120 XRP credited, even though every payment reached the service's address. The 50 XRP difference is an attribution problem under these assumptions. Looking at the network's successful-payment status again cannot supply the missing customer mapping.
Now assume the service verifies A's claim to T3 through its support process. It moves 35 XRP from unassigned to A: A becomes 155, B stays 80 and unassigned becomes 15. The reconciliation remains 155 + 80 + 15 = 250 XRP. This is an internal reattribution of T3, with no additional blockchain payment.
Change just one input: suppose T4 used B's valid tag 48218 instead of unknown tag 99999. The initial result would be A at 120, B at 95 and unassigned at 35. The same total still balances: 120 + 95 + 35 = 250 XRP. Balanced totals do not prove correct ownership. Binance explicitly warns that a mistaken tag belonging to another user may direct the deposit to that user's account. Binance's wrong or missing tag guidance.
Use a transfer worksheet before submitting
Keep the deposit instructions beside the sender's final review screen. Record enough to reconstruct the route without storing private keys, seed phrases or API secrets.
| Check | What to record | Reason to pause |
|---|---|---|
| Receiving scope | Platform, account or subaccount, asset and network | The deposit page belongs to another account or route |
| Destination | Full address from the current receiving instructions | The sender's final address differs |
| Routing reference | Exact required value and memo type, if specified | Missing, changed, unsupported or taken from an old transfer |
| Transfer amount | Expected received amount after the sender's deductions | Below the receiver's current minimum or unclear |
| Submission review | Network, address, reference and amount actually being submitted | Only a local address-book label contains the memo |
| Completion evidence | Transaction ID plus receiving-account deposit credit | Only the sender or explorer reports success |
A local nickname such as “my exchange XRP” is not a destination tag. If a wallet offers both an address-book note and a transaction memo field, verify which one is transmitted. When scanning a QR code or loading a saved contact, inspect the resulting fields; the convenience step does not replace that check.
If you choose a small test transfer, make it eligible for the receiving service's current minimum and account for fees. Wait for the intended account to show the expected credit, then recheck the instructions before any further transfer. A test that reaches the shared address but remains uncredited has exposed an unresolved problem. Its explorer receipt is not a reason to send the rest.
If the payment has already been sent
First identify the actual blockchain transaction and its result on the network used by the sender, then compare that network with the receiving instructions. A withdrawal request number or “completed” label from the sender is not enough to establish what the network delivered. Inspect the destination, transmitted reference and received amount where the network exposes them.
Next compare those fields with the receiving account's deposit instructions and deposit history. Classify the situation before acting:
- A rejected payment has not produced the successful receipt assumed in the worked ledger. Check the sender's authoritative balance and transaction state before considering another submission.
- A payment still awaiting the receiver's stated confirmation or processing conditions needs that status resolved; a missing balance does not by itself prove a memo error.
- A settled payment to the correct shared address with a missing, unknown or wrong reference needs an attribution investigation through the receiver's official process.
Preserve the transaction hash, asset, network, amount, sending platform, destination and reference actually sent, plus the intended receiving account. Contact support through the platform's authenticated route. Coinbase says it may assist with an incorrect tag and requests the transaction hash; that conditional wording matters. Coinbase's incorrect-tag guidance.
Recovery is service-specific. Binance documents eligibility limits, retrieval fees and a post-fee minimum below which its process cannot recover a deposit. It also describes returning an approved recovery to the original sender's address. If the sender was another exchange, involve that platform before assuming a return to its shared wallet will credit your account. Binance's recovery conditions.
Do not send a second transfer merely to “add” the forgotten memo. It creates another payment; it does not edit the routing information of the first one. Keep the original receipt's support case and any subsequent transfer separate.
Confirm usable funds before automation relies on them
After the intended account records a deposit, distinguish that credit from funds available for a particular action. The available-versus-total balance guide covers reservations and wallet boundaries that can explain a remaining difference. The trading bot launch checklist then places account and balance checks before execution readiness.
Finish each transfer record with two separate statements: the network delivered this amount to this destination with this reference, and the intended receiving account credited this amount. If the first statement is verified and the second is unresolved, keep the transfer open for investigation and exclude it from any automation budget that requires available funds.