XRP Ledger master key secured in a vault with three separate delegated operational keys

XRP Ledger Turns On Permission Delegation, Giving Institutions Safer Account Controls

By Isaac • October 9, 2026 7:07 pm • Comments

The XRP Ledger just switched on a feature that looks technical on the surface but solves a very practical problem for institutions: how do you let employees and service providers do specific jobs without handing them the keys to the entire treasury?

PermissionDelegationV1_1 went live on October 8. It allows an XRPL account to authorize separate accounts to perform narrowly defined actions on its behalf while the main account keeps control of its own credentials.

That matters because the old choice was often too blunt. A company could keep its most powerful keys offline, which is safer but makes routine operations harder, or it could put broader signing authority on an online system, which is convenient but expands the damage a compromised key could cause.

Trending: Bitcoin’s $81,000 Break Turns Into a $1 Billion Leverage Washout

A new layer of separation for XRPL accounts

The XRP Ledger’s own documentation says delegation can work alongside multisigning and other security controls. The account granting authority is the delegator.

The separate account carrying out a task is the delegate.

The documentation says a delegator can maintain several delegates with different roles, and each delegate can sign with its own master key, regular key or multisigning list. A delegated transaction must match an authority already recorded on the ledger, so the operational account cannot simply expand its own powers.

Delegated transactions also cannot wait in the normal transaction queue. If one cannot apply to the open ledger immediately, it fails instead of sitting for later execution, giving operators a clear result instead of a delayed action that might execute under changed conditions.

The delegator uses a DelegateSet transaction to assign a specific list of permissions. Those permissions can later be changed or revoked.

The delegate signs with its own key and pays the transaction fee from its own account, but the approved transaction acts on behalf of the delegator.

In plain English, a stablecoin issuer could let one operational account approve authorized trust lines without giving that account permission to change the issuer’s keys or perform unrelated treasury actions. A compliance provider could do its assigned work without receiving control of the institution’s master credentials.

The final XLS-75 standard describes this as a way to support more flexible account management and multi-party workflows. It creates a Delegate ledger object and a DelegateSet transaction rather than forcing every organization to recreate the same authorization logic in a custom smart contract.

The specification uses a token issuer as its practical example. One employee can be limited to token issuance, another can manage trust lines, and an outside compliance provider can authorize trust lines after customer checks without receiving unrelated account powers.

That separation is the point of the amendment: each operational participant carries its own credentials, while the main account retains the authority to define or remove every delegated role.

The limits are as important as the feature

Delegation is not unlimited. XRPL’s documentation says one delegate can receive up to 10 permissions.

Certain sensitive actions cannot be delegated at all, particularly actions that would let a delegate change cryptographic keys or grant new permissions to someone else.

There is also a specific warning that users should not ignore. The documentation advises account owners not to delegate the PaymentBurn permission until the separate fixCleanup3_4_0 amendment is enabled.

Before that fix, PaymentBurn can allow a delegate to mint fungible tokens in certain circumstances. Other granular permissions are not affected by that warning.

Unchained places the activation at ledger 107,524,865 on October 8 and reports that the feature lets an owner assign selected transaction duties to a separate account, revise or revoke those duties later, and keep the owner’s primary credentials out of routine online operations. Its report also separates the live amendment from the unresolved PaymentBurn issue: delegation itself is available, but XRPL’s official guidance says operators should withhold that one granular permission until fixCleanup3_4_0 activates, because the current behavior can permit unauthorized token minting in limited circumstances.

Why this arrives at the right moment

The timing fits XRPL’s growing push into tokenized assets. The network is trying to win business that demands both always-on settlement and controls that resemble the role separation institutions already use internally.

CryptoSlate’s current reporting connects permission delegation to the larger effort to make tokenized assets usable as round-the-clock collateral. The core idea is straightforward: assets can move continuously, but the people and systems operating them still need clear boundaries.

Permission delegation will not create institutional adoption by itself, and it does not change XRP’s supply. It removes a real operational objection.

A bank, issuer or asset manager can split duties more precisely, keep the strongest keys away from day-to-day systems, and revoke a worker’s authority without rebuilding the entire account.

The feature is infrastructure, not a price catalyst. Its value will be measured by whether serious issuers use those narrower controls to put more assets and routine financial work on the ledger.

Join the conversation!

We have no tolerance for comments containing violence, racism, profanity, vulgarity, doxing, or discourteous behavior. If a comment is spam, instead of replying to it please click the icon below and to the right of that comment. Thank you for partnering with us to maintain fruitful conversation.

 

Search ProCoinNews