Mentioned in This Article
1. What the XRP Ledger zero-XRP wallets proposal does
Developers working on the XRP Ledger (XRPL) are testing a mechanism that would let new accounts exist with a balance of zero XRP, a change aimed at payment applications and automated software that would otherwise have to deposit XRP into every wallet before using it. The code was submitted on October 15 as pull request number 8606 in the XRPLF rippled repository, the reference software that runs the network, and it introduces a transaction type called SponsoredAccountCreate.
In practical terms, the new transaction allows an account that already exists to create a second account and pay for that account's reserve out of its own funds. The wallet that results can sit at zero XRP while still being recognized by the ledger. The proposal is experimental, the pull request is still open, and none of the behavior it describes is active on the main network.
2. Why the ledger asks every account to lock up XRP
The XRP Ledger currently requires each account to keep a minimum reserve of 1 XRP, and that amount stays locked for as long as the account is active. The rule exists as a defense against clutter: if opening an account cost nothing, anyone could generate enormous numbers of empty wallets and force every server on the network to store them. Tying up a small amount of XRP per account gives each entry a price and keeps the shared ledger from bloating.
That design works well enough for individuals who already hold XRP, but it becomes awkward when an application wants to create wallets in bulk for customers who have no intention of owning the token. The reserve is a requirement of the network rather than a fee that is spent, yet it still has to be funded up front, which means someone must acquire XRP before a user can do anything else.
3. How large the reserve burden becomes at scale
The scale of the issue is easy to see with a simple example. A company that opens 100,000 separate customer accounts would need to set aside 100,000 XRP just to satisfy the reserve requirements. For a payments business, that is capital sitting idle, exposed to the price swings of the token, and unrelated to the service being sold.
The same arithmetic applies to software agents. Automated programs that make payments on behalf of people or businesses may each need their own account, and multiplying the reserve across a large fleet of agents quickly becomes a meaningful balance-sheet item. Removing the need to fund every wallet individually is the central problem the proposal tries to solve.
Reserve rules shape the economics of any business built on a public ledger. A payments company weighs the cost of acquiring each customer against the revenue that customer generates, and a fixed deposit per wallet adds a line to that calculation before a single transaction has taken place. When the deposit is denominated in a volatile asset, the company also takes on market exposure it did not seek, since the value of the locked tokens can rise or fall while the customer account stays dormant.
For that reason, developers on several networks have looked for ways to separate the act of using a chain from the act of owning its token. Sponsorship is one of the more direct answers: the party with a commercial reason to onboard users pays the network's protective cost, and the user sees only the service. The XRP Ledger proposal follows that logic while keeping the reserve itself intact, which preserves the protection against spam that the rule was written to provide.
4. How would a sponsor cover the reserve?
Under the proposal, a sponsoring account pays the reserve on behalf of the account it creates, and the new wallet is allowed to keep a zero XRP balance. The total reserve obligation across the network does not shrink, because the locked amount still exists. What changes is who bears it: the sponsor, typically a company running an application, carries the cost rather than the end customer.
Sponsors could also cover transaction fees through a broader sponsorship mechanism, so that applications could absorb the small charges their users would otherwise pay in XRP. Taken together, the two pieces would let a person open a wallet, receive a dollar-denominated token, and move it without ever buying the network's native asset.
5. Where stablecoin payments and AI agents fit in
A stablecoin is a token designed to hold a steady value, usually one US dollar, and it has become one of the most widely used tools in crypto payments. Payment firms like it because customers can think in familiar currency units, but on many networks they must still hold the chain's native token to pay fees or meet account requirements. The zero-XRP design is meant to remove that friction on the XRP Ledger.
The timing connects to recent product work. Ripple recently partnered with Privy, a company owned by Stripe, to bring embedded wallets to applications built on the XRP Ledger. The integration supports payments in XRP and in Ripple's RLUSD stablecoin, including payments initiated by AI agents. Those wallets currently need to be funded with XRP before they become active, even when the wallet is only intended to hold a stablecoin, and that is the gap the sponsored-account transaction would close.
6. What changes for ordinary users
For a person using an application built on the ledger, the visible effect would be a shorter path to a working wallet. Today, a newcomer who wants to hold a dollar-denominated token on the network must first find a way to buy XRP, transfer it to the new address, and only then add the stablecoin. Each of those steps is a point at which users abandon the process, and each requires knowledge that has little to do with the payment they actually want to make.
With a sponsor in place, the application could create the account on the user's behalf, leave it at zero XRP, and let the user receive stablecoins immediately. The user would still control the private keys, because the sponsorship standard is built so that paying costs does not confer authority over the account. The experience would resemble signing up for a conventional payment app, with the ledger operating in the background.
7. Risks and trade-offs of sponsored accounts
Shifting the reserve to a sponsor introduces its own considerations. A sponsor that opens many accounts commits its capital for as long as those accounts remain active, so a company would need to manage how many wallets it supports and what happens when customers stop using them. Because the total reserve obligation across the network stays the same, the proposal does not reduce the ledger's storage burden; it only moves the financial responsibility.
Reviewers will also look closely at how the transaction could be abused. Any feature that makes account creation cheaper for the user invites questions about whether it could be used to flood the ledger with accounts at the sponsor's expense. The unresolved findings from automated code review, along with human feedback on the pull request, are part of how the community tests those questions before an amendment is put to validators.
8. How the new transaction builds on the sponsorship standard
The proposed transaction extends a standard known as Sponsored Fees and Reserves. That standard lets one account pay network costs for another without gaining any control over the second account's private keys. The distinction matters for security and for trust: a company can subsidize its users while the users keep sole authority over their own funds.
What the new code adds is the ability to create the account directly, without first sending it any XRP. Under the existing approach, an account has to be activated by a payment of at least the reserve amount before the sponsorship features can help. The proposed transaction collapses that step, so the wallet can be born already covered.
9. What still stands in the way
The pull request carries two unresolved findings from automated code review, and it depends on sponsorship changes that have not yet activated on the main network. Open review items are a normal part of development on an open-source ledger, but they signal that the design and its implementation are not final.
The larger obstacle is the underlying sponsorship amendment, which still needs validator approval. On the XRP Ledger, protocol changes are introduced as amendments, and they activate only after a supermajority of trusted validators vote in favor and maintain that support for a set period. As of October 19, according to XRPL Dashboard, the sponsorship amendment had received 11 votes, well short of the number it needs to pass. Until that threshold is reached, the sponsored account creation transaction cannot be used on the live ledger.
10. What to watch next
The next markers are the resolution of the open review findings on the pull request and any movement in validator votes for the sponsorship amendment. No activation date has been set, and the experimental status of the code means the design could still change before it reaches the main network.
If the amendment advances and the transaction is adopted, payment companies and wallet providers building on the XRP Ledger would be able to onboard stablecoin users without pre-funding each account. If support stalls, applications will continue to rely on funding every wallet with XRP, with the capital cost that implies. Either way, the proposal shows how developers are reworking basic account rules to suit stablecoin payments and software agents, which are likely to create far more wallets than individuals ever did.