XRP Ledger Permission Delegation Returns After a Security Pull

13 of 35 trusted validators supported PermissionDelegationV1_1 after Vet, a default Unique Node List operator, voted Yes on September 8. The amendment is the rewritten successor to a feature the network pulled in 2025, when a fee bug could have drained XRP from accounts that never signed.

XRP Ledger Operations said Cantina had verified the fixes and that quality assurance found no regressions across 5,088 tests. That clearance is why a validator who sat out the first version is willing to vote. It is not the same thing as turning the feature on.

Vet Votes Yes, and the Tally Is Still 13 of 35

XRPSCAN listed PermissionDelegationV1_1 at 37.14% support, or 13 of 35 votes, on the live amendment board. The XRP Ledger enables a protocol change only after it holds more than 80 percent of trusted validators for two continuous weeks. If support drops under that mark, the two-week clock starts over.

Vet wrote that he had just voted Yes, that the code had been reworked for months after “the initial issues last year,” and that Cantina had re-reviewed the security. He called Permission Delegation a critical feature for issuers and treasury managers who need to hand out narrow jobs while the main account keys stay in cold storage.

XRP Ledger Operations posted the audit note a few minutes earlier, with links to Cantina and to the QA write-up.

https://x.com/XRPLOperations/status/2097315273510449243

The public conversation treated that post as if limited powers were already live on mainnet. They are not. The original PermissionDelegation amendment is obsolete. The replacement is still in the voting column, and the default path for a validator who does nothing is to leave it off.

A September Fee Bug Forced the Network to Pull V1.0

The first version shipped in rippled 2.5.0 and reached a voting phase without ever activating on mainnet. On September 15, 2025, a community tester named tequ reported the hole on devnet. The September 2025 vulnerability disclosure said an account could charge transaction fees to another account and, with a high fee and an offline-signed transaction, drain XRP.

Delegated fees are meant to be paid by the delegate. In the broken code, permission was checked before the signature. A missing permission returned a tec-class error, and tec errors still charge a fee. A stranger could point a Delegate field at a victim, sign offline to skip the RPC check, and keep billing the victim as long as that account lacked the permission being claimed.

J. Ayo Akinyele, head of engineering at RippleX, said the bug came in through the bug bounty program before mainnet, and that the team pulled the amendment instead of issuing a quiet patch. “Rather than simply patching it, we pulled the amendment and recently introduced V1.1 to create a clear distinction between the original implementation and the hardened version,” he wrote on September 8.

Validators were told the same day as the report to vote No. The original amendment was disabled in rippled 2.6.1 and later marked obsolete. The replacement, PermissionDelegationV1_1, is the version packaged with xrpld 3.3.0 alongside rewritten Batch and Permission Delegation code that had both been blocked before activation.

THE SEPTEMBER 2025 PULL

1. September 15, 2025: tequ reports the fee-drain bug on devnet during the first amendment’s voting phase.
2. September 15, 2025: operators on the Unique Node List are told on Mattermost to vote No and block activation.
3. September 29, 2025: the XRP Ledger site publishes the disclosure and the plan for a replacement amendment.
4. rippled 2.6.1: PermissionDelegation is disabled and later listed as obsolete, replaced by PermissionDelegationV1_1.
5. March 23 to April 8, 2026: Cantina reviews the rewrite in the XRPLF/rippled repository.
6. September 8, 2026: XRP Ledger Operations posts the Cantina and QA clearance, and Vet votes Yes.

The disclosure itself warned that swapping amendments “may potentially slow down the timeline for the feature to go live.” That delay is the year the network just spent.

Cantina’s Rewrite Review Still Found a High-Risk Hole

Cantina’s public report, a solo engagement by a researcher using the handle shotes, covers March 23 to April 8, 2026. It lists one high finding, one medium finding, and two informational notes. The high and medium items are marked fixed. The two informational notes are acknowledged and left as they are.

The high finding is irrevocable delegate permissions after deletion. A delegate could delete its own account, after which the delegator could not send a DelegateSet to strip the grant, because the preclaim path required the delegate account to exist. Recreating the same account later restored the old powers. Cantina also noted that the leftover Delegate object held the delegator’s reserve hostage. Ripple’s proposed fix, recorded in the report and landed as PR 6681, was to store the Delegate object on both sides so deletion on the delegate side clears the grant.

The medium finding was an unsigned integer overflow in isDelegable. A uint32 permission value truncated to uint16 could wrap onto a delegable transaction type, which let a crafted list dodge the duplicate check. Cantina judged the practical impact low because the delegator would have to misbehave. It was still fixed, in PR 7047.

CANTINA FINDINGS ON V1.1

Akinyele said V1.1 also closed edge cases around delegate identity, stopped Vault and Lending operations from being delegated by accident, fixed reserve accounting on delegated payments, shut a multi-sign path that could bypass checks, and tightened revocation. “V1.1 doesn’t change the core capability or what users and custody providers can build with XLS-75. It makes the original capability safer to activate,” he wrote.

What a Delegate Can and Cannot Do

The delegator sends a DelegateSet transaction that names another funded account and a list of permissions. That second account, the delegate, can then submit transactions that run as if they came from the delegator, signed with the delegate’s own master key, regular key, or signer list. Official docs on how permission delegation works say the delegator can change or revoke the grant at any time with another DelegateSet, and can give different sets of permissions to different delegates.

Permissions are either a whole transaction type, such as Payment, or a granular slice of one type. Some types cannot be delegated at all, including AccountSet, DelegateSet, AccountDelete, and Batch, because those would let a helper change keys, grant itself more power, erase the account, or wrap a bundle the network has not fully tested under delegation. The XLS-75 permission delegation standard, written by Mayukha Vadari, Yinyi Qian, and Ed Hennis, is the spec behind the amendment. XLS-74 holds the shared permission values other features can reuse.

The fee on a delegated transaction is paid by the delegate, not by the account that owns the assets. That is the opposite of multi-signing, where the account that owns the signer list pays. Multi-signing can still send almost any transaction once the quorum is met. Delegation is narrower by design, and it has no M-of-N quorum of its own.

DELEGATION LIMITS IN THE SPEC

• Ten permissions: Each delegate can hold at most 10 permissions on one Delegate object.
• Owner reserve: Each delegate costs one Delegate ledger entry, which counts toward the delegator’s owner reserve.
• Key changes blocked: AccountSet, SetRegularKey, SignerListSet, and DelegateSet cannot be handed off, so a helper cannot promote itself.
• No currency filters: Granular permissions are hard-coded; an issuer cannot grant “this currency only.”
• No queue: A delegated transaction that cannot apply to the open ledger fails with telCAN_NOT_QUEUE instead of waiting in the transaction queue.

Jazzi Cooper, head of product at RippleX, described the feature in July as the on-chain primitive for role-based access control, so a treasury can keep issuance keys and still let a desk place offers or run a clawback inside a defined limit.

Treasury Desks Want the Master Key Offline

The people who actually need this are not casual holders. They are stablecoin issuers who must approve trust lines after KYC, RWA shops that mint and claw back, and treasury teams that want a hot wallet for daily DEX offers without putting the master seed on the same machine. Vet named those jobs in the same post as his vote: compliance clawbacks, DEX trading, and minting payments, “all while keeping the main account keys in cold storage.”

Permission Delegation is critical feature for the XRP Ledger. Allowing (RWA, Stablecoin, Meme coin etc) issuers as well as Treasury managers to securely build their operations on the XRP Ledger by giving them the ability to delegate permissions to perform very specific tasks.

Vet, dUNL validator, on X

https://x.com/Vet_X0/status/2097318426951704958

A helper can run those tasks without taking custody of the master key, which is the point of putting the grant on the ledger instead of sharing a seed. The grant is revocable with one DelegateSet if the helper’s keys leak. The network still blocks the dangerous jobs, so a stolen hot key should not be able to rotate the account or hand itself more scope.

That is also why the 2025 bug was so awkward for the same users. The whole pitch is that a treasury can leave the crown jewels offline. A fee path that billed the offline account for unsigned junk would have punished the exact setup the feature exists to protect. The rewrite had to make that path fail before any fee is taken, which is why the error class moved off tec and the signature check moved forward.

Batch Is Closer to Activation Than Delegation

xrpld 3.3.0 put five feature amendments in front of validators at once. PermissionDelegationV1_1 is not the one nearest a supermajority. BatchV1_1, the other rewrite of a feature that was pulled after a signature bug, sat at 25 of 35 votes, or 71.43 percent. Sponsor, ConfidentialTransfer, and DynamicMPT were further back.

XRPLD 3.3.0 FEATURE VOTES

fixCleanup3_3_0, a cleanup amendment from the same release, already had 31 of 35 votes, or 88.57 percent, and was in its two-week activation window. Validators are clearly willing to turn on a fix when the code is boring. They are slower on the two features that already failed a security review once.

The two-week clock for PermissionDelegationV1_1 has not started. Thirteen Yes votes after a Cantina pass and a public pledge from a well-known dUNL operator still leave the amendment in the same bucket as Single Asset Vault, which is a different product with the same 13 of 35. Until that share holds above 80 percent for two weeks, issuers who want a clawback desk and a cold master key keep waiting on a feature the network has already pulled once.

Disclaimer: This article is news reporting on an XRP Ledger protocol vote and related security reviews. It is informational only and is not investment advice, trading advice, or a recommendation to buy, sell, or hold XRP or any other token. Readers who are considering any digital-asset decision should consult a qualified financial adviser or licensed investment professional who can review their own facts. Vote tallies, amendment status, and audit details reflect the cited pages and posts as of the dates given in the article and can change as validators update their votes.