XRPL Permission Delegation Fix Targets Permissions That Survive Account Deletion

What the XRPL permission-revocation fix changes

XRPL Permission Delegation V1.1 includes a fix for permissions that could survive a delegate account’s deletion and recreation. Cantina marks the flaw fixed, and XRPLF’s code change cleans the permission record from both accounts. Current mainnet checks still show the amendment disabled, so custody teams should separate software assurance from operational availability.

CryptoPotato’s September 10 report brings renewed attention to the rebuilt feature. The useful development for readers is the public chain of evidence: an external finding, a specific cleanup change and a later QA report. Those records let an issuer or custody provider ask a concrete question: can it reliably withdraw a service account’s authority after that account changes state?

Confirmed chronology: RippleX Developers published its expanded QA report on August 26, 2026. XRPLF’s August 6 release notes already included PermissionDelegationV1_1. This article examines the revocation control behind that release, rather than treating September’s coverage as the date a new patch shipped. It does not report a demonstrated mainnet loss from this finding.

Section sources[1][4][2][3][5][8][10]

Cantina found a gap between deleting an account and deleting its authority

Cantina’s engagement ran from March 23 through April 8, 2026. Its public report credits researcher shotes with a high-severity finding concerning irrevocable delegate permissions. The publication date of the portfolio page is not stated; the engagement dates should not be mistaken for a disclosure timestamp. CryptoPotato independently describes the same account-deletion and recreation scenario.

The distinction is subtle. A delegator is the account granting authority; a delegate is the account receiving it. In the reported flaw, deleting the delegate did not remove the corresponding permission record held on the delegator’s side. An attempt to revoke then failed because the target account no longer existed. Recreating that account made the surviving permission usable again.

Analysis: this is an account-lifecycle problem, not merely a question of whether a submitted payment has a valid signature. An organization might remove a service from its own inventory while an authorization remains elsewhere. A complete access review therefore has to reconcile the ledger’s permission records with the organization’s operational records, including identities that have disappeared and later returned.

Section sources[2][3][5]

XRPLF’s April fix makes the permission record reachable from both accounts

XRPLF merged PR #6681 on April 29, 2026. The pull request describes storing the Delegate entry in the owner directories of both the delegating and authorized accounts. When either party deletes its account, deletion processing can find the entry and clean up both sides. Cantina links this pull request as the fix for its high-severity finding.

This does not mean two independent grants should be managed manually. The repair makes the same relationship discoverable from either end. That matters because deleting an account is an ordinary lifecycle event, and cleanup should follow that event without depending on a later transaction aimed at an account that no longer exists.

Practical implication: acceptance testing should cover the whole relationship. Establish a limited grant in a controlled environment, delete the delegate, inspect both accounts’ relevant records, recreate the delegate and confirm that the former grant has not returned. Treat that as a proposed integration check, not as a claim that AllAboutXRP reproduced the vulnerability or audited the patched server. The public fix establishes what changed; each operator still has to verify its own deployed version and procedures.

Section sources[3][2][5]

The 2025 fee-drain disclosure is a separate security event

XRPL’s September 29, 2025 disclosure describes a bug reported on September 15 by community member tequ. That report concerns transaction fees being charged before the necessary signature verification in a particular failure path. It says the affected amendment had not been activated on mainnet and that validators were advised to vote against it. This predates Cantina’s 2026 account-deletion engagement.

The August 26 QA history records the feature becoming unsupported in September 2025, receiving the PermissionDelegationV1_1 name with a security fix in October, and returning to supported status in June 2026. The August release subsequently packaged the revised amendment. These are distinct milestones, with different meanings for software maintenance and network availability.

Uncertainty label: the examined records do not justify collapsing every delegation weakness into a single incident, or attributing the original withdrawal to the later Cantina finding. They also do not establish that every possible flaw has been eliminated. A repaired lifecycle edge case and a prior fee-charging bug demonstrate why a feature needs several kinds of review; neither is evidence of a newly compromised XRP wallet today.

Section sources[6][1][2][5]

What RippleX’s QA results establish, and what they leave open

RippleX Developers’ August 26 report lists 179 dedicated delegation tests: 112 functional, 48 adversarial/security and 19 cross-feature tests. It also reports execution of a 5,088-test xrpld regression suite and no critical open internal bugs. These are the QA team’s reported counts, corroborated in CryptoPotato’s coverage, not measurements collected independently by this publication.

The stated environment was xrpld devnet and a private CI network. The report covers interactions involving Batch, Confidential MPT, the transaction queue and multi-signing, and limits its production-readiness conclusion to the tested commit level. That qualification matters: a test outcome attaches to particular code, configuration and scenarios, rather than to every future deployment bearing the feature’s name.

Analysis: test volume is useful evidence of coverage, but the operational question is whether the failure mode an institution cares about was exercised. A custodian should request the tested revision, confirm that its software contains the relevant fixes and retain an emergency revocation procedure. Passing an automated suite does not demonstrate that an external service’s key inventory, alerting or incident-response staff will behave correctly under pressure.

Section sources[1][5][3]

Mainnet activation remains a separate XRPL governance decision

Confirmed snapshot, September 10, 2026 at approximately 13:07 UTC: direct feature queries to Ripple’s s1 and s2 public endpoints returned PermissionDelegationV1_1 as supported but not enabled. XRPScan’s independently operated amendment API also returned enabled:false and no majority timestamp. These observations concern the specific V1.1 amendment, identified in the official registry; they are not a forecast of the next validator decision.

XRPL’s amendment process separates a server’s knowledge of a feature from the network choosing to enable it. The official amendments documentation requires sustained validator support through the prescribed voting period. Readers should consult fresh network state when making an operational decision, because an article’s snapshot can become outdated. An audit report, release announcement or readiness statement is not a substitute for that state.

Analysis: this creates two approval questions for a custody team. Is the revised implementation acceptable under the organization’s security criteria? Is the feature actually available on the network where the service will run? A yes to the first does not answer the second. No activation date is asserted here, and the checked records do not support claiming a resulting increase in XRP payment demand, institutional adoption or token price.

Section sources[8][9][10][11][4]

What XRP issuers and custody teams should require before deployment

The current XRPL permission-delegation guide describes grants created, updated or revoked with DelegateSet. It distinguishes permissions for a transaction type from narrower, predefined permissions. It also warns that granular permissions cannot be customized arbitrarily. A team should therefore compare the exact available permission with the intended business role, rather than assume the protocol expresses every internal spending restriction.

For an issuer, a restricted service account could handle recurring actions while more powerful keys stay offline. For a custody provider, the benefit would be a smaller set of actions available to an exposed operational key. Those are intended design uses described by XRPL, not evidence that a particular bank or token issuer has adopted the revised feature.

Operational inference: the permission inventory should identify who granted each role, who controls the delegate’s keys and who can execute revocation if the normal service is unavailable. Monitoring should distinguish successful grant removal from a failed request or an application merely hiding a delegate. The case for this feature depends on bounded authority that remains removable throughout the account lifecycle. That is the concrete control to evaluate before treating delegation as a production security improvement.

Section sources[7][2][3][1]