XRP Ledger again attempts new upgrades, allowing banks to separate payments from compliance responsibilities

Delegation: Allocating multiple responsibilities from one account

The XRP Ledger ((XRPL) network introduced an upgrade called PermissionDelegationV1_1, which allows individual accounts to divide their permissions according to the job function. According to official XRPL documentation, each delegated account can receive up to 10 permissions and the master account can modify or revoke these at any time.

Specifically, this design provides a flexible portfolio of permissions for institutional users. For example, an stablecoin issuer can have the network's compliance system responsible for approving which customer accounts are eligible to hold its token , while maintaining complete control over key keys that remain offline. At the same time, another account in charge of day-to-day operations may only receive payment authorization but has no ability to modify the core key or delegate authority.

Why the First Edition Folded

Notably, PermissionDelegationV1_1 is the network's second attempt to introduce permission delegation functionality. The previous first version had a security flaw that could allow an attacker to force other accounts to pay fees for transactions not signed properly.

The problem arises in the order of procedures: software first determines whether an account is authorized to execute a transaction and then verifies its signature. According to XRPL's vulnerability report, some failures still charge fees, meaning that funds may have been deducted before signatures are found invalid. If attackers repeatedly submit transactions with deliberately set high commission rates, victims' XRP balances could be gradually depleted.

A community tester detects a vulnerability and the verifier is intercepted in time

The flaw was discovered and reported by a community tester on September 15, 2025, when testing the feature outside of mainnet . Subsequently, the community advised each validator to reject the fix, so the first version was never activated in mainnet

Today's re-launch of V1_1 fixes the signature validation sequence issue, allowing permission assignment to be officially deployed. This feature provides native support for multi-role collaboration and reduces the risk of core keys being exposed over time in a networked environment for enterprises and project parties who wish to fine tune their permissions management on on-chain .