Definition and scope
XRP Destination Tags Explained addresses a distinct part of payments and transfers. Understand how custodial services use tags to identify customers sharing one ledger address.
XRPL payments range from direct XRP transfers to routed cross-currency delivery, escrows, checks, and payment channels. This collection focuses on what users and applications must verify before signing and what the validated ledger proves afterward. A payment workflow is complete only after a validated ledger proves the result. Service crediting and recovery remain off-ledger responsibilities.
How it works
DestinationTag is an unsigned 32-bit value used by recipients such as exchanges to map one shared XRPL address to an off-ledger customer or purpose. The ledger does not interpret the business meaning of the number.
- DestinationTag: verify this field, object, or component against the cited protocol documentation.
- SourceTag: verify this field, object, or component against the cited protocol documentation.
- shared address: verify this field, object, or component against the cited protocol documentation.
- off-ledger credit: verify this field, object, or component against the cited protocol documentation.
Practical example and checks
Copy both the service's classic address and required tag, show them separately during review, submit the Payment, and retain the validated transaction hash for support.
For production use, preserve the exact signed or queried data, record the network and validated ledger reference, and compare the result with the current primary documentation before changing off-ledger state.
Open the related live demo or evidence lab →Limits, risks, and common confusion
A correct address with a missing or wrong tag can reach the service while failing to credit the intended account. Recovery depends on the recipient and is not guaranteed by XRPL.
A payment workflow is complete only after a validated ledger proves the result. Service crediting and recovery remain off-ledger responsibilities.
Current network status
Enabled on XRPL Mainnet. The underlying protocol capability is available on XRPL Mainnet. Individual services can still impose additional rules, limits, or trust assumptions.
Status reviewed 2026-08-23. Amendment-dependent behavior must be rechecked against the network's live feature state before operational use.