The XRP Ledger's PermissionDelegationV1_1 amendment is now live on mainnet, according to the XRPL amendment tracker, which records the feature taking effect on October 8 at ledger 107,524,865. The amendment completed its validator-approval period in late September, and that process has now produced a live account-control tool for the ledger. Under XRPL's amendment process, features reach mainnet only after validators approve them through consensus, making this activation the point at which the tooling becomes available for production use.

Activation makes Permission Delegation available to institutions, although no bank, stablecoin issuer or fund manager has publicly confirmed an implementation so far. Businesses can now build these permission structures directly on XRPL, while the practical details remain the responsibility of their wallet providers, custodians and internal security teams. The need the amendment addresses is long-standing in institutional digital asset operations, where signing authority for routine transactions is typically kept separate from the master credentials that control a treasury. Permission Delegation moves part of that separation onto the ledger itself rather than leaving it entirely to off-ledger software.

A stablecoin issuer can divide routine work across accounts

A stablecoin issuer, for example, may need one team to approve eligible customers and another to process routine transfers. Under the new model, the issuer's primary account can stay under stricter custody, while a compliance account receives authority to approve trust lines after KYC checks and an operations account gains payment authority. Each account holds only the role assigned to it, limiting the damage a compromised day-to-day key can cause.

A business could divide wallet duties as follows:

• Primary account: Creates, changes or revokes delegated roles while its key remains under stronger custody.
• Compliance account: Receives authority for a defined customer-approval task.
• Operations account: Receives authority to submit an approved category of transaction, such as a payment.

XRPL records each assignment in a Delegate ledger entry. The account receiving the assignment signs with its own credentials and pays the transaction fee from its own balance, while the authorised action takes effect for the primary account. XRPL's documentation describes the arrangement as role-based access control that can work alongside multi-signing.

Where delegated authority ends

A business can grant authority over particular transaction types or predefined granular functions. Each delegate can hold up to 10 permissions, and the primary account can update or revoke them through another DelegateSet transaction.

Some powers remain exclusively with the primary account. A delegate cannot change its cryptographic keys, create further delegations or submit a transaction outside the permissions it has received. Each delegation also creates an on-ledger object that counts toward the primary account's reserve requirement.

The permission set includes no custom payment-policy function. A business cannot use Permission Delegation alone to enforce rules such as “payments below $10,000 only” or “transfers only to these addresses.” Those controls still belong in wallet software, approval workflows or compliance systems.

Ledger permissions and compliance decisions stay separate

Permission Delegation determines which account submits an approved XRPL action, nothing more. KYC checks, sanctions screening, investor records, fund documents and legal responsibility remain with the issuer and its service providers. The amendment divides technical authority; it does not automate the underlying compliance decision.

XRPL's fund-recordkeeping pilot with Brazil's CSD BR follows a similar principle: the ledger can support a controlled workflow while established market infrastructure remains responsible for the official ownership record. Permission Delegation could give projects using that model more flexibility over which account carries out each authorised ledger action.

One delegated permission carries a published warning

XRPL's documentation advises businesses against delegating the PaymentBurn granular permission until a separate amendment, fixCleanup3_4_0, becomes active. Until that fix arrives, the documentation states that a delegate holding PaymentBurn authority could also mint fungible tokens in certain circumstances. Other granular permissions are unaffected.

The warning applies to a single permission rather than to the amendment as a whole, but it illustrates why issuers need to review each delegated role before moving routine functions to separate online accounts.

What businesses can do with the new feature

Permission Delegation gives XRPL issuers a way to divide responsibility across wallets without sharing the credentials that control their main account. Its practical value will depend on the policies built around it: which tasks are delegated, how quickly permissions can be revoked, and whether wallet providers turn the protocol feature into a usable business-control system. The nearest-term signals are observable rather than speculative: whether wallet and custody providers add support for the new delegation transactions and ledger entries, and whether fixCleanup3_4_0 reaches activation — the condition XRPL's documentation sets before PaymentBurn can be delegated.

This article is for informational purposes only and does not constitute legal, financial or investment advice. Businesses should review XRPL's current technical documentation and their own security policies before using delegated permissions.