XRP Ledger Activates Permission Delegation for Institutions

The XRP Ledger activated its permission delegation feature on October 8, 2026, allowing an account owner to authorize a separate account to send specific transactions without sharing the keys that control the owner’s account. The change took effect when the PermissionDelegationV1_1 amendment became enabled on the network, according to the XRPL amendments dashboard.

The XRPL documentation describes permission delegation as a way to build role-based access control, an arrangement in which each account can perform only the tasks assigned to its role. Owners can use it instead of, or alongside, multi-signing, a feature that lets several key pairs sign for one account.

The documentation says a secure setup should limit the damage if a secret key is compromised, and it lists the practice to “keep master keys off of computers that are always connected to the internet.” Businesses that sign transactions automatically usually need secret keys on an internet-connected server, which is the problem the feature targets.

How XRP Ledger Permission Delegation Works

An account owner, called the delegator, sends a DelegateSet transaction to name another account as its delegate and to list the permissions that delegate holds. The delegator can update or revoke those permissions at any time. A delegator can also name more than one delegate and give each a different set of permissions. The delegate signs with its own keys and pays the transaction cost.

Each delegate can hold up to 10 permissions. Permissions that would let a delegate change cryptographic keys or grant additional permissions cannot be delegated. The list of granular permissions, meaning permissions limited to part of a transaction type’s functionality, is hard-coded. The documentation gives one example of the limit: an owner cannot grant permission to send only certain currencies.

The documentation says the feature is especially helpful for stablecoin issuers that use Authorized Trust Lines. That compliance feature requires an issuer to approve each user individually after meeting regulatory requirements such as Know Your Customer rules. Limited permissions can go to separate accounts whose keys stay online for day-to-day tasks, while the keys with full control over the issuer account stay offline for special tasks such as issuing tokens.

PaymentBurn Warning Applies for Now

The documentation advises against delegating the PaymentBurn permission, which covers payments that destroy tokens, until the fixCleanup3_4_0 amendment is enabled. Before that fix, a delegate holding PaymentBurn can also create new fungible tokens in certain circumstances. The warning covers both trust line tokens and Multi-Purpose Tokens (MPTs). The documentation states that other granular permissions are unaffected.

Delegated transactions also cannot wait in the transaction queue. A delegated transaction that cannot apply to the open ledger immediately fails with the result code telCAN_NOT_QUEUE.

Interested in advertising with CIM? Talk to us!