
Destination tags
4 minDifficulty Checked 2026-11-10- Exchanges share one address among many customers. The destination tag says which customer to credit.
- A tag is a whole number that fits in 32 bits. The ledger does not interpret it.
- An address can require tags. Payments without one then fail and no XRP moves.
Picture an apartment building with one street address. The mail carrier needs the apartment number too. Without it, the letter reaches the building and nobody knows whose it is.
An exchange works the same way on the XRP Ledger. It often keeps one address for all its customers. Your destination tag is your apartment number. It is a plain number the exchange gives you. When you deposit, you enter the exchange's address and your tag.
Why not give every customer their own address? Every address on the ledger must be a funded account, and each one locks 1 XRP. One shared address with tags is far lighter.
If you forget the tag, one of two things happens:
- The exchange requires tags on its address. The ledger rejects your payment and the XRP never leaves your account. You pay only the tiny fee.
- The exchange does not require tags. The XRP arrives and nobody knows it is yours. You have to contact support and wait.
The ledger does not check that a tag is the right one. A wrong tag still goes through. Copy the tag exactly.
A self-custody wallet has one owner, so paying it needs no tag. Tags are for addresses that serve many people.
Some services show an X-address instead. On Mainnet it starts with X. It packs the address and the tag into one string, so there is one thing to copy.
DestinationTag and SourceTag are optional fields, each a 32-bit unsigned integer. They have no on-ledger function. They tell off-ledger systems how to process a payment.
| Field | Meaning |
|---|---|
DestinationTag | The hosted recipient to credit, or the reason for the payment |
SourceTag | The sender on whose behalf the payment was made |
Returns. When a service bounces a payment, it uses the incoming SourceTag as the DestinationTag of the return. The docs suggest sending the return as a partial payment.
Requiring tags. An account turns the rule on with AccountSet and SetFlag: 1 (asfRequireDest). The ledger stores it as lsfRequireDestTag (0x00020000) on the AccountRoot. A Payment with no tag to that account fails with tecDST_TAG_NEEDED. Check any address with account_info and read its Flags.
The ledger cannot know which tags are valid in a business's system. A service still has to handle payments with a wrong tag.
Privacy. All transactions are public. Tags handed out in numerical order make it possible to guess which tag belongs to which customer. The docs advise assigning them in an unpredictable order.
X-addresses. XLS-5 defines the format. An X-address encodes a classic address and a tag in one base58 value with a checksum. Mainnet X-addresses start with X and Testnet ones with T. The tag acts as a source tag when sending and a destination tag when receiving.
Memos are a separate field. Memos is an array on any transaction, up to 1 KB when serialized. Each memo has MemoData, MemoFormat and MemoType, all hex. A memo does not set DestinationTag. An account that requires tags checks only the tag field.
Related: Who holds the keys, Partial payments.
- Source and Destination TagsRead 2026-11-10
- Require Destination TagsRead 2026-11-10
- AccountSetRead 2026-11-10
- Transaction Common FieldsRead 2026-11-10
- Bouncing PaymentsRead 2026-11-10
- XLS-5 Tagged AddressesRead 2026-11-10
