The XRP Ledger is moving forward with a second attempt at introducing permission delegation capabilities. The PermissionDelegationV1_1 upgrade entered a 14-day activation countdown on September 21 after 29 of the network's 35 trusted validators backed it. If support remains at or above 80% throughout the period, the upgrade could activate on October 5 at 11:18 UTC.
At least 28 validators must continue supporting the upgrade for it to proceed. Any drop below that threshold would reset the activation clock.
How Permission Delegation Works
The feature allows an account to divide its authority by delegating specific duties to other accounts without surrendering full control. A stablecoin issuer, for example, could allow an internet-connected compliance system to approve customer accounts while keeping the keys with full control offline.
Separate operational accounts could receive permission to make payments without gaining the ability to change keys or grant authority to others. Each delegate can receive as many as 10 permissions, which the main account can modify or revoke at any time.
Addressing Security Flaws from First Attempt
The current proposal represents a revision of an earlier version that contained a critical vulnerability. The original flaw could allow an attacker to make another account pay fees for transactions it had not properly signed. Repeated submissions with deliberately high fees could have drained the victim's XRP balance.
The security issue stemmed from a logic error in the software's transaction verification process. The system checked whether an account had permission to carry out a transaction before verifying its signature, meaning fees could be deducted even for invalid transactions.
A community tester reported the flaw on September 15, 2025, while the feature was undergoing testing outside the main network. Validators were advised to reject the amendment, and it never activated.
The replacement version, included in xrpld 3.3.0 server software, restructures how unauthorized transactions are rejected to prevent fees from being charged before signature verification is completed.
