Tags can identify hosted-account beneficiaries.
XRP Payment Attribution Guide
XRP destination tags tell a shared-address system which customer or contract to credit.
XRP destination tags are 32-bit unsigned integers attached to XRPL transactions so an off-ledger system can attribute a payment arriving at a shared address. The tag supplies routing context; it does not create a separate wallet or control funds on the ledger.
What tags do
A tag adds payment context to a shared destination address.
Exchanges, issuers, merchants and applications can assign tags to customers, invoices or contracts. The destination address receives the payment; the off-ledger system interprets the tag.
They can map payments to orders or contracts.
The number has no universal meaning.
The recipient defines how its tags are interpreted.
What tags do not do
A tag does not enforce payment logic on-ledger.
XRPL records the number, but the ledger does not know which customer, invoice or agreement it represents. Correct crediting depends on the recipient’s application logic.
Tags do not create separate wallet balances.
They do not prove a deliverable was completed.
They do not replace amount verification.
They should not contain secret credentials.
Missing tags
Omitting a required tag can create an ambiguous payment.
When many users share one address, the recipient may see the funds but not know whom to credit. Manual investigation may be necessary unless the account requires destination tags.
RequireDest can reject payments lacking a tag.
RequireDest cannot determine whether a supplied tag is valid.
Wrong tags can still need support intervention.
Always copy payment instructions from the intended workflow.
Tags in contracts
Unique tags can associate funding with a specific agreement.
A platform can issue a tag for a contract and match incoming ledger activity to that record. Verification must still check the destination, asset, delivered amount, validation status and other required context.
Treat the tag and address as one instruction set.
Do not reuse unrelated contract details.
Verify the validated transaction result.
Use X-addresses where the receiving system supports them.
Official XRPL references
Verify the protocol behavior.
Ledger features and amendments can evolve. Check the current XRP Ledger documentation before implementing or funding a transaction.
Attribution
XRP destination tags solve a shared-address accounting problem.
An exchange, platform or merchant can receive many customers at one XRPL address and use each DestinationTag to identify the intended beneficiary, invoice or contract. The official XRPL tag documentation describes tags as information for off-ledger processing rather than direct on-ledger behavior.
The address receives the asset.
The tag identifies the internal purpose.
The receiving application performs attribution.
A tag is not a password or secret.
RequireDest
An account can reject payments that omit a required destination tag.
The RequireDest setting helps shared-address operators avoid receiving untagged payments they cannot automatically credit. It does not verify that the supplied tag is the correct customer’s tag; senders must still copy the exact value from trusted payment instructions.
RequireDest can reject a missing tag.
It cannot correct a wrong tag.
The recipient defines valid internal mappings.
Verify the full address and tag together.
Failure handling
A successful ledger payment can still be operationally misattributed.
If the destination address is correct but the XRP destination tag is wrong, the funds may reach the operator while its internal system credits another purpose or cannot locate the intended contract. Stop duplicate payment, preserve the transaction hash and contact the recipient through an authenticated channel.
Do not resend blindly.
Record the validated transaction hash.
Provide the intended account or contract reference.
Never share seed phrases during support.
Privacy
Predictable tag assignment can leak patterns from public transactions.
Because XRPL transactions are public, sequential tags may allow observers to infer relationships or activity. Operators can use less predictable allocation while checking for collisions. An X-address can also package a classic address and tag into one representation, reducing copy errors in compatible workflows.
Treat tags as public metadata.
Avoid embedding sensitive identity information.
Use collision-safe assignment.
Confirm wallet support before using X-addresses.
Payment checklist
Treat the address and tag as one complete routing instruction.
Before signing, compare the full classic address or decoded X-address, then verify the exact DestinationTag shown by the receiving service. Confirm amount, asset and memo separately. After submission, check validated status and transaction result before assuming the recipient credited the payment. XRP destination tags improve attribution only when the sender, wallet and receiver preserve the same value end to end.
Verify address and tag together.
Verify amount and asset separately.
Wait for validated success.
Confirm application credit after ledger settlement.
Frequently asked questions
XRP Destination Tags: One Wrong Number Can Send Payment Context to the Wrong Place
What is an XRP destination tag?
It is a numeric transaction field that helps a recipient map a payment to a customer, purpose, invoice or other off-ledger record.
Does every XRP payment need a destination tag?
No. Use one when the recipient requires or supplies it.
What happens if I forget the tag?
The payment may be rejected when RequireDest is enabled, or it may arrive without enough information for the recipient to credit it automatically.
Can the XRP Ledger tell whether a tag is correct?
No. The ledger records the tag, while the receiving system decides what that number means.
Explore XRPL Integration →See the commercial solution and payment workflow.Read More Payment Guides →Explore crypto escrow, milestone contracts and safer internet work.Follow the Money →Understand verification, release, refunds and fee routing.Review the Risks →Understand what payment infrastructure can and cannot protect.
Rules before risk
Structure the agreement before money or work changes hands.
Create a wallet-based contract with defined milestones, deadlines, review rules and XRP settlement instructions.