Key takeaways XRPL introduces more granular institutional account permissions Developers warn PaymentBurn delegation can enable unintended token minting The warning concerns issued tokens, no
The XRP Ledger's new account-permission system carries a security warning affecting token issuers, even as the network advances features designed for banks and institutional asset managers.
PermissionDelegationV1_1, scheduled for activation on October 8, allows accounts to authorize other accounts to perform specific operations without sharing their primary cryptographic keys. However, official XRPL documentation cautions that delegating one particular permission, PaymentBurn, can unexpectedly allow the creation of additional issued tokens in certain circumstances.
The warning concerns trust-line tokens and Multi-Purpose Tokens (MPTs), not XRP itself. Developers recommend avoiding that permission until a separate corrective amendment becomes active.
XRPL's Banking Upgrade Introduces 10 Delegated PermissionsPermissionDelegationV1_1 introduces the DelegateSet transaction, enabling accounts to assign up to 10 specific permissions to another account.
For banks and token issuers, that creates a way to separate responsibilities such as payment execution, account authorization and other operational functions without exposing full account control.
According to the official XRPL specification, administrators can grant, modify or revoke those permissions through on-chain transactions.
The upgrade was previously expected to activate in early October, but changes in validator support delayed its timetable.
Unlike traditional account sharing, delegated permissions restrict what another authorized account can execute. Certain sensitive operations, including actions that change account authorization, cannot be delegated.
PaymentBurn Warning Raises Questions for Token IssuersThe concern involves PaymentBurn, a granular permission intended to allow delegated accounts to destroy issued tokens under defined conditions.
According to XRPL's official permission documentation, a delegate holding this permission can also mint new fungible tokens in certain circumstances before the fixCleanup3_4_0 amendment activates.
That behavior goes beyond the authority normally associated with burning tokens and could create operational risks for institutions that rely on strict issuance controls.
Developers explicitly recommend against delegating PaymentBurn until the correction is enabled. Other granular permissions are unaffected by the identified issue.
Importantly, the warning does not establish that additional XRP can be created or that attackers have exploited the behavior.
What Happens Before the Security Fix Activates?The issue places additional importance on permission management as financial institutions increasingly explore XRPL tokenization.
The network recently addressed a separate critical security vulnerability, but that incident involved different technical conditions and should not be confused with the PaymentBurn warning.
For institutional users, the immediate precaution is clear: avoid granting the affected permission while continuing to use unaffected delegation features where appropriate.
The next milestone is activation of fixCleanup3_4_0, which developers identify as the amendment needed to correct the unexpected minting behavior.
