XRP Ledger Developers Propose Zero-XRP Wallets to Cut the 1 XRP Reserve Cost
A new account on the XRP Ledger could soon open with nothing in it, removing a fixed entry cost that every user currently pays in XRP.
AI SummaryAI
- XRP Ledger developers filed the SponsoredAccountCreate proposal on Oct. 15 in the rippled repository.
- XRP Ledger requires each account to hold a locked 1 XRP reserve.
- The proposal lets a sponsoring account create a new wallet with zero XRP.
- A company provisioning 100,000 accounts currently locks 100,000 XRP in reserves.
SponsoredAccountCreate Targets the 1 XRP Reserve
A new account on the
XRP Ledger could soon open with nothing in it, removing a fixed entry cost that every user currently pays in XRP. The work targets the ledger's account rules rather than the XRP price, and it took the form of a code proposal submitted on Oct. 15 in the rippled repository that hosts the network's core server software. The change adds a transaction named SponsoredAccountCreate, which lets an existing account create a new crypto wallet and pay the new account's reserve requirement on its behalf.
The reserve sits at the center of the design. Each XRP Ledger account must hold at least 1 XRP, and that amount stays locked for as long as the account remains active. The rule exists to keep the network from being flooded with empty wallets, but it also fixes a floor under the cost of onboarding. A company provisioning 100,000 customer accounts would have to park 100,000
XRP against those reserves alone, capital that sits idle instead of moving through payment flows.
Under the proposed transaction, that cost moves rather than disappears. The sponsoring account carries the reserve, the customer's wallet can start with a zero XRP balance, and the network's overall reserve obligation stays intact. Sponsors could also cover transaction fees on a user's behalf through the broader Sponsored Fees and Reserves standard the proposal builds on. That standard already lets one account pay another account's network costs without taking control of its private keys, so the sponsor never gains custody of user funds. The new code goes a step further than fee sponsorship: instead of funding a wallet with XRP and letting the user manage it, the sponsor creates the account directly with nothing in it. For automated software that provisions accounts at scale, the difference between 100,000 locked XRP and zero locked XRP is the difference between a funding line item and a non-issue.
Privy Integration and the 29-Vote Hurdle
The proposal lands where an integration already exists. Ripple recently partnered with Privy, the embedded-wallet provider owned by Stripe, to bring in-app wallets to
XRP Ledger applications. Those wallets, in practice a form of hot wallet that the application holds for the user, are designed to support payments in XRP and in Ripple's RLUSD stablecoin, the asset that received an A2 rating from Moody's across the XRP Ledger and Ethereum. They currently need XRP funding before they can activate, even when they exist only to hold a stablecoin. Sponsorship, in this design, replaces the user's upfront XRP purchase with a service relationship between application and sponsor. The same friction applies to automated payments made by software agents, the core AI crypto wallet scenario that Ripple and Privy cited when they announced the integration.
The code itself is not ready for the network. The pull request stays open, with two findings from automated code review still unresolved, and it builds on sponsorship changes that have yet to activate on mainnet. Those changes sit with validators. The sponsorship amendment had drawn 11 of the 29 votes it needs from the network's trusted validators as of Oct. 19, out of a trusted set of 35, well short of the approval threshold. The amendment math explains the gap: XRPL amendments activate only when a supermajority of the trusted validator set votes for them and holds that vote through the activation window, so 29 of 35 is the bar the sponsorship changes must clear and sustain. For node operators, the practical step is running a rippled release that carries the new transaction type and the sponsorship logic it depends on, then signaling support. Until that happens, applications built on the Privy integration keep paying the 1 XRP entry cost that SponsoredAccountCreate is written to remove.
The Sponsor Carries the Locked XRP
If the sponsorship amendment clears the 29-vote bar, the practical effect is that a stablecoin user never has to acquire XRP at all. That reshapes where demand for the asset sits: instead of 100,000 customers each locking 1 XRP, a single sponsor locks 100,000 XRP, concentrating the token's role as network collateral in a handful of payment companies. For an altcoin that markets itself on settlement utility, the PayFi build-out depends more on sponsor economics than on retail acquisition, and SponsoredAccountCreate is written for exactly that model. The amendment's tally of 11 votes as of Oct. 19 gives the current answer to the timing question: the shift has not arrived yet.
Primary sources
- a code proposal submitted on Oct. 15 · github.com
AI-generated, AI-reviewed, under COINOTAG editorial oversight.

