The missing memo, recovering an XRP or TON deposit

On Bitcoin or Ethereum, an address identifies a recipient. On XRP Ledger, Stellar and TON that is not enough: the address identifies an account, and an extra field identifies who inside that account should be credited. That field is called Destination Tag on XRP, Memo on Stellar, comment on TON.

Forgetting it does not make funds vanish. But it turns an automatic deposit into a manual case, and in some situations into a permanent loss. Here is why, and what happens next.

Why the field exists

A service receiving deposits from thousands of customers has two ways to tell them apart.

The first is to create one address per customer. That is what Bitcoin and EVM chains do: generating an address costs nothing, you just derive a key.

The second is to use one address and distinguish customers by a label attached to each transaction. That is the model imposed by the structure of XRP Ledger, Stellar and TON, for a concrete economic reason: on those networks, opening an account requires locking a minimum reserve in the native asset. Opening ten thousand accounts means locking ten thousand reserves. The "one address, many tags" model is the rational answer.

Direct consequence: on these networks the deposit address we give you is shared. The memo is the only thing identifying you. Without it the transaction does land on the account, but nothing says whose it is.

What exactly happens without a memo

Three cases, very different.

Case 1: the network refuses the transaction. Some accounts set a flag (RequireDest on XRP Ledger) that rejects any transaction without a destination tag. That is the best outcome: the transaction fails, your funds stay with you, and you lose only the network fee, negligible on these chains.

Case 2: the transaction lands on an account we control. It is credited to the pooled account without being attached to an order. The funds exist, they are in our treasury, but no automation can attribute them. This is the standard case and it is recoverable — the procedure is below.

Case 3: the transaction lands at another service. You pasted another custodian's address, or you sent from one platform to another without a memo. Recovery depends entirely on the recipient's policy. Some large services charge substantial recovery fees; others simply refuse to process memoless deposits and say so in their terms.

Case 3 is the real source of permanent losses. It does not concern us directly, but it concerns anyone moving XRP between two accounts.

The recovery procedure with us

When a deposit reaches our XRP, XLM or TON accounts without a usable memo, this is what happens.

1. Detection. Our systems continuously reconcile deposit account movements against open orders. An entry with no match is automatically isolated into a manual reconciliation queue.
2. Report from your side. Open a ticket from the help centre with three items: the transaction hash, the address you sent from, and the order number concerned. The hash alone is technically enough, but all three speed up verification.
3. Proof of control. We must establish that the sender is indeed you. Depending on the network that means a signed message from the key that issued the transaction, or a match with an origin platform already identified in your name. This is not a formality: without it, anyone could claim an orphan deposit whose hash they read on a public explorer.
4. Attachment or return. Once proof is established there are two outcomes: the deposit is attached to your order and processed at the rate in force at the moment of attachment, or the funds are returned to the origin address, less the network cost of the return.

Timing depends on the manual queue and on how fast you supply proof of control. It is not instant, and we do not promise a contractual deadline on an operation that leaves the automated path.

What we cannot do

The limits need stating plainly.

• We can do nothing about a deposit sent to another service. If the destination address is not ours we have no access to the account. Your only recourse is that service's support.
• We cannot reverse a confirmed transaction. On XRP Ledger finality is reached in seconds and it is definitive. No operator, no validator, no authority can undo it.
• We cannot guess your identity. A memoless deposit from a shared exchange address, with no possible proof of control, cannot be attributed. That is precisely the scenario that ends in a loss.

How never to end up here

The rules are short, and they cover nearly every incident.

• Read the whole deposit screen. When a memo is required it is displayed beside the address with the same visual weight. It is not an optional field.
• Copy the memo with the copy button, not by hand. One character too many or too few produces a non-existent tag, which is equivalent to no memo at all.
• Paste the memo into the right field. Withdrawal interfaces name it differently: Tag, Memo, Destination Tag, Comment, Message. It is sometimes folded behind an "advanced options" link.
• Send a test amount when the sum is significant. Sending a small amount first costs cents on these networks and proves the whole path works.
• Pick a memoless network when you have the choice. If you are selling USDT, Tron, Solana and Polygon require no memo at all. The comparison is in USDT on TRC-20 or ERC-20.

The TON special case

TON deserves its own note. There the field is called a "comment" and is technically a text message attached to the transaction, not an integer like XRP's Destination Tag. Two traps follow:

• Some wallets send the comment encrypted by default. An encrypted comment is unreadable to the recipient: the deposit arrives as if there were no memo. Check that the encryption option is off.
• The TON address format exists in several variants (EQ... and UQ..., plus raw forms). They denote the same account with different flags. Use the one we display, without rewriting it.

Why newer designs are moving away from memos

The memo is a workaround, not a feature. It exists because creating an account costs something on those networks, and it pushes the burden of correctness onto the least equipped participant: the person sending.

Two developments are slowly removing that burden.

The first is the drop in the cost of holding accounts. When reserve requirements fall, or when a custodian accepts to carry them, generating one deposit address per customer becomes viable again — and the memo disappears from the user's screen even though the network still supports it. Several services have already made that move on XRP Ledger for their largest customers.

The second is address derivation on account-model networks. On TON, a wallet can deploy lightweight contracts derived from a parent, giving each customer a distinct address without the operator managing thousands of key pairs.

Neither change is universal today. Until it is, the practical rule stands: if the deposit screen shows a memo field, that field is as mandatory as the address, and treating it as optional is what turns a routine transfer into a support ticket.

One thing to remember

On XRP, Stellar and TON the address says where the funds go; the memo says who they are for. An address without a memo is an envelope with no recipient name, left at the front desk of a thousand-apartment building.

For per-network deposit requirements, including confirmation counts and address formats, see Choosing your deposit network and the relevant asset page, for example Sell XRP.