update: Changes to the XLS-68 PR before merge by mvadari · Pull Request #564 · XRPLF/XRPL-Standards

mvadari · 2026-06-16T20:36:41Z

High Level Overview of Change

Title says it all

Context of Change

XRPLF/rippled#7350

Type of Change

XLS Update (changes to an existing XLS)

Copilot

Pull request overview

This PR updates XLS-0068 (Sponsored Fees and Reserves) to align the specification with ongoing implementation work (notably rippled PR #7350), adding clarifications for pseudo-accounts, reserve carve-outs, Batch transaction behavior, and feature interactions.

Changes:

Adds/clarifies sponsorship constraints around pseudo-accounts and pseudo-account–owned objects, plus reserve carve-out behavior.
Specifies sponsorship rules and failure conditions related to Batch (XLS-56) and permissioned delegation interactions.
Renumbers/extends later sections (Feature Interactions, Invariants, etc.) and updates various references (with some remaining inconsistencies).

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

… 68-updates

oleks-rip · 2026-07-21T17:23:37Z

+1. The sponsor's account does not have enough XRP to cover the sponsored transaction fee (`terINSUF_FEE_B`, or `tecINSUFF_FEE` if some — but not enough — XRP is available when the transaction is applied to a closed ledger)

-If a `Sponsorship` object exists:
+If a `Sponsorship` object exists, it is **always** used as the source of the sponsored fee — even if a valid `SponsorSignature` is also included. A co-signature does not bypass the object's budget or limits:


even if a valid SponsorSignature is also included -> even if a valid SponsorSignature or Delegate is also included

I think this remark about priority should be moved / duplicated to
3.2. The Sponsorship Flow (Not Pre-Funded) Or
3.3. The Sponsorship Flow (Pre-Funded)

And also + Delegate behavior

oleks-rip · 2026-07-21T17:27:17Z

-1. Paying fees via sponsorship will _not_ be able to [go below the reserve requirement](https://xrpl.org/docs/concepts/accounts/reserves#going-below-the-reserve-requirement).
-1. The fee in `tx.Fee` is greater than `Sponsorship.MaxFee`
+1. The `lsfSponsorshipRequireSignForFee` flag is enabled and there is no sponsor signature included (`terNO_PERMISSION`).
+2. There is not enough XRP in the `FeeAmount` to pay for the transaction (`terINSUF_FEE_B` / `tecINSUFF_FEE`). The transaction errors; it does **not** fall back to the sponsor's main `AccountRoot.Balance`, even if the sponsor co-signed the transaction.


Fallback + delegates should be mentioned in 3.2 (copy or move)

oleks-rip · 2026-07-21T17:34:56Z

+In all cases:
+
+1. If the resolved fee payer does not have sufficient XRP available, the transaction errors (`terINSUF_FEE_B` / `tecINSUFF_FEE`).
+2. Paying a transaction fee via sponsorship — whether pre-funded from the `Sponsorship.FeeAmount` or co-signed from the sponsor's `AccountRoot.Balance` — will _not_ be able to [go below the reserve requirement](https://xrpl.org/docs/concepts/accounts/reserves#going-below-the-reserve-requirement) (`terINSUF_FEE_B` / `tecINSUFF_FEE`). This is unlike an ordinary, non-sponsored fee, which may draw the paying account below its reserve.


I think this should be checked if it was implemented correctly in all places over the code.

oleks-rip · 2026-07-21T17:35:52Z

+1. The sponsor does not have enough XRP to cover the reserve (`tecINSUFFICIENT_RESERVE`).
+2. The transaction does not support reserve sponsorship — see [section 8.3.4](#834-transactions-that-cannot-be-sponsored) (`temMALFORMED`).
+3. The transaction creates a ledger object whose owner is an account other than `tx.Account` (e.g. `AMMClawback` creating a trust line on behalf of the holder) (`tecNO_SPONSOR_PERMISSION`).
+4. The transaction includes an `sfDelegate` field and `spfSponsorReserve` is enabled — reserve sponsorship combined with permissioned delegation is disallowed (`temINVALID`; see [section 18.1](#181-permissioned-delegation)).


copy this to 3.3. too

oleks-rip · 2026-07-21T17:40:29Z

+4. The transaction includes an `sfDelegate` field and `spfSponsorReserve` is enabled — reserve sponsorship combined with permissioned delegation is disallowed (`temINVALID`; see [section 18.1](#181-permissioned-delegation)).

-If a `Sponsorship` object exists:
+If a `Sponsorship` object exists, it is **always** used for the sponsored reserve — even if a valid `SponsorSignature` is also included. Every sponsored reserve is checked against, and consumed from, the object's remaining `ReserveCount`; a co-signature does not bypass the budget:


Should fee be paid for the signers if they are not used?

We shouldn't make the fee dependent on ledger state

oleks-rip · 2026-07-21T17:45:02Z

-11. `Owner == Sponsee` (attempting to create self-sponsorship) (`temMALFORMED`)
-12. `CounterpartySponsor` does not have sufficient XRP to cover the reserve for the `Sponsorship` object (`tecINSUFFICIENT_RESERVE`)
-13. If `tfDeleteObject` is enabled:
+7. `MaxFee` is not denominated in XRP (`temBAD_AMOUNT`)


why MaxFee is less than the base condition removed?

Felt like an unnecessary check to add, given that a MaxFee lower than the base fee could be used to prevent any fee-based signatures.

oleks-rip · 2026-07-21T17:53:10Z

+
+Sponsorship is a cross-cutting feature that touches almost every transaction type and interacts with several other XRPL features. This section is a catch-all for those interactions. The normative mechanics live in the per-feature sections above; this section consolidates the resolution rules so they can be reasoned about in one place.
+
+### 18.1. Permissioned Delegation


I think this should be move to 3.2/3.3 to have all behavior in one place

oleks-rip · 2026-07-21T17:58:54Z

 - **Pre-funded sponsorship** reduces operational overhead for sponsors who want to enable many transactions without being involved in each one, while still maintaining limits via `MaxFee` and `ReserveCount`.

-### 20.3. Other Designs Considered
+**Precedence: the `Sponsorship` object always governs.** If a `Sponsorship` object exists between the sponsor and sponsee, it is always the authoritative source for that sponsorship — its budgets (`FeeAmount`, `ReserveCount`) are the ones checked and consumed, and its limits (`MaxFee`) always apply, even when the sponsor also co-signs the transaction. A co-signature never bypasses the object or falls back to the sponsor's account balance. This keeps the accounting predictable: by creating the object, the sponsor has opted into explicit budgets, and those budgets are the single source of truth for what the sponsee may spend. A sponsor who wants to co-sign directly from their balance again can delete the `Sponsorship` object (or the relevant budget field) via `SponsorshipSet`.


22.2 - this explanation too - better to move to 3.2/3.3. To much nuances to look all over the document

mvadari added 3 commits June 15, 2026 18:03

[Claude] updates

68d840f

more updates

883a95c

clean up

98cbfea

Copilot AI review requested due to automatic review settings June 16, 2026 20:36

Copilot started reviewing on behalf of mvadari June 16, 2026 20:37 View session

Copilot AI reviewed Jun 16, 2026

View reviewed changes

mvadari and others added 5 commits June 16, 2026 16:42

add error codes

3246f79

fix section numbers

196bfb7

Potential fix for pull request finding

0aada05

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

Potential fix for pull request finding

e35488d

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

Potential fix for pull request finding

e90074f

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

yinyiqian1 reviewed Jul 9, 2026

View reviewed changes

Comment thread XLS-0068-sponsored-fees-and-reserves/README.md Outdated

mvadari added 3 commits July 10, 2026 14:42

update spec

e273e13

Merge branch 'master' of https://github.com/XRPLF/XRPL-Standards into…

d0dad14

… 68-updates

update spec

02bcc18

kuan121 mentioned this pull request Jul 12, 2026

Sponsorship xls 68 XRPLF/xrpl.js#3238

Open

9 tasks

mvadari and others added 2 commits July 17, 2026 14:17

Merge branch 'master' into 68-updates

554ce0f

fix ci

33708bf

yinyiqian1 reviewed Jul 17, 2026

View reviewed changes

Comment thread XLS-0068-sponsored-fees-and-reserves/README.md Outdated

oleks-rip reviewed Jul 21, 2026

View reviewed changes

mvadari added 3 commits July 21, 2026 15:35

more updates from the code

bf1cf30

more changes

7ba1e12

make spec internally consistent

3f94278

kuan121 mentioned this pull request Jul 24, 2026

Support XLS-68 Sponsored Fees and Reserves XRPLF/xrpl-py#1020

Open

3 tasks

more changes

2733d3a

sappenin mentioned this pull request Aug 5, 2026

Xls 68 sponsored fees reserves updated XRPLF/xrpl4j#720

Merged


		Sponsorship is a cross-cutting feature that touches almost every transaction type and interacts with several other XRPL features. This section is a catch-all for those interactions. The normative mechanics live in the per-feature sections above; this section consolidates the resolution rules so they can be reasoned about in one place.

		### 18.1. Permissioned Delegation

Uh oh!

Conversation

mvadari commented Jun 16, 2026

High Level Overview of Change

Context of Change

Type of Change

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants