XRP destination tags: the integer that decides who gets paid

An XRP address without a destination tag is a building without apartment numbers. The mail arrives. Nobody knows whose it is.

Most chains give every customer their own address. Bitcoin does. Ethereum does. You derive a fresh address per invoice, watch it, and the address is the identity of the payment. The XRP Ledger breaks that assumption, and the break is the single most common way an XRP payment goes missing. It is almost never lost. It is unattributed, which from the payer's seat feels identical.

What the tag actually is

A destination tag is an unsigned 32-bit integer carried alongside the payment, separate from the address. That is the entire mechanism. No magic, no second signature, just a number between 0 and 4,294,967,295 that travels with the transaction and tells the receiver which sub-account the funds belong to.

The reason it exists is architectural. Opening an account on the XRP Ledger costs a reserve — XRP that gets locked up for as long as the account exists. An exchange or a payment processor taking deposits from a million customers does not open a million ledger accounts and burn a million reserves. It opens one account, publishes one address, and disambiguates the million customers with a tag per customer. The address answers which institution. The tag answers which account inside it.

This is why XRP belongs to a small family of "shared-address" assets where the routing detail lives outside the address — the same family as a Cosmos or BNB Beacon Chain memo, or an XLM memo. Different word, identical problem: the network delivers to the address, and a second field decides attribution.

Why the failure is so quiet

Here is the part that catches teams off guard. On Bitcoin, sending to a wrong or malformed address fails loudly — the transaction won't build, or it lands somewhere provably unrecoverable. On XRP, a payment with a missing destination tag to a shared address succeeds. It confirms in three to five seconds. The payer sees a green check. The funds are sitting in the receiver's pooled account with no marker saying who they're for.

xrp · address shared, tag routes

Now it's a support ticket instead of a payment. The receiver has the XRP and a transaction hash, but reconciling it back to a customer means a human reading timestamps and amounts and guessing. Most large exchanges publish a recovery process for exactly this, and it is slow on purpose, because guessing who owns money is a risk they price in friction. A tagged payment skips all of it.

What this means for accepting XRP

If you take XRP into a pooled account, the destination tag is not optional metadata. It is the primary key. Three rules fall out of that, and we hold all three when halfin processes XRP deposits:

1. Generate a unique tag per invoice, and treat it as required. A payment that arrives with no tag, or with a tag you never issued, cannot be auto-attributed. It is not "close enough" — it is a different category of event that needs a human.
2. Tell the payer the tag in the same breath as the address. A payment instruction that shows the address prominently and buries the tag is an instruction designed to lose money. Address and tag are a pair; present them as a pair.
3. Don't reuse tags carelessly. A 32-bit space is large, but if two open invoices share a tag, an on-time payment to one is indistinguishable from a late payment to the other. Tag uniqueness is what makes the row unambiguous.

There is a cleaner alternative the Ledger also supports: a per-customer or per-invoice account, no tag needed, because the address is once again unique. It costs the reserve. For a high-volume processor that math rarely favors a fresh account per invoice, which is exactly why the tag convention won. Knowing why the industry standardized on tags is what stops you from treating them as an afterthought.

The acceptance edges that bite

A few specifics worth internalizing before you wire up an XRP rail:

• Tag 0 is a real value, not "no tag". Some wallets and some integrations conflate an empty field with 0. They are not the same. If your system issues tag 0 to a customer and another system reads "no tag provided" as 0, two different intents collide on the same integer. Decide early whether 0 is reservable in your scheme.
• Some receivers reject untagged deposits outright. An account can set a flag requiring a destination tag on every incoming payment. That turns the quiet failure into a loud one — the payment bounces instead of pooling unattributed. It is a good default for a deposit account, and it changes the payer's experience: an untagged send fails at submission rather than arriving and vanishing.
• The tag is on the payment, not baked into the address. Wallets that support XRP let the payer enter the tag in a dedicated field. A few encode address-plus-tag into a single string (the X-address format) so the pair travels together and can't be split. If a payer's wallet only shows an address box and no tag box, that is the moment to stop and check, because that wallet will produce an untagged transaction.
• It is a routing detail, not a security control. A destination tag is not secret and not a password. Anyone watching the ledger sees it. It identifies an account; it does not authorize anything. Don't lean on it for anything beyond attribution.

How it sits next to other rails

We've written before about how the right rail depends on your counterparty, and XRP fits that frame. Its pitch is speed and a fee that rounds to nothing — settlement in seconds, deterministic finality, no fee market that spikes during a busy hour. The cost of that design is the tag: you trade per-customer addresses for a shared address plus a routing integer, and the integer becomes a thing you cannot get wrong.

For a payments team, the takeaway is narrow and firm. On most chains, correctness means watch the right address. On XRP, correctness means issue the right tag, show it next to the address, and require it on the way in. Get that one integer right and XRP is one of the fastest, cheapest rails you can offer. Get it wrong and every untagged payment becomes a person reading transaction logs at the end of the day.

The address tells the ledger where the money goes. The tag tells you whose it is. On the XRP Ledger those are two different questions, and a payment isn't really done until both are answered.

M. Voss, halfin network research