Skip to article
XRPAuthority
Payments · Verified concept guide

X-Addresses vs. Classic XRP Addresses

Compare classic addresses with a format that packages an address and destination tag together.

Published 2026-08-23Reviewed 2026-08-237 minute readBy Matt Barlow
SIMPLE EXPLANATION

Definition and scope

X-Addresses vs. Classic XRP Addresses addresses a distinct part of payments and transfers. Compare classic addresses with a format that packages an address and destination tag together.

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.

TECHNICAL DEPTH

How it works

A classic address identifies an XRPL account, while an X-address encodes a classic address, optional destination tag, and network indicator into one checksummed string for safer interchange.

  • X-address: verify this field, object, or component against the cited protocol documentation.
  • classic address: verify this field, object, or component against the cited protocol documentation.
  • DestinationTag: verify this field, object, or component against the cited protocol documentation.
  • network indicator: verify this field, object, or component against the cited protocol documentation.

Comparison at a glance

Use these dimensions to choose between the concepts without treating their names as interchangeable.

Both formats ultimately identify the same XRPL account.
DimensionClassic addressX-address
Encodes accountYesYes
Encodes destination tagNoOptional
Encodes networkNoYes
On-ledger fieldUsed as Account or DestinationDecoded before transaction submission
PRACTICAL EXAMPLE

Practical example and checks

A wallet can decode an X-address into Destination and DestinationTag transaction fields, reject a network mismatch, and display the decoded values before signing.

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

X-addresses are an application convention, not a separate on-ledger account type. APIs and exchanges may still require classic addresses and explicit tags.

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.