Privy's Embedded Wallets Support the XRP Ledger, With Spending Rules

An app can give its users an XRP Ledger wallet without sending them off to install one. Privy's developer documentation lists embedded XRPL wallets, meaning wallets that live inside the app itself. A developer creates one with the xrpl chain type, and the user gets a standard r-prefix address, the same format every XRPL account uses.

The most telling design choice is what Privy doesn't do. It signs XRPL transactions, but it leaves sending them to the app.

Privy Signs XRPL Transactions but Doesn't Send Them

Privy sorts the chains it supports into tiers on its chains page. XRPL sits in Tier 2, labelled "Sign transactions" and described as "XRP Ledger transactions with policy controls."

At that level, Privy can create and export wallets, sign hashes and messages, and sign transactions. It can't send transactions. That's Tier 3, which currently covers Ethereum, Solana, Tempo and Tron.

The signing isn't blind, either. Privy's docs describe it as transaction-aware:

"Privy decodes and validates the transaction before signing."

Here's how that looks for a developer. You pass any XRPL transaction to xrpl_signTransaction. Privy hands back a DER-encoded signature and a ready-to-submit transaction blob. Picture a signed cheque returned to the app: it's valid, but somebody still has to deliver it. On XRPL, that somebody is the app, which submits the blob to the ledger itself. So XRPL builders get Privy's wallet creation and signing, but not the full send-it-for-you treatment Ethereum and Solana apps get.

Spending Rules Sit Inside the Wallet

The "policy controls" in that Tier 2 description do real work. Privy's policy engine can constrain XRPL wallets in three ways: restrict which addresses they pay, cap amounts, and limit which transaction types they're allowed to sign.

Two controls are specific to how XRPL handles tokens. Policies can cap the value of IOU payments, XRPL's term for payments in tokens issued by a company rather than in XRP itself. They can also restrict trust line creation through the TrustSet.LimitAmount field. Trust lines are how issued tokens, such as Ripple's RLUSD stablecoin, are held on XRPL.

That combination is the kind of guardrail an automated payment setup needs, whether it's a bot or an AI agent spending on someone's behalf. A wallet that can only pay approved addresses, only up to a set amount, is easier to hand to software. To be clear, the docs don't name RLUSD or agent payments. They describe the controls, and the use cases are ours to infer.

A Wallet That Needs 1 XRP to Exist

There's a catch every XRPL developer will recognise. A new XRPL wallet doesn't exist on-ledger until it receives the base reserve, which Privy's docs put at 1 XRP for now. Until then, the user has an address but no ledger account behind it.

Privy doesn't cover that cost. Apps must fund the wallets themselves, so an app planning to onboard lots of users needs to budget 1 XRP per wallet before anyone makes a single payment.

Users aren't locked in. Privy lets them export either the hex private key or a BIP-39 seed phrase, which the docs pitch as "full portability." Your wallet can leave the app with you.

What the Documentation Doesn't Say

Neither docs page mentions Ripple or any partnership, and neither says when XRPL support first went live. Both pages show a last-modified date of 12 October 2026.

What the pages do show is a practical toolkit with a clear boundary. XRPL apps can create wallets, sign any transaction under strict spending rules, and let users take their keys elsewhere. Submitting transactions and funding that first 1 XRP stay on the developer's side of the line.