# XRPL Request URI > Source: https://docs.barcoder.ai/docs/standards/xrpl-request-uri > research date 2026-06-04 · extracted at 2026-10-07 > Publisher: Barcoder — encyclopedia of QR, barcode and payment-code standards Specifications: - [XLS-32: Request URI Structure — XRPL-Standards](https://github.com/XRPLF/XRPL-Standards/blob/master/XLS-0032-tx-request-uri/README.md) - [0032 XLS-32d: Request URI Structure (discussion)](https://github.com/XRPLF/XRPL-Standards/discussions/81) ## Overview **XLS-32d** ("Request URI Structure") is an **XRP Ledger proposed standard** that defines a universal **URI scheme for links and [QR Code](https://docs.barcoder.ai/docs/standards/qr-code)** used to make payments and share data between XRPL applications [1][1], [2][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][1], [2][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][1]: ``` : 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][1], [3][3]. ## History XLS-32d was authored by **Ryan ("interc0der")**, created **2022-07-28**, in the **Ecosystem** category of the `XRPLF/XRPL-Standards` repository [1][1], [2][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][1], [3][3], [4][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][1], [2][2]. When the `type` field is omitted, XLS-32d defaults to the older XLS-2 form `xrpl:
[&dt=]` for backward compatibility [1][1]. ## Technical specification ### Request types Seven `type` values are defined [1][1], [2][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][1], [2][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][1], [3][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][3]. Example [1][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][1]. The spec advises keeping URIs **under ~3 KB** so they remain reliably scannable as QR codes on low-end devices [1][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][1], [2][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][1], [3][3]. - **Delegated signing**: a `payload` request hands a prepared transaction to a signer's wallet and learns the result via the callback flow [1][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][1]. ## Implementations - **`XRPLF/XRPL-Standards`** — the specification repository hosting the XLS-32 document and its discussion [1][1], [2][2]. - **`xrp-community/xrpl-tagged-address-codec`** — TypeScript library to encode/decode X-addresses (account + destination tag), the format XLS-32d relies on [5][5]. - The reference site **xrpaddress.info** documents the X-address format used by the `account`/`xaddress` parameter [3][3]. - A community implementation (`standardconnect/xls-32d`) was referenced in the proposal discussion as an early demonstrator [2][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][1], [3][3]. Compared with the older XLS-2 `xrpl:
&dt=` 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](https://docs.barcoder.ai/docs/standards/stellar-sep-7)) or TON's `bin` payload deep links ([TON Transfer URI](https://docs.barcoder.ai/docs/standards/ton-transfer-uri)) than to Cardano CIP-13's payment-only links ([Cardano CIP-13 (Cardano URI)](https://docs.barcoder.ai/docs/standards/cardano-cip-13)) [1][1]. It lacks SEP-7's cryptographic signed-origin mechanism, instead leaning on strict parsing and user confirmation for safety [1][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][1], [2][2], [3][3]. ## Sources [1]: https://github.com/XRPLF/XRPL-Standards/blob/master/XLS-0032-tx-request-uri/README.md [2]: https://github.com/XRPLF/XRPL-Standards/discussions/81 [3]: https://xrpaddress.info/ [4]: https://github.com/XRPLF/XRPL-Standards/discussions/27 [5]: https://github.com/xrp-community/xrpl-tagged-address-codec [1] [XLS-32: Request URI Structure](https://github.com/XRPLF/XRPL-Standards/blob/master/XLS-0032-tx-request-uri/README.md) — XRPLF, 2022 [2] [0032 XLS-32d: Request URI Structure (discussion)](https://github.com/XRPLF/XRPL-Standards/discussions/81) — XRPLF, 2022 [3] [The new XRPL X-address format](https://xrpaddress.info/) — xrpaddress.info, 2026 [4] [0002 XLS-2d Standard for XRPL destination information](https://github.com/XRPLF/XRPL-Standards/discussions/27) — XRPLF, 2020 [5] [xrpl-tagged-address-codec](https://github.com/xrp-community/xrpl-tagged-address-codec) — GitHub, 2022 ## Deployments _No country reports mention this standard by name._ ## Regions / aggregations not mapped to a single country - Universal