The XRP Ledger has released a hardened version of its Permission Delegation feature after a high-severity bug was identified during testing. The original V1.0 was withdrawn before reaching mainnet, with a reworked V1.1 now completing security review and approved for production deployment.
Permission Delegation, formally known as XLS-75, enables one account to grant another account specific powers to act on its behalf with limited, narrow permissions rather than full account control. A researcher identified a critical flaw where a delegate could delete and recreate their account while retaining irrevocable permissions granted by another account, with no revocation mechanism available.
Scope of Security Fixes
Beyond addressing the core vulnerability, V1.1 introduces broader safeguards including restrictions preventing newer Vault and Lending features from being delegated unintentionally. The update also fixes reserve accounting for delegated payments, closes a multi-signing pathway that could circumvent delegation checks, and tightens revocation behavior.
A medium-severity unsigned integer overflow issue in isDelegable was also identified and resolved. The flaw could have allowed malformed permission values to be misinterpreted as delegable transaction types, though researchers noted it posed no practical risk without deliberate delegator misconduct.
Testing and Verification
Quality assurance testing included 179 dedicated Permission Delegation tests comprising 112 functional tests, 48 adversarial security tests, and 19 cross-feature tests. Testing covered interactions with Batch, Confidential MPT, the transaction queue, and multi-signing. Cantina security firm verified all identified issues were fixed in V1.1.
XRP Ledger Operations reported no regressions across 5,088 tests and no open internal bugs classified as critical at the tested commit level. A public testing dashboard had previously flagged Permission Delegation as incompletely exercised on devnet before mainnet consideration.
The feature's user-facing functionality remains unchanged from the original design. The revision instead modifies the conditions under which the capability activates to ensure security safeguards are enforced.
