An XRP payment can reach an exchange’s blockchain address without appearing in the intended customer’s balance. The destination tag tells the exchange which account to credit when customers share one address. A successful ledger transaction therefore answers only part of the deposit question.
| What you need to know |
|---|
| A destination tag helps a hosted service identify the customer behind an incoming XRP payment. |
| The XRP Ledger does not assign customer balances from tags; the receiving service processes them. |
| An address with RequireDest enabled rejects an incoming payment that omits its destination tag. |
| A validated payment without the required customer details may still need the exchange's manual intervention. |
The XRP Ledger documentation on source and destination tags describes tags as identifiers carried with a transaction. They are unsigned 32-bit numbers, rather than another wallet address. Their purpose is to give an off-ledger system information it can use to attribute a payment.
That creates two separate checks. The ledger processes the transfer to the receiving address. The exchange’s own records then connect that incoming payment with a customer. A transaction hash showing a successful transfer does not prove that the second step used the correct customer information.
The deposit page supplies the missing instruction
Kraken’s XRP deposit instructions provide a concrete example. Kraken says its customers share the same XRP deposit address and receive their own mandatory destination tag. Its stated tag format is ten digits. That is Kraken’s implementation, not a universal length rule for every service using the XRP Ledger.
Copy both fields from the receiving service’s current deposit page and check that the sending wallet has placed the tag in its destination-tag field. A number added to a free-text note is not necessarily the same transaction field. Do not borrow a tag from another customer or reuse an address-and-tag pair just because a previous transfer succeeded; the current receiver’s instructions decide which details to send.
The ledger also supports an X-address format that combines an address and tag. This can reduce separate-field handling where the sending and receiving applications support it. It is not a reason to substitute an X-address for the exact format a deposit page requests. Compatibility still matters at both ends.
What happens when the tag is absent?
The receiving address can enable RequireDest. With that setting, the XRP Ledger rejects an incoming payment lacking a destination tag. This safeguard checks that a tag exists; it does not establish that the supplied number belongs to the intended customer. A wrong tag can therefore remain a customer-attribution problem even when the transaction passes the ledger’s checks.
Without that requirement, an untagged transfer may reach the shared address. Kraken warns that missing tag details can delay a deposit and may make funds irretrievable, and directs affected customers to support. Recovery depends on the receiver’s records and procedures; ledger success provides no guarantee of automatic credit or recovery.
If a deposit is missing, give the receiving service the transaction hash, amount, time and the address and tag actually used. Compare those details with the deposit instructions before sending more funds. A wallet’s private key or recovery phrase is not a destination tag and is not needed to identify the public transaction.
