XRP Destination Tags: What They Are and When You Need One

The expensive mistake is leaving the tag box empty on an exchange deposit and finding out afterwards. The rest of this page is why it happens and what recovery looks like, so you can avoid learning it the hard way.

What a destination tag is

A destination tag is a number attached to a payment that marks what the payment is for. Source and destination tags are a feature of XRP Ledger payments that mark specific purposes for money moving to or from multi-purpose addresses. The destination tag points at the beneficiary. In the Payment transaction, the DestinationTag field identifies the reason for the payment, or a hosted recipient to pay.

Both tag types are 32-bit unsigned integers, so a tag is a plain whole number, never text. It carries no name, no email and no note. Its meaning lives in the records of whoever owns the receiving address.

The ledger does not act on a tag. Tags only inform off-ledger systems how to process a payment. Picture the address as a building’s street number and the tag as the apartment label: the post office delivers to the building, and the building’s staff decide what the label means.

Why exchanges and issuers need them

Tags let one address serve millions of customers without a funded account each. An address must be a funded, permanent account to receive payments, so giving every customer their own would burden every server on the network and lock up reserve for each address indefinitely. Source and destination tags are a lighter way to map deposits and payments to individual customers.

The reserve cost is real. When checked on 2026-10-21, Mainnet asked for a base reserve of 1 XRP and an owner reserve of 0.2 XRP per item. Multiply that by every customer and a single shared address wins easily. The reserve guide explains how those amounts are set.

A tag can do several jobs for a business:

A payment to an exchange or stablecoin issuer address can use a tag to say which customer to credit in that business’s own systems. A merchant could use one to show which item or cart a payment buys. Hosted accounts typically use a tag for each customer.

When you do not need one

You need a tag only when the receiving address expects one. Sending to your own wallet, or to another person’s personal address, needs none. The need arises when the recipient is a hosted service with a shared address, and the service tells you which tag to use.

Without a tag the trouble is bookkeeping. For an address that may receive money for several customers, an untagged payment leaves it unclear whom to credit. The money arrives. The receiver just cannot tell who sent it, or for what.

What happens if you send without a required tag

An address owner can block untagged payments at the ledger level. With the Require Destination Tag setting on, the XRP Ledger rejects any payment to that address that does not specify a tag. The setting suits addresses that host balances for multiple people or purposes, and it exists to stop senders from forgetting the tag. The owner is spared money they cannot assign. A rejected untagged payment fails with the error code tecDST_TAG_NEEDED.

The check has a limit. The ledger cannot know whether a specific tag is valid in the owner’s system, so the owner still has to be ready for payments carrying the wrong tag. That usually means a support process that can track down misdirected payments, credit the right customers and sometimes bounce unwanted payments.

The two cases end differently:

• The address enforces tags. The ledger rejects the payment with tecDST_TAG_NEEDED. Nothing was delivered, so the XRP never left your account apart from the transaction cost.
• The address does not enforce tags. The ledger accepts the payment and the XRP lands in the exchange’s shared address, but the exchange cannot tell whose it is. Do not send it again. Contact the exchange’s customer support and ask for a recovery, with the transaction hash copied as text, not a screenshot, and your sending address.

Whether the exchange can fix it is its own call. Recovery depends entirely on the exchange’s policy, and at least one exchange says it will not be able to locate or reverse funds sent without the tag. Copy the tag before you send.

Source tags

A source tag names where a payment came from; a destination tag names where it goes. Source tags indicate the originator of a payment, and the most common reason to include one is so the recipient knows where to send a returned, or bounced, payment.

On returns the two work as a pair. When you send an incoming payment back, use the source tag from that payment as the destination tag of the return. The common-fields convention for the SourceTag field is the same, and xrpl.js repeats it. A business that tags its outgoing payments can then match every bounce to the payment that prompted it.

X-addresses carry the tag inside

An X-address combines a classic address with a tag into a single string that encodes both. In an X-address the tag acts as a source tag when you send and a destination tag when you receive. These addresses start with X on Mainnet and T on test networks.

The format is one Base58 string encoding the account ID, the tag, and whether the address is meant for a test network. Its practical benefit: users cannot unintentionally leave the tag out when sending or receiving. Tools across the ecosystem are encouraged to support it.

One caveat. The protocol itself natively supports only classic addresses, though many client libraries also handle X-addresses. A wallet or exchange that does not recognize an X-address will not accept it, so when in doubt keep the classic address and the tag as separate values.

Tag versus memo

Different fields, different jobs. A destination tag is a 32-bit integer. The Memos field holds arbitrary messaging data on a transaction, limited to 1 KB when serialized in binary form. A memo can hold text; a tag cannot. Receiving systems that route deposits read the tag, and nothing in the protocol makes a memo a substitute. A service that asks for a destination tag wants the tag field filled in, not a note.

Before you send

• Copy the address and the tag from the receiving service, not from memory.
• Paste the tag into the destination tag field, not the memo field.
• If the service gave you an X-address, use it whole.
• If the recipient is new to you, send a small test first. For a brand-new wallet the test must still cover the reserve, as the exchange-to-wallet walkthrough explains.
• When returning a payment, reuse the incoming source tag as the destination tag.

For businesses that receive XRP

Everything above is for the person sending. These two sections are for the operator who owns a shared address.

Turning on the Require Destination Tag setting

An address owner enables it with an AccountSet transaction that sets the asfRequireDest flag, value 1, in the SetFlag field. To test it, send a payment to that address without a tag; it should fail with tecDST_TAG_NEEDED. A payment that includes a tag goes through. Most holders never touch this. It matters for anyone running an address that receives funds on behalf of others, and the transaction costs the standard fee covered in the transaction cost guide.

How businesses should hand out tags

Not in a guessable order. Every XRP Ledger transaction is public, so assigning tags in plain numerical order makes it possible to guess which tags belong to which users, or to infer details about their accounts. Sequential numbering gives customers less privacy.

The documentation suggests a different approach:

• Divide the total range of tags into sections, one per purpose.
• Assign tags in an unpredictable order inside each section.
• Generate them with a cryptographic hash such as SHA-256, then use the modulo operator to fit the output to the section’s size.
• Check for collisions with old tags before using a new one.

That prevents overlap while protecting privacy. For a developer the field is simply set in the payment transaction; a payment type that holds funds first is covered in the escrow guide.

More address basics sit in the accounts guides.