An XRP Ledger destination tag is a 32-bit unsigned integer, so a decimal display such as 00042 represents the same numeric value as 42. But zero and an omitted tag are different, and an exchange's order reference is not automatically a destination tag. Use the recipient's assigned deposit instructions and inspect the actual tag before signing.
Decide whether the copied value is really a destination tag
A deposit page may show an account address, a destination tag and an internal order or customer reference. Those fields do not serve the same purpose. The XRP Ledger tag documentation describes tags as information used by off-ledger systems to allocate payments. The receiving account exists on the ledger; the tag can tell the service which internal beneficiary should receive credit.
Before interpreting leading zeros, read the field label. A string such as ORDER-00042 can be a valid internal reference while being unsuitable for the numeric DestinationTag field. Removing its letters to make the wallet accept it would invent new deposit instructions. Ask the recipient which value belongs in the tag field instead of coercing any reference into a number.
What normalization changes, and what it must preserve
The protocol stores the tag as a number, not the exact sequence of decimal characters in a screenshot. A wallet may therefore display a numeric tag without its leading zeros. That can be ordinary normalization if the intended value is unchanged. It is not evidence that the recipient's account address changed, and it does not imply that a different internal order code should also be normalized.
| What you copied or saw | Protocol interpretation | What to check | Unsafe assumption |
|---|---|---|---|
| 00042 in an explicitly numeric tag field | The decimal value is 42 | The review screen and submitted DestinationTag preserve that value | Any longer reference ending in 42 must mean this tag |
| 0 | A present tag with numeric value zero | The recipient actually assigned zero | Zero is the same as leaving the tag absent |
| An empty tag field | No tag may be included | Whether the receiving account requires one | The network will infer your customer account |
| ORDER-00042 | Not a numeric DestinationTag as written | Whether this is an internal reference instead | Delete the letters and send |
| 4,294,967,295 | The upper bound of an unsigned 32-bit value | The actual assigned value and input formatting | Any numerically valid tag belongs to your deposit |
| 4,294,967,296 | Outside that numeric range | The source and type of the reference | Truncate it until the wallet accepts it |
The boundary values illustrate the field's mathematical range; they are not usable deposit instructions. A service has to assign the tag you use. Numerical validity does not prove customer ownership, and a successful transaction does not prove that the service's internal allocation accepted your interpretation. Keep the original instruction as well as the final transaction record.
Zero is a value; absence is a different condition
A wallet should not silently treat an assigned zero as an instruction to omit the tag. Equally, a sender should not invent zero merely because a form asks for an optional field. The Payment transaction reference defines DestinationTag as an optional numeric field. Optional means it may be absent when the payment arrangement permits it, not that an arbitrary value can replace the receiver's instructions.
Some receiving accounts enable a requirement for destination tags. The protocol can reject a payment missing the field, but that does not mean it validates every tag against the service's private customer database. A wrong but present value can therefore be a different problem from an absent value. Check the final result before deciding whether funds arrived or whether another transfer is appropriate.
Do not put the tag into a different reference field
A source tag describes the sending side; a destination tag identifies the receiving allocation. They are not substitute boxes merely because both accept numbers. A text memo is another kind of field and should not be assumed to satisfy a required DestinationTag. If the sending app offers several references, identify the actual destination-tag control before preparing the payment.
An X-address can encode a classic account address together with a tag, as the official tag guide explains. That is a distinct supported format, not a reason to trim characters from an address manually. If your sender accepts only a classic address and separate tag, obtain a verified compatible representation. If it accepts an X-address, inspect what it decodes and do not add a conflicting tag blindly.
Follow this comparison before signing
- Open the receiving platform's current XRP deposit page and identify the account address and explicitly assigned destination tag. Keep the internal order reference separate.
- Copy the assigned value through the wallet's intended field. If its display changes, compare the numeric value and check that no meaningful digits disappeared.
- For an assigned zero, verify that the final review still includes a tag. For a blank instruction, do not invent a value without confirmation.
- Check the recipient, network, amount and any decoded X-address details on the signing screen. Resolve incompatible formats through verified support.
- After submission, locate the validated transaction and inspect its actual destination tag and outcome. Retain that record alongside the receiving instructions.
The memo and tag checker is a useful reminder to inspect the relevant field, while the XRPScan guide helps locate a submitted transaction. Neither can tell you which private customer mapping a receiving platform assigned. That mapping must come from the actual recipient, not an example tag from a tutorial or another customer's screenshot.
If a payment already has the wrong or missing tag
Provide the receiving service with the transaction hash, amount, time, account or order reference and the tag that was actually submitted. Explain whether the issue is a missing field, a different numeric value or only a padded display. BitPay's destination-tag explanation illustrates why shared receiving arrangements need correct allocation information, but each platform sets its own reconciliation process.
Do not promise yourself automatic recovery or a universal processing fee. A validated transaction cannot be edited afterward by changing the local form, and a second transfer does not alter its tag. Preserve the evidence and let the actual recipient determine whether manual allocation is possible. If the first operation's outcome is unknown, establish it before creating another payment.
For a no-account swap, use the deposit details attached to the current order and verify any required reference before sending. Distinguishing a numeric tag from the order's internal ID makes a later support inquiry much clearer. A correctly normalized number is useful only when it is the value the receiving arrangement actually assigned.
FAQ
What does an XRP destination tag look like?
The on-ledger field is an unsigned integer within its 32-bit range. An example number demonstrates the format but must never replace the tag assigned by your recipient.
Is an XRP destination tag the same as a memo?
Services may use memo as a broad interface label, but the XRP Payment field is specifically DestinationTag. Verify that the sending app places the assigned numeric value in the correct field.
Do I need a destination tag when using Trust Wallet?
The receiving arrangement determines the required tag, not the sender application's brand alone. Read the current recipient instructions and do not invent a tag for a destination that has not assigned one.