XRPL Request URI

Overview

XLS-32d ("Request URI Structure") is an XRP Ledger proposed standard that defines a universal URI scheme for links and [[qr-code|QR codes]] used to make payments and share data between XRPL applications [1, 2]. Its goal is interoperability: instead of every wallet inventing its own link format, XLS-32d standardizes the syntax and semantics for off-chain requests that point at on-chain XRPL data or prepare a transaction for signing [1, 2].

The scheme uses the protocol name xrpl with an optional version suffix, and a required type token that says what kind of request the URI carries [1]:

<protocol>:<type><query>          protocol = "xrpl" [ "." version ]

A defining feature is its use of the X-address format to embed an account together with its destination tag in a single field — eliminating the classic XRPL footgun of forgetting or mistyping a destination tag [1, 3].

History

XLS-32d was authored by Ryan ("interc0der"), created 2022-07-28, in the Ecosystem category of the XRPLF/XRPL-Standards repository [1, 2]. It builds on earlier XRPL destination-information work — XLS-2d (destination information) and the X-address tagged-address format (XLS-5d) — which it explicitly supersedes for embedding the destination tag [1, 3, 4]. The proposal's status is listed as Stagnant / draft, and the original discussion thread was later closed in favour of the in-repo spec document [1, 2]. When the type field is omitted, XLS-32d defaults to the older XLS-2 form xrpl:<address>[&dt=<tag>] for backward compatibility [1].

Technical specification

Request types

Seven type values are defined [1, 2]:

Type	Purpose	Key parameters
account	A single XRPL address (optionally tagged)	address (required), tag (optional), or xaddress
ledger	A ledger by sequence number	seq (256-bit)
tx	A transaction by hash	hash (256-bit hex)
payload	A transaction prepared for an XRPL client to sign	tx (serialized transaction), callbacks uuid / url / jwt
offline	An air-gapped signed transaction blob	blob (hex signed tx), callbacks uuid / url / jwt
token	An issued-currency reference	address (issuer, required), code (currency code, required)
nftoken	An NFT reference	id (256-bit token hash)

The type field is required and determines parsing; all characters must be URI-encoded [1, 2].

X-address embedding

For the account type, the destination tag can be supplied either as a separate tag parameter or — preferred — folded into a single X-address via the xaddress parameter [1, 3]. An X-address packs the 160-bit account ID, flags, and a 64-bit tag into one Base58Check value beginning with X (mainnet) or T (test), so a payer cannot omit or mistype the destination tag [3]. Example [1]:

xrpl:account?address=rpfBYsmNBB7Y6z7qHS8g26KE3y3hHaTxkq&tag=000001
xrpl:tx?hash=73734B611DDA23D3F5F62E20A173B78AB8406AC5015094DA53F53D39B9EDB06C
xrpl:token?address=rpfBYsmNBB7Y6z7qHS8g26KE3y3hHaTxkq&code=USD
xrpl:nftoken?id=000B013A95F14B0044F78A264E41713C64B5F89242540EE208C3098E00000D65

Callbacks and size

For payload and offline types, callbacks mirror an OAuth2-style flow: status updates route to https://{url}/{uuid}/{status} with statuses such as /scan, /sign, /reject, /error, and /expire, letting a requester learn the outcome of a signing request [1]. The spec advises keeping URIs under ~3 KB so they remain reliably scannable as QR codes on low-end devices [1].

Security

Because a URI can arrive from an untrusted source, the spec calls for strict parsing, limited parameter sets to reduce attack surface, CSRF protection on callbacks, and mandatory user review before any value-transferring transaction is signed [1, 2].

Use cases

• Tagged payment QR: an exchange or merchant encodes an account request with an X-address, so the payer's wallet automatically applies the correct destination tag [1, 3].
• Delegated signing: a payload request hands a prepared transaction to a signer's wallet and learns the result via the callback flow [1].
• Data references: tx, ledger, token, and nftoken types let one app link another straight to a specific transaction, ledger, issued currency, or NFT [1].

Implementations

• XRPLF/XRPL-Standards — the specification repository hosting the XLS-32 document and its discussion [1, 2].
• xrp-community/xrpl-tagged-address-codec — TypeScript library to encode/decode X-addresses (account + destination tag), the format XLS-32d relies on [5].
• The reference site xrpaddress.info documents the X-address format used by the account/xaddress parameter [3].
• A community implementation (standardconnect/xls-32d) was referenced in the proposal discussion as an early demonstrator [2].

Comparison

Versus a plain XRPL address QR — which on XRPL is genuinely dangerous because a missing destination tag can lose funds at custodial recipients — XLS-32d's account type with X-address bundles account + tag into one mistake-proof value [1, 3]. Compared with the older XLS-2 xrpl:<address>&dt=<tag> form it supersedes, the typed scheme also covers transactions, ledgers, issued tokens, and NFTs, plus a payload signing flow with callbacks — closer to Stellar SEP-7's tx operation (stellar-sep-7) or TON's bin payload deep links (ton-transfer-uri) than to Cardano CIP-13's payment-only links (cardano-cip-13) [1]. It lacks SEP-7's cryptographic signed-origin mechanism, instead leaning on strict parsing and user confirmation for safety [1].

Status

Draft / Stagnant. XLS-32d is a numbered, published XRPL proposed standard, but it has not advanced through ratification and its repository status is marked stagnant; the X-address format it depends on, however, is established and widely used across XRPL [1, 2, 3].

Sources

1 XLS-32: Request URI Structure — XRPLF, 2022 2 0032 XLS-32d: Request URI Structure (discussion) — XRPLF, 2022 3 The new XRPL X-address format — xrpaddress.info, 2026 4 0002 XLS-2d Standard for XRPL destination information — XRPLF, 2020 5 xrpl-tagged-address-codec — GitHub, 2022

Deployments

No country reports mention this standard by name.

Regions / aggregations not mapped to a single country

• Universal