Vulnerability Disclosure Report: XLS-68 Sponsored Fees and Reserves

Date Reported: August 07, 2026

Affected Version(s): xrpld 3.3.0 (Sponsor amendment, not yet activated on Mainnet)

During Devnet testing of the XLS-68 Sponsored Fees and Reserves amendment, a reserve-accounting vulnerability was identified in the sponsorship lifecycle. The implementation allows a sponsor to end an object-level sponsorship without verifying that the object's owner can cover the reserve, enabling a state-growth exploit where unbacked ledger objects can be created at minimal cost.

Sponsored Fees and Reserves (XLS-68) lets one XRPL account cover another's network fees and reserves, so end users can transact without holding XRP. Sponsors can either pre-fund a budget via an on-ledger Sponsorship object or co-sign each transaction individually. This is foundational for institutional adoption, as regulated entities often can't hold crypto directly.

The Sponsor amendment has not been activated on Mainnet. No funds were at risk.

No loss of funds, private key compromise, or consensus failure occurred. The amendment was in development and had not been activated on any production network. The vulnerability affects reserve accounting in the sponsorship lifecycle and, if left unpatched, would have introduced a state-growth vector once the amendment activated.

Kris Dangerfield and Andrew Spencer disclosed the finding during Devnet testing and reported it through a formal vulnerability disclosure, accompanied by reproduction scripts and Devnet transaction hashes.

The finding traces back to a fundamental design tension in reserve sponsorship, which we refer to as the “Reserve Exit Trilemma”. Three properties are desirable:

1. Either party can exit the sponsorship at any time.
2. Every ledger object's reserve is always backed by someone.
3. Sponsees can operate with zero XRP.

You cannot have all three simultaneously.

If the sponsor can exit freely and the sponsee holds zero XRP, there is a moment where the object exists on the ledger with no reserve backing it. The implementation did not enforce a reserve check on exit, allowing this gap to be exploited.

When a sponsor ends reserve sponsorship on a specific ledger object (a trust line, an MPT holder slot, an offer, etc.), the implementation does not verify that the object's owner can cover the reserve. The reserve obligation is simply removed, leaving the object on the ledger with no one backing its reserve.

This is exploitable: an attacker can sponsor the creation of multiple objects for a sponsee, then end sponsorship on each object. Because the reserves are returned to the sponsor upon ending, the same capital can be recycled to create more unbacked objects. In testing, 30 permanent unbacked ledger objects were created using recycled capital at a cost of approximately 20 drops each. This is a state-growth vector; the attacker can inflate the ledger cheaply with objects that persist indefinitely and that no one is paying reserves on.

The engineering team adopted the approach where the sponsor accepts a conditional lock-in, by not being able to unilaterally end reserve sponsorship. Exit requires one of three conditions:

1. The sponsee self-funds the reserve from their own XRP balance,
2. Another sponsor assumes the obligation via SponsorshipTransfer, or
3. The sponsored object or account is deleted.

As a consequence of this fix, a sponsor can no longer end account-level sponsorship when the sponsee holds a residual XRP balance below the base reserve ("dust"). This is expected behavior under the new model: reserve sponsorship can only be ended when the sponsee can fully cover the reserve, not partially.

This decision was not made in isolation. We evaluated the impact of the proposed changes on active pilots together with early customers and design partners to ensure the conditional exit model is workable for real deployment scenarios. We studied how other networks handle the same problem and found direct precedent: Stellar's CAP-33 (sponsored reserves) implements an equivalent constraint, where a sponsor cannot revoke sponsorship unless the sponsee can cover the reserve or the entry is removed. We also discussed the fix directly with the bug reporters, as well as members of the XRPL Foundation, to confirm the approach addresses the finding at the root-cause level.

In the short-to-medium term, this is the only feasible resolution of the trilemma that preserves the guarantee that every ledger object is always reserve-backed.

Exploring longer-term mechanisms that could relax the conditional lock-in without reintroducing the state-growth vector, such as protocol-level grace periods, on-ledger reserve insurance pools, or automated sponsorship transfer markets. These are not committed to a timeline and would require their own specification process.

The fix to enforce conditional exit on reserve sponsorship is included in xrpld v3.4.0, released on September 17, 2026.

The Sponsor amendment will not be activated on Mainnet until the fix is included.

We'd like to thank the following for identifying and helping resolve this finding:

• Denis Angell (XRPL Foundation)
• Kris Dangerfield
• Andrew Spencer

• XLS-68 Sponsored Fees and Reserves Spec
• Fix PR: rippled#8044
• Ctrl Alt: Sponsored Fees and Reserves

To report security issues, see the xrpld Security Policy.