A customer wants to receive a token. Your application asks them to acquire XRP before they can finish onboarding. That extra step can overwhelm an otherwise straightforward product journey.
Sponsored Fees and Reserves, specified in XLS-68, addresses this problem by allowing one XRP Ledger account to cover another account's fees and reserve obligations. The customer retains control of their account keys. For an enterprise application, that creates an appealing division of responsibilities: users authorize their activity, while the business pays selected infrastructure costs. XRPL sponsorship overview
The architectural challenge appears when the relationship ends. A fee is consumed. A reserve obligation can remain for as long as its underlying ledger state exists. A good onboarding experience therefore needs a treasury policy and an exit process from the start.
Research snapshot: October 17, 2026. Our read-only Mainnet query returned validated ledger 107723505, hash E0B8A1BD6377AC2E1CEC9D26440A6633AEF5243FEDCF6C6E42309520C2486B21. Neither Sponsor nor fixCleanup3_4_0 appeared in its enabled amendment list. The design below is preparation for a capability that was not enabled in that observed ledger. It is not an announcement of Mainnet availability. The downloadable package preserves the raw response and observation time.
Why this is a useful XRPL topic now
For teams building business software, several XRPL developments deserve attention:
- Tokenization infrastructure: Multi-Purpose Tokens provide a native token building block, while confidential transfers introduce a separate privacy capability with its own amendment requirements. Documentation or SDK support alone does not establish availability on a particular network. MPT documentation, confidential transfers
- Vaults and lending: the September 2026
xrpld3.4.0 release introducedLendingProtocolV1_1, extending the design with closed-ended vaults and cash-basis accounting. This is a server-release fact; activation must be checked separately. Release notes - Protocol security and deployment discipline: the latest item on the official community blog at research time was the October 9 disclosure covering Batch wrapper validation and XRP arithmetic issues fixed in 3.4.1. These are separate from the sponsorship issue discussed below. October disclosure, 3.4.1 release
- Sponsored onboarding: XLS-68 directly connects user experience, application authorization, and the cost of persistent ledger state. Its September security disclosure makes the lifecycle implications unusually concrete. XLS-68
Sponsored onboarding is our editorial choice for this article because it creates actionable architecture work before activation. It also extends Homann Software's existing XRPL coverage without repeating payment-settlement or Batch-completion guidance.
Two costs, two different lifecycles
Think of a sponsor service as managing two distinct resources.
The fee budget funds transactions. Product policy can set a maximum fee for one operation and a cumulative allowance for a customer or campaign. A small per-transaction limit alone cannot prevent a large number of transactions from consuming the overall budget.
Reserve capacity backs persistent accounts or objects. XRPL uses reserves to constrain ledger growth; requirements include a base reserve and increments associated with owned objects. Values can change through fee voting, and individual ledger object types have exceptions. Production software should obtain current reserve parameters and inspect the actual objects involved. The arithmetic later in this article assumes normalized reserve counts, after those object-specific rules have been applied. Reserve documentation
Figure 1. A sponsor's fee allowance and reserve commitments need separate limits, metrics, and reconciliation. Illustration of application accounting, not an XRPL balance sheet.
Suppose an internal pilot uses a base-reserve assumption of 1,000,000 drops and an owner-reserve increment of 200,000 drops. Sponsoring 10,000 new accounts with one additional reserve unit each would require 12,000,000,000 drops, or 12,000 XRP, before existing obligations, pending work, transaction fees, and operating headroom. These are planning assumptions for the example, not a live quote of protocol parameters or a forecast of customer demand.
An application may offer a customer a free service while deliberately accepting this cost. The important part is to make the commitment visible to the people responsible for funding it.
What the sponsorship disclosure teaches
The September 21 disclosure described a reserve-accounting defect found during Devnet testing of the Sponsor amendment. Ending object sponsorship could leave persistent state without adequate reserve backing. The report states that the feature had not been activated on Mainnet and no funds were at risk in that incident.
Its central design issue is the tension between unconditional sponsor exit, continuously backed ledger state, and a customer holding no XRP. The remediation uses conditional exit: the owner funds the obligation, another sponsor takes it over, or the relevant state is deleted. Official vulnerability report
For application design, the consequence is straightforward: a cancelled customer subscription does not prove that a reserve commitment has ended. A deletion request, a proposed replacement sponsor, and a submitted transaction are intermediate states. Treasury capacity should be released only after the expected change is confirmed in validated ledger evidence.
The current sponsorship documentation explicitly ties the object-exit reserve check to fixCleanup3_4_0. Our sample consequently requires both the feature and that fix as a conservative application gate. This is our product policy, not a claim that these two IDs alone establish complete production readiness. Sponsorship exit conditions
Choose the authorization model deliberately
XLS-68 supports co-signing individual transactions and setting up a pre-funded sponsorship relationship. In a co-signed flow, the sponsor can review each transaction before signing. In a pre-funded flow, the relationship records the permitted allowance and restrictions. Specification
The Sponsorship object distinguishes fee funds, remaining owner-reserve units, a maximum fee, and flags that can require sponsor signatures. These fields give applications protocol controls to combine with their own customer and campaign policies. Sponsorship ledger entry
For a first integration, we would start with a narrowly scoped, co-signed flow. That is an architectural recommendation, not a requirement of XRPL. It makes it easier to restrict transaction types and understand which operations create persistent obligations. The official tutorial provides the protocol-specific construction and signing steps. Co-signing tutorial
Pre-funding can reduce sponsor involvement in individual operations, but shifts more authority into the relationship's settings. The documented deltas for fee and reserve allowances are additive. Retrying an uncertain top-up as though it were an idempotent assignment can therefore be a costly application mistake. Persist the intended operation, track its transaction identity, and reconcile its result before deciding whether another top-up is needed. SponsorshipSet reference
Keep customer intent, signing, and treasury accounting separate
Consider a token issuer onboarding customers. We would assign four responsibilities:
- The onboarding application decides which customer journey is eligible and records the customer's intent.
- The sponsorship policy checks the permitted operation, fee ceiling, cumulative budget, and additional reserve exposure.
- The signing boundary verifies the complete transaction against the approved intent and signs the exact protocol payload.
- The ledger adapter and reconciler submit approved work, resolve uncertain outcomes, and update obligations from validated evidence.
Figure 2. Proposed UML sequence. The atomic budget hold, signer, transaction construction, and reconciler are production responsibilities; the downloadable sample implements only the pure planning decisions.
Do not let a positive budget calculation directly trigger a signature. Between checking capacity and submitting a transaction, other requests may consume that capacity. A production service needs an atomic hold against both fee budget and reserve headroom, keyed by an immutable operation ID and linked to the exact approved transaction intent. Multiple service instances need the same serialization boundary.
An HTTP timeout also leaves an unresolved operation, not permission to release its hold. Reconciliation must establish what happened before retrying or reclaiming capacity. This connects to the evidence discipline in our XRPL Batch article.
A small, tested policy core
The accompanying Python example uses integer drops and contains no wallet keys, signing code, or transaction submission. It separates protocol observation from application accounting so that the critical decisions can be inspected and tested locally.
This is the complete admission function from sponsor_policy.py:
def admit(fee: int, max_fee: int, fee_budget: int,
reserve_capacity: int, new_accounts: int,
new_owner_units: int, base: int, increment: int) -> Admission:
"""Capacity is already net of existing obligations and pending holds."""
for value in (fee, max_fee, fee_budget, reserve_capacity, new_accounts,
new_owner_units, base, increment):
natural(value)
cost = new_accounts * base + new_owner_units * increment
return Admission(
fee <= max_fee and fee <= fee_budget and cost <= reserve_capacity,
fee_budget - fee,
reserve_capacity - cost,
)
Admission is an immutable result containing allowed, fee_headroom, and reserve_headroom. The natural helper rejects negative numbers, floats, strings, and booleans. Rejecting booleans matters in Python because bool is a subclass of int.
For a normalized request to sponsor one account and two owner-reserve units, a reserve capacity of 1,400,000 drops exactly covers the assumed requirement. One drop less causes rejection:
from sponsor_policy import admit, exit_plan
decision = admit(
fee=12, max_fee=20, fee_budget=100,
reserve_capacity=1_400_000,
new_accounts=1, new_owner_units=2,
base=1_000_000, increment=200_000,
)
assert decision.allowed
assert decision.reserve_headroom == 0
assert exit_plan(0, 1_200_000) == "KEEP_OBLIGATION"
The fee of 12 drops is a synthetic test input, not a fee recommendation. The function's inputs are internal normalized values, not XRPL transaction JSON. reserve_capacity must already exclude the sponsor's existing reserve needs, committed obligations, and pending holds. The pure function does not reserve funds, prevent concurrent oversubscription, or handle object-specific reserve exceptions.
The module also calculates the documented reserve formula from normalized counts and provides an advisory exit decision. SELF_FUNDING_CANDIDATE means a balance supplied by the caller meets a supplied post-exit requirement; it does not mean a transaction has succeeded. The caller must supply trustworthy, current evidence and account for relevant fee effects.
Check the actual network capability
Our read-only observer requests the amendment object from a validated ledger:
{
"method": "ledger_entry",
"params": [
{"amendments": true, "ledger_index": "validated"}
]
}
The parser requires a validated response, a positive ledger index, the expected ledger-entry type, and both amendment IDs in Amendments. Entries in Majorities are not accepted as activation. The ledger-entry documentation explains the request; the Amendments object reference distinguishes enabled amendments from majority records. ledger_entry API, Amendments object
This check is intentionally conservative. It does not authenticate a network cryptographically, validate a server binary, or implement a freshness policy. A production adapter must bind its endpoint to the intended network, reject stale or inconsistent evidence, and decide what independent observations it requires. The saved Mainnet response is a dated observation, not a permanent feature flag.
The known-amendments catalog supplies the IDs. Its dynamically loaded status text was not usable as activation evidence in our text retrieval, which is why we performed the direct query.
Make the exit process part of the product
A customer-facing cancellation flow should tell the truth about pending ledger work. Internally, maintain the distinction between stopping new sponsorship and closing obligations that already exist.
Figure 3. Proposed BPMN 2.0 exit process. The package contains editable XML with diagram layout. This is a design model, not an executable workflow or adopted company policy.
The process starts by reviewing current ledger state and available exit routes. If there is no feasible route, record the continuing obligation and route it to operations. Where a route is feasible, obtain the necessary authorization, construct the relevant transaction, and reconcile its outcome. Only confirmed evidence closes the local commitment.
The protocol reference defines which party can create, reassign, or end reserve sponsorship, including when another sponsor must consent. The process model deliberately leaves those transaction-specific authorization checks inside the preparation task. It does not imply that the existing sponsor can unilaterally select a replacement. SponsorshipTransfer reference
Deleting a pre-funded arrangement is also distinct from ending reserve sponsorship of existing objects. Treat these as separate operations in your domain model and user interface. SponsorshipSet semantics
What we tested—and what remains integration work
Using Python 3.13.14, the local suite passed 35 tests. It exercises amendment gating, malformed observations, integer validation, reserve counts, exact budget boundaries, large integer arithmetic, and underfunded exit decisions. A parameterized monotonicity check covers 101 owner-count values inside one of those tests.
Three deliberately weakened versions were rejected by the same suite: ignoring the cleanup amendment, ignoring reserve capacity, and accepting an underfunded exit. These are targeted mutation checks, not an exhaustive mutation score.
The package also includes the executed inline example and the read-only network observer. No transactions were signed or submitted. We did not reproduce the vulnerability, run an XRPL node, or validate sponsorship end to end on Devnet. Before production, separately test protocol construction, signatures, authorization, reserve exceptions, concurrent budget holds, idempotent reconciliation, fee-paying failures, and recovery from uncertain submission results on a suitable test environment.
Run the local checks from the extracted examples directory:
python -m unittest -v
python inline_demo.py
python mutation_check.py
The optional python observe_amendments.py command performs a public, read-only network request. Its result changes over time; it is not part of the deterministic unit suite.
Download the tested examples and instructions or the editable UML and BPMN models. The complete editorial package also contains the saved network observations and verification results.
Build the lifecycle before removing the onboarding step
Sponsored onboarding is valuable when the business can explain which activities it funds, how much persistent state it backs, and how those commitments end. A practical pilot should have a narrow transaction allowlist, explicit fee and reserve limits, a separately controlled signer, atomic budget holds, and a reconciler that keeps unresolved work visible.
That preparation pays off even before activation. It turns a promising protocol capability into a product decision with named owners and testable rules. The customer can have a simpler journey because the application takes responsibility for the complexity behind it.