Xls 68 sponsored fees reserves updated by cybele-ripple · Pull Request #720 · XRPLF/xrpl4j

cybele-ripple · 2026-04-09T02:17:42Z

This PR supports the new amendment for sponsored fees and reserves for the java library.

…ault

…rp/lending-protocol

codecov · 2026-04-09T22:14:35Z

Codecov Report

❌ Patch coverage is 97.19626% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 93.62%. Comparing base (6234b48) to head (631dfd4).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
...org/xrpl/xrpl4j/crypto/signing/SignatureUtils.java	88.88%	2 Missing ⚠️
...l4j/model/transactions/SponsorshipValidations.java	89.47%	1 Missing and 1 partial ⚠️
...g/xrpl/xrpl4j/model/flags/SponsorshipSetFlags.java	96.96%	0 Missing and 1 partial ⚠️
...pl/xrpl4j/model/transactions/SponsorSignature.java	95.83%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main     #720      +/-   ##
============================================
+ Coverage     93.50%   93.62%   +0.11%     
- Complexity     2606     2699      +93     
============================================
  Files           486      497      +11     
  Lines          6578     6790     +212     
  Branches        565      585      +20     
============================================
+ Hits           6151     6357     +206     
- Misses          270      274       +4     
- Partials        157      159       +2

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

cybele-ripple · 2026-04-09T22:44:40Z

/ai-review

xrplf-ai-reviewer

ℹ️ Note: This is a large diff (208,487 chars). Complex issues deep in the diff may receive less attention.

Missing cryptographic domain separation in sponsorSign — see inline comment.

Review by Claude Opus 4.6 · Prompt: V14

xrplf-ai-reviewer · 2026-04-10T21:10:08Z

+
+    // Sponsor single-signing uses the same signable bytes as regular single-signing.
+    // The sponsor signs the complete transaction binary (including the sponsee's SigningPubKey).
+    final UnsignedByteArray signableTransactionBytes = this.signatureUtils.toSignableBytes(transaction);


sponsorSign reuses regular signable bytes — no domain separation from the account-owner path. sponsorMultiSign correctly uses toSponsorMultiSignableBytes; the single-sign path should mirror this with a dedicated method and distinct prefix to prevent signatures being cross-applicable between roles.

Suggested change

final UnsignedByteArray signableTransactionBytes = this.signatureUtils.toSignableBytes(transaction);

final UnsignedByteArray signableTransactionBytes = this.signatureUtils.toSponsorSignableBytes(transaction);

I have changed toSignableBytes to toSponsorSignableBytes

Patel-Raj11 · 2026-04-10T21:01:06Z

+   */
+  @Beta
+  @JsonProperty("Sponsor")
+  Optional<Address> sponsor();


Even though other ledger objects are not listed here but some of them like MpTokenObject, MpTokenIssuanceObject etc do have reserve requirements. Should we add Sponsor field to such ledger objects as well?

I think we should not add Sponsor to other ledger objects. There is some ambiguity in "Allowed Ledger Entry Types" ("Any other ledger entry type that contributes to an account's owner reserve, subject to implementation details") and I want to ensure that any added ledger object are truly supported

Patel-Raj11 · 2026-04-10T21:19:33Z

+   */
+  @JsonProperty("Flags")
+  @Value.Default
+  default Flags flags() {


Should we create SponsorshipFlags?

Yes. Just added the file xrpl4j-core/src/main/java/org/xrpl/xrpl4j/model/flags/SponsorshipFlags.java which creates these sponsorship flags

Patel-Raj11 · 2026-04-10T21:22:39Z

+   *
+   * @return An {@link Optional} {@link UnsignedInteger} containing the sponsor flags.
+   */
+  @com.google.common.annotations.Beta


nit: Should we use just the class name instead of fully qualified name? This applied to other places in this PR.

Yes. Imported and used just the class name here and here in this file

Patel-Raj11 · 2026-04-10T21:28:28Z

+   */
+  @com.google.common.annotations.Beta
+  @JsonProperty("SponsorFlags")
+  Optional<UnsignedInteger> sponsorFlags();


Should we create SponsorFlags class that extends TransactionFlags?

Also, should we add the checks mentioned in the spec?

I agree we should create SponsorFlags to extend another class, but we should extend Flags instead of TransactionFlags since other flag types do this. I added SponsorFlags
I added validation checks for SponsorFields here

Should the return value use the flag type, like this?

Optional<SponsorFlags> sponsorFlags();

Patel-Raj11 · 2026-04-10T21:35:36Z

+   */
+  @JsonProperty("Flags")
+  @Value.Default
+  default TransactionFlags flags() {


Should we create SponsorshipSetFlags?

Created xrpl4j-core/src/main/java/org/xrpl/xrpl4j/model/flags/SponsorshipSetFlags.java and associated tests xrpl4j-core/src/test/java/org/xrpl/xrpl4j/model/flags/SponsorshipSetFlagsTest.java

Patel-Raj11 · 2026-04-10T21:52:05Z

+   *
+   * @throws JsonProcessingException if JSON is not valid.
+   */
+  public String encodeForMultiSigningWithSigningPubKey(


Changes in this file can be reverted.

This change has been removed from the PR. There are now no changes in xrpl4j-core/src/main/java/org/xrpl/xrpl4j/codec/

Patel-Raj11 · 2026-04-10T21:56:25Z

+ *
+ * @see "https://github.com/XRPLF/XRPL-Standards/blob/master/XLS-0068-sponsored-fees-and-reserves/README.md"
+ */
+@Disabled("SponsorshipTransfer requires featureSponsorship amendment which may not be enabled on test networks")


Can we remove Disabled and instead use this image - legleux/xrpld:sponsor so that CI can pass for SponsorshipTransferIT? We can make a note to review the image back to develop once this rippled changed is merged and we have Docker image from develop branch.

Added legleux/xrpld:sponsor to RippledContainer.java here

Patel-Raj11 · 2026-04-10T22:04:11Z

+   * Scenario: tfSponsorshipCreate - Creating a new sponsorship where sponsor uses multi-sig.
+   */
+  @Test
+  public void testSponsorshipTransferSingleSponseeMultiSponsor() throws JsonRpcClientErrorException,


Since we have not executed SignerListSet transaction to register signers for sponsor, I doubt this test would pass when run locally on standalone instance. Should we make sure to remove the Disabled and see if these tests run locally on standalone instance?

Removed the disabled line for these tests but they still failed with the legleux/xrpld:sponsor rippled image because the featureSponsorship amendment is not registered in Feature.cpp

The feature name is Sponsor. Can you give it a try?

Reviewing once the integration tests passes either locally or on the CI pipeline will avoid back and forth.

Patel-Raj11 · 2026-04-10T22:18:44Z

@@ -0,0 +1,492 @@
+package org.xrpl.xrpl4j.tests;


As per xrpl4j IT conventions we have one test file per amendment, we should merge these two IT files into one.

It would be good to add lifecycle tests that tries to exercise as many fields and flags of various transactions and ledger objects introduced in this PR. For example:

Tests for Fee sponsorship

Alice sponsors Bob to pay for transaction fees

Check ledger object that was modified/created and assert if Alice/Bob appears in it.

Bob submits a Payment transaction.

Assert that fees were paid by Alice and not Bob.

Bob transfers ownership to Charlie.

Assert that ledger objects involved are correctly reflected.

Test for Ledger object sponsorship

Similar idea as 2.1

Changes to integration tests have been added to a single file, SponsorshipIT.java.

I have added each of these test cases here.

Patel-Raj11 · 2026-04-10T22:20:42Z

+   * @return An {@link Optional} {@link List} of {@link Signer} objects.
+   */
+  @JsonProperty("Signers")
+  Optional<List<SignerWrapper>> signers();


The Singers needs to be sorted by AccountID in case of multi-signing. Batch and Lending Protocol have that sorting in-place which should be applied here as well.

Added sorting in this file here

if (!sortedSigners()) { return ImmutableSponsorSignature.builder() .from(this) .signers(signers().get().stream() .sorted(Comparator.comparing(wrapper -> new BigInteger( AddressCodec.getInstance().decodeAccountId(wrapper.signer().account()).hexValue(), 16 ))) .collect(Collectors.toList())) .sortedSigners(true) .build(); }

Patel-Raj11 · 2026-04-15T00:47:38Z

+@Value.Immutable
+@JsonSerialize(as = ImmutableSponsorshipSet.class)
+@JsonDeserialize(as = ImmutableSponsorshipSet.class)
+public interface SponsorshipSet extends Transaction {


temMALFORMED errors checks are yet to be added across various transactions modified in this PR.

https://github.com/mvadari/XRPL-Standards/blob/4c0b41935f70020c9e603c61fec4069aedfa36c0/XLS-0068-sponsored-fees-and-reserves/README.md#94-failure-conditions

…branch

…000/0x20000)

Swap the RippledContainer image from legleux/xrpld:sponsor (pulled from Docker Hub) to a locally-built xrpld:sponsor-local tag with PullPolicy.defaultPolicy(), so integration tests run against the locally-built rippled sponsor-branch image.

…sorshipIT Move the charlieAddress declaration in testSponsorshipTransferReassign from the top of the method to immediately before its first use in Step 3, satisfying the checkstyle VariableDeclarationUsageDistance rule (distance was 6, max allowed 3).

…sorshipIT Move the charlieKeyPair declaration in testSponsorshipTransferReassign from the top of the method to immediately before its first use in Step 3 (alongside charlieAddress), satisfying the checkstyle VariableDeclarationUsageDistance rule.

Restore the publicly-pullable legleux/xrpld:sponsor image and PullPolicy.alwaysPull() so integration tests run on GitHub Actions, which has no access to the locally-built xrpld:sponsor-local tag introduced in 2773b22.

@JsonProperty

Per XLS-0068, the Sponsorship ledger object carries a SponseeNode field (UInt64, nth=32). SponsorshipObject.java already serializes it via @JsonProperty("SponseeNode"), but the field was absent from definitions.json, so any binary-codec round-trip of a Sponsorship object emitted by rippled would fail to decode. Matches rippled source: sfields.macro line 155 TYPED_SFIELD(sfSponseeNode, UINT64, 32)

Merges main (Dynamic MPT XLS-94D, XLS-65 Vault, XLS-66 Lending Protocol, Issue polymorphism refactor, Q2 dep upgrades, bug fixes) while preserving XLS-68 sponsored fees changes (sponsorSign/sponsorMultiSign, SponsorshipObject, SponsorshipSet/Transfer, SponsorSignature, SponsorshipValidations). Resolved conflicts: - Vault/Loan/LoanBroker objects: took main's AssetAmount→Amount refactor - Transaction.java/TransactionType/LedgerObject: merged both sides' additions - AbstractTransactionSigner: removed duplicate counterpartySign methods, fixed signingHelper→signatureHelper, moved overloads adjacent for checkstyle - MetaMpTokenIssuanceObject: removed duplicate domainId() method - Deleted orphaned AssetAmountDeserializer/Serializer and AssetAmountTest - RippledContainer: kept legleux/xrpld:sponsor image for CI

+   *
+   * @see "https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0056-batch"
+   */
+  public boolean tfInnerBatchTxn() {


+   *
+   * @return {@code true} if {@code tfFullyCanonicalSig} is set, otherwise {@code false}.
+   */
+  public boolean tfFullyCanonicalSig() {


…y check Replaced explicit (Consumer<CreateContainerCmd>) cast with an inferred lambda so that the docker-java-api transitive dependency is no longer directly referenced in source, fixing the dependency:analyze-only failure.

…devnet/testnet - Add docker-java-api as explicit test dependency in integration-tests pom.xml to satisfy dependency:analyze-only (RippledContainer directly uses CreateContainerCmd bytecode regardless of the source-level cast) - Annotate SponsorshipIT with @DisabledIf to skip on devnet/testnet/clio environments where the featureSponsorship amendment is not yet enabled, matching the pattern used by BatchTransactionIT, LendingProtocolIT, SingleAssetVaultIT, and XChainIT

sappenin · 2026-06-16T23:17:02Z

+  @JsonProperty("SponsorSignature")
+  Optional<SponsorSignature> sponsorSignature();
+
+  // TODO: Add Granular Permission fields (SponsorFee, SponsorReserve) for sponsorship once #689 is merged.


TODO nees to be addressed.

sappenin · 2026-06-16T23:20:25Z

    Objects.requireNonNull(transaction);
+
+    // Validate sponsorship fields per XLS-0068
+    SponsorshipValidations.validateSponsorFields(transaction);


We shouldn't inject statically like this. If we have a dependency like SponsorshipValidations then we need to inject via the constructor. This will allow proper mocking for testing.

That said, I'm not convinced that this check should occur here in SignatureUtils. This function is merely serializing bytes. The correctness or non-correctness checks seem like they should be in the transaction itself, or possibly in the signing function itself (as opposed to here).

If we want to consider adding an @Check default function in Transaction.java that might be a good candidate. Transaction.java is not itself an immutable, but we do have some prior art here where we annotation transactionType() function with @Value.Default. The immutables codegen picks this up and applies it to all Transactions.

sappenin · 2026-06-16T23:35:45Z

+   * @return An {@link UnsignedByteArray}.
+   */
+  @Beta
+  public UnsignedByteArray toSponsorSignableBytes(final Transaction transaction) {


This method doesn't seem any different from toSignableBytes(final Transaction transaction). Is there any reason we have it like this (i.e., with a different name)?

sappenin · 2026-06-16T23:37:02Z

+    Objects.requireNonNull(privateKeyable);
+    Objects.requireNonNull(transaction);
+
+    final UnsignedByteArray signableTransactionBytes = this.signatureUtils.toSponsorSignableBytes(transaction);


I might be missing something, but if privateKeyable is the Sponsor's private key, then couldn't this function simply call this.signatureUtils.toSignableBytes(transaction) instead?

If that answer is "yes", then do we need sponsorSign at all?

I see that we need a special function for sponsorMultiSign, so even if this is a redudant function, I kind of like the API part of it. In that case, could this just be implemented like this?

@Override public <T extends Transaction> Signature sponsorSign(final P privateKeyable, final T transaction) { Objects.requireNonNull(privateKeyable); Objects.requireNonNull(transaction); return this.sign(privateKeyable, transaction).signature(); }

sappenin · 2026-06-16T23:40:00Z

  }

+  @Override
+  public <T extends Transaction> Signature sponsorSign(final P privateKeyable, final T transaction) {


Should this return a SingleSignedTransaction<T> instead of a `Signature?

I'm inclined to say "no" because sign that returns a SingleSignedTransaction<T> appears to be an anomaly rather than a pattern, but this is still probably worth discussing.

sappenin · 2026-06-16T23:42:44Z

+   * Its API is subject to change.</p>
+   */
+  @Beta
+  protected static final PaymentFlags SPONSOR_CREATED_ACCOUNT = new PaymentFlags(0x00080000L);


I don't see this change reflected in PaymentFlagsTests.

sappenin · 2026-06-16T23:47:57Z

+   */
+  @Beta
+  @JsonProperty("Sponsor")
+  Optional<Address> sponsor();


Let's be sure to update unit tests for this. In particular, we'll want to make sure serialization works with and without this field being present.

sappenin · 2026-06-16T23:48:03Z

+   */
+  @Beta
+  @JsonProperty("Sponsor")
+  Optional<Address> sponsor();


Let's be sure to update unit tests for this. In particular, we'll want to make sure serialization works with and without this field being present.

sappenin · 2026-06-16T23:48:13Z

+   */
+  @Beta
+  @JsonProperty("Sponsor")
+  Optional<Address> sponsor();


Let's be sure to update unit tests for this (e.g., EscrowObjectJsonTests). In particular, we'll want to make sure serialization works with and without this field being present.

We should do this for any ledger object that gets a sponsor.

sappenin · 2026-06-16T23:49:30Z

+   */
+  @Beta
+  @JsonProperty("LowSponsor")
+  Optional<Address> lowSponsor();


Let's be sure to update unit tests for this. In particular, we'll want to make sure serialization works with and without this field being present.

sappenin · 2026-06-16T23:52:39Z

+@Value.Immutable
+@JsonSerialize(as = ImmutableSponsorSignature.class)
+@JsonDeserialize(as = ImmutableSponsorSignature.class)
+public interface SponsorSignature {


I think this class needs to move to package org.xrpl.xrpl4j.crypto.signing;

Patel-Raj11 added 30 commits March 12, 2026 10:40

initial commit

10f0f48

add tests for IssueType

0778c7e

add NumberType tests

b352310

add tests

b356de7

add DomainID to permission domain

e5c7d5d

add fixtures

38de730

rename NumberAmount to AssetAmount

1735fbe

add IssueType tests

74866b0

import IT

e04b31d

add more tests

756f6b3

Merge branch 'main' of github.com:XRPLF/xrpl4j into rp/single-asset-v…

b9a4984

…ault

fix checkstyle warnings

623ac44

add transactions, ledger objects and tests

0a13d73

Merge branch 'main' of github.com:XRPLF/xrpl4j into rp/single-asset-v…

318e66c

…ault

address code review comments

5256ce8

add migration guide

95a0530

remove unnecessary checks

4d6b600

merge main

41d2a8e

small refactor

e7a4a7c

update migration guide

31ba40e

xrpl-ai suggestions

e2f2730

Merge branch 'rp/single-asset-vault' of github.com:XRPLF/xrpl4j into …

82bdeef

…rp/lending-protocol

add helper methods for counterparty signing

2793212

add sorting support for multi-sign in CounterpartySignature

9f42146

add tests for signing/multi-sign

f534f03

add isNegative and isZero on AssetAmount

d8f263b

add LoanBrokerSetTest

ca0c0db

add LoanBrokerDeleteTest

5d3e673

add computeLoanSetNetworkFees

2d58cf4

add LoanBrokerCoverDepositTest

a06aba6

cybele-ripple requested a review from Patel-Raj11 as a code owner April 9, 2026 02:17

resolve error related to merge

996cb5f

enhanced test coverage

30034c7

added test coverage

8019191

xrplf-ai-reviewer Bot reviewed Apr 10, 2026

View reviewed changes

Patel-Raj11 requested changes Apr 10, 2026

View reviewed changes

cybele-ripple added 5 commits April 13, 2026 20:55

addressed PR comments

a4eebe3

added validation checks

71fa82e

use xrpld:sponsor

0b4f73f

fix combatibility issues

fa76ae0

addressed PR comments

9de74aa

cybele-ripple requested a review from Patel-Raj11 April 14, 2026 23:46

Patel-Raj11 requested changes Apr 15, 2026

View reviewed changes

cybele-ripple added 8 commits April 17, 2026 17:39

test fix: Enable SponsorshipIT and align with rippled XLS-68 sponsor …

aefeb82

…branch

test fix: update SponsorshipFlagsTest to match lsf* flag values (0x10…

fb7afb5

…000/0x20000)

fix: restore legleux/xrpld:sponsor as RippledContainer image for CI

6a4f773

fix(test): revert RippledContainer to legleux/xrpld:sponsor for CI

cc47dd4

Restore the publicly-pullable legleux/xrpld:sponsor image and PullPolicy.alwaysPull() so integration tests run on GitHub Actions, which has no access to the locally-built xrpld:sponsor-local tag introduced in 2773b22.

Base automatically changed from rp/lending-protocol to main May 20, 2026 18:21

github-code-quality Bot found potential problems May 29, 2026

View reviewed changes

cybele-ripple added 2 commits June 1, 2026 13:45

sappenin reviewed Jun 16, 2026

View reviewed changes

sappenin requested changes Jun 16, 2026

View reviewed changes

	final UnsignedByteArray signableTransactionBytes = this.signatureUtils.toSignableBytes(transaction);
	final UnsignedByteArray signableTransactionBytes = this.signatureUtils.toSponsorSignableBytes(transaction);

Conversation

cybele-ripple commented Apr 9, 2026

Uh oh!

codecov Bot commented Apr 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

cybele-ripple commented Apr 9, 2026

Uh oh!

xrplf-ai-reviewer Bot left a comment

Choose a reason for hiding this comment

Uh oh!

xrplf-ai-reviewer Bot Apr 10, 2026

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!

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!

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!

Choose a reason for hiding this comment

codecov Bot commented Apr 9, 2026 •

edited

Loading