Permission Delegation: Unlocking a New Era of XRPL Account Management

Yinyi Qian — Tue, 24 Jun 2025 20:29:05 +0000

Introduction: What is Permission Delegation?

The proposed Permission Delegation feature represents a significant upgrade in operational flexibility and security for token issuers, notably by enabling clear segregation of duties. It empowers issuers to delegate specific account actions or transaction types to other designated accounts without the need to share the primary issuer account’s keys. This allows specialized accounts to be authorized for their defined roles instead of being added to the issuer’s main Multi-Signature configuration where any rules are uniformly applied across all transactions regardless of business function.

Permission Delegation provides issuers with far more granular control over their operations, facilitating the segregation of duties required to manage diverse business functions. This meaningfully enhances the security of their core account by limiting its direct exposure for certain tasks, ultimately reducing overall risk.

Technical note:

The Feature: XLS-75d “Permission Delegation”, is the new feature that allows delegating specific account actions to another account without sharing keys.
The Definitions: XLS-74d “Account Permissions”, is the definer of these permissions.

Performance Testing: The Permission Delegation feature has undergone rigorous testing and analysis. XRPL remains performant across all scenarios, validating that the feature can be safely integrated into the rippled implementation without compromising network stability or performance.

Security Audit: Permission Delegation Security Audit Findings.

Terminology:

Delegator / Delegating Account: The account that grants permissions.
Delegatee / Delegated Account: The account that receives permissions.

Key Feature Highlights

Granular delegation: Assign permissions with multiple levels of precision. This includes granting authority for transaction level actions, as well as more granular permissions that only allow for specific actions within a transaction.
On-Ledger and secure: Delegation of specific transaction permissions, recorded as a new Delegate ledger object, enforced by the protocol.
Full control: Delegator can create, modify, or revoke these permissions at any time.
On-Chain Authorization: All transactions executed are signed by the delegated account and permanently recorded on the ledger. This creates a verifiable audit trail for every authorized action, offering a distinct advantage over systems that rely on off-chain policy engines for transaction authorization.

Benefits of Permission Delegation

Enhanced security: Permission Delegation drastically reduces the risk associated with compromised keys by allowing the delegation of specific, limited permissions instead of requiring full key access for every action. This fundamentally changes access management and improves security for different participants:

Token issuers can delegate routine yet essential tasks to separate, specialized accounts without adding them as signers to their primary Multi-Signature setup. These operational accounts receive only the precise permissions needed for their specific function, protecting the integrity of the primary issuing account from risks associated with daily operational needs.
Users can grant minimal necessary access to third-party applications for specific tasks without exposing their primary funds or full account control. If a delegated key for a particular service were compromised, their main account and other assets would remain secure.
Developers can build applications that inherently require less trust from users. dApps can operate effectively by requesting only narrow, clearly defined permissions for specific functionalities.
Validators and infrastructure providers can potentially apply similar principles of delegation for certain routine, non-critical operational tasks. By assigning specific, limited permissions to separate accounts for these functions, they can enhance their own security posture and contribute to the overall stability of the network.

Increased Flexibility and Granular Control: Permission Delegation adds a new layer of Role-Based Access Controls. Access rights can be precisely tailored to specific tasks or roles and facilitate compartmentalization of duties. Different operational aspects of an account can thus be managed with distinct authorizations, enabling safer automation of account interactions.

Fosters Innovation and Enables New Use Cases: By providing a secure mechanism for delegating authority, Permission Delegation directly unlocks a wide array of new possibilities and services. It allows XRPL to support a more diverse range of use cases and encourages innovative solutions.

Use cases unlocked by Permission Delegation

MiCA Compliance: Permission Delegation can assist entities in meeting the EU’s MiCA requirements by strengthening governance, operational controls, and third-party risk management.

For Issuers: EU-based stablecoin issuers can meet MiCA’s stringent governance and operational mandates by allowing delegation of specific tasks like redemption processing to distinct internal roles or automated systems.
For Managing Third Parties: When entities outsource functions or engage third party services, Permission Delegation enables them to grant only minimal, task-specific functions. For instance, a business raising funds through tokenized debt or equity sales can enable other distributors to help run KYC checks and facilitate the distribution of assets. Another example is law enforcement, where an issuer could outsource Freeze and Clawback capabilities for a compliance provider who can sign for that action in cases of a government order.
RLUSD: Ripple plans to use Permission Delegation for the RLUSD stablecoin, using the feature to segregate signing responsibilities by delegating permissions for specific transaction types to distinct, specialized accounts. Each of these delegated accounts, managed by different segments of our global operations team, will only have the authority needed for their particular function. This increases issuer account security by having different signer lists sign for different transactions. Additionally, it will scale the number of signers which can interact with the issuer account, allowing us to scale our global operations team more easily.

Automated Financial Services:

Automated payments: Delegate Payment permission to a service to make specific, recurring payments on your behalf.
Portfolio management: Grant limited permissions (e.g., OfferCreate for specific pairs, TrustSet for vetted assets) to an automated service to manage a portion of a user's portfolio.

Enhanced Security and Key Management:

Outsource Critical Compliance Functions: Stablecoin issuers can delegate permission for Freeze and Clawback transactions to a specialized account managed by a trusted KYT provider to mitigate financial crime.

Business and Organizational Accounts:

Corporate Treasury Management: Delegate specific permissions to different departments or employees (e.g., payroll account can only make Payment transactions, an auditor account gets permission for specific data-setting transactions, if applicable).

DeFi and Specialized Interactions:

Controlled AMM Participation: Delegate permissions like AMMDeposit, AMMWithdraw, or AMMVote to a third-party service or a bot that executes predefined strategies, without exposing the user's entire capital.
Issuer-Managed Authorizations: An issuer could delegate the ability to authorize trustlines (TrustSet with tfSetfAuth) for their token to a KYC/KYB provider.

Get Started: Testing PermissionDelegation on Devnet

Prerequisites

Make sure your client libraries (e.g., xrpl.js, xrpl-py) are updated to a version that supports PermissionDelegation amendment if you plan to use them. (Minimum required versions: xrpl@4.3.0 , xrpl-py@4.2.0)
Alternatively, you can send requests directly without any libraries by using tools like Postman or curl. Both HTTP and WebSocket protocols are supported.
The XLS-75d amendment PermissionDelegation must be enabled on the Devnet instance you are using.

Accessing Devnet

Obtain test accounts and fund with XRP from an XRPL Faucet: https://xrpl.org/resources/dev-tools/xrp-faucets
Connect to a Devnet server via WebSocket: wss://s.devnet.rippletest.net:51233
Alternatively, you can send requests through HTTP: https://s.devnet.rippletest.net:51234
Optionally, you can start your own local server to join the Devnet. This allows you to send requests directly to your server using a custom IP address and port that you configure. Find more details here..

Basic Test Scenario

Delegate: Using Account A (Delegating Account), submit an DelegateSet transaction to grant Account B (Delegated Account) specific permissions, such as Payment, and TrustSet. The following request is a websocket request example sent to wss://s.devnet.rippletest.net:51233.

{
   "command": "submit",
   "tx_json" : {
     "TransactionType" : "DelegateSet",
     "Account" : "DelegatingAccount_A",
     "Authorize" : "DelegatedAccount_B",
     "Permissions":[
        {"Permission": {"PermissionValue": "Payment"}},
        {"Permission": {"PermissionValue": "TrustSet"}}
     ]
  },
  "secret":"DelegatingAccount_A_secret"
}

Alternatively, you can send request via HTTP
https://s.devnet.rippletest.net:51234

{
   "method": "submit",
   "params": [
     {
       "tx_json": {
         "TransactionType": "DelegateSet",
         "Account": "DelegatingAccount_A",
         "Authorize": "DelegatedAccount_B",
         "Permissions": [
           { "Permission": { "PermissionValue": "Payment" } },
           { "Permission": { "PermissionValue": "TrustSet" } }
         ]
       },
       "secret": "DelegatingAccount_A_secret"
     }
   ]
 }

Verify: Check ledger entry for the new Delegate object. For example, send HTTP request:

{
 "method": "ledger_entry",
 "params" : [
   {
     "delegate": {
     "account": "DelegatingAccount_A",
     "authorize": "DelegatedAccount_B"
   },
   "ledger_index": "validated"
   }
 ]
}

Execute: Using Account B, attempt to send a Payment transaction on behalf of Account A. Here is an example of the delegation Payment by websocket:

{
   "command": "submit",
   "tx_json" : {
     "TransactionType" : "Payment",
     "Account" : "delegatingAccount_A",
     "Destination": "destinationAccount",
     "DeliverMax": 100000000,
     "Fee": 20,
     "Delegate": "delegatedAccount_B"
  },
  "secret":"delegatedAccount_B_secret"
}

Alternatively, you can send an HTTP request. If the delegation is valid, the request will succeed.
Account A will initiate a payment of up to 100 XRP to the destination, while Account B will cover the transaction fee.

Revoke/Update Permissions: Using Account A, submit a DelegateSet transaction to update the Delegate object and verify that Account B can no longer perform the revoked action. For example, if Account A wants to revoke the Payment permission but retain the TrustSet permission, simply remove Payment from the permission list. The new DelegateSet transaction will override the previous Permissions entirely.

{
   "command": "submit",
   "tx_json" : {
     "TransactionType" : "DelegateSet",
     "Account" : "DelegatingAccount_A",
     "Authorize" : "DelegatedAccount_B",
     "Permissions":[
        {"Permission": {"PermissionValue": "TrustSet"}}
     ]
  },
  "secret":"DelegatingAccount_A_secret"
}

If Account A wants to revoke all permissions, simply submit an empty permission list.

{
   "command": "submit",
   "tx_json" : {
     "TransactionType" : "DelegateSet",
     "Account" : "DelegatingAccount_A",
     "Authorize" : "DelegatedAccount_B",
     "Permissions":[
     ]
  },
  "secret":"DelegatingAccount_A_secret"
}

The Permissions field’s permission list replaces the entire set, so Account A can revoke some permissions while simultaneously adding new ones.

Granular Permissions: You can also try granting granular permissions, such as AccountDomainSet, which allows the delegated account to change the delegating account's domain by submitting an AccountSet transaction. Please note that the AccountDomainSet permission only authorizes domain changes. Any other modifications using AccountSet, such as setting flags or changing the transfer rate, will not be permitted.

Test Using Libraries

The following demonstrates testing with xrpl.js.

Connect to Devnet

async function main() {
 const client = new xrpl.Client("wss://s.devnet.rippletest.net:51233");
 await client.connect();
 // … custom code goes here
 await client.disconnect();
}
main();

Delegate

const delegator = xrpl.Wallet.fromSeed("sDelegator...");
const delegatee = xrpl.Wallet.fromSeed("sDelegatee...");
const delegateTx = await client.autofill({
   TransactionType: "DelegateSet",
   Account: delegator.address,
   Authorize: delegatee.address,
   Permissions: [
       { Permission: { PermissionValue: "Payment" } },
       { Permission: { PermissionValue: "TrustSet" } },
   ],
});
const delegateResponse = await client.submitAndWait(delegateTx, { wallet: delegator });
console.log(delegateResponse);

Execute

const paymentTx = await client.autofill({
   TransactionType: "Payment",
   Account: delegator.address,
   Amount: xrpl.xrpToDrops("1"),
   Destination: "rDestination...",
   Delegate: delegatee.address,
});

const paymentResponse = await client.submitAndWait(paymentTx, { wallet: delegatee });
console.log(paymentResponse);

Feedback and Amendment Voting:

Validator operators and any interested developers in the community are encouraged to read more about the PermissionDelegation amendment and experiment with it on Devnet. Everyone is encouraged to provide feedback on the amendment and ask any questions.

To support the adoption of Permission Delegation on the XRPL, you can participate in the amendment voting process!

Refer to the Amendments Guide for a step-by-step overview of how to vote.

New to the XRPL? The guide also explains how the amendment process works and how you can contribute to the network’s evolution.

Permission Delegation Security Audit Findings

Yinyi Qian — Tue, 24 Jun 2025 20:16:05 +0000

Permission Delegation is among the latest features coming to XRPL, and will offer developers and token issuers enhanced security and operational flexibility through clear segregation of duties. As a powerful new feature, it is imperative that its codebase is reviewed by a professional third party. We have engaged the security experts at FYEO to perform a security audit of the Permission Delegation feature. We are pleased to report that all findings classified as High or Low severity have been fully remediated.

The full, detailed report from FYEO is available for public review here: Link.

Summary of Key Findings

The security audit identified four findings, which FYEO categorized by severity. Our engineering team has addressed each of them as follows:

Shadowed variable (High severity) - Remediated
Code optimization (Low severity) - Remediated
Concerns for Exchanges, Bridges, 3rd party tooling (informational) - Acknowledged
The DelegateSet SLE can be created empty (informational) - Remediated

Detailed Findings and Our Response

As background, FYEO notes that this new feature introduces new ledger object, ltDELEGATE, and transaction type, DelegateSet. The code checks for the presence of a delegate field, verifies that the delegated account holds the required permission, and confirms the signing key matches the delegate. Transaction fees will be deducted from the delegate’s account rather than the original account. This introduces complexity in ensuring the correct amount is charged for fees and that permissions are accurately verified.

Finding 1: Shadowed variable (High severity)

A function parameter was unintentionally "shadowed" by a local variable with the same name, which could nullify the intended filtering logic. The risk was that this could lead to incorrect behavior during transaction processing, potentially allowing unintended operations.

Remediation: We have resolved the issue by renaming the variables to ensure they are distinct.

Finding 2: Code optimization (Low severity)

FYEO identified areas where the code could be refactored for better performance, clarity, and long-term maintainability. This did not pose a security risk.

Remediation: We have addressed these suggestions by introducing a whitelist for permitted transaction types, correcting typos, and refactoring the logic for type conversion.

Finding 3: Concerns for Exchanges, Bridges, 3rd party tooling (Informational)

Permission Delegation changes how transaction fees are paid (deducted from the delegate account, not the originating account). Thus, external systems like exchanges, bridges, and tools must be updated to account for this new logic to avoid miscalculating balances. This is not a code defect but a necessary consideration for the ecosystem.

Acknowledgement: We acknowledge this finding and are committed to providing clear and explicit documentation for all ecosystem partners. As recommended, we will provide integration guidance with examples and proactively notify integrators about these logic changes.

Finding 4: The DelegateSet SLE can be created empty (Informational)

The code could create an empty delegate ledger object if one didn’t already exist and the incoming permission set was empty. While not a security threat, this could lead to unnecessary clutter on the ledger.

Remediation: We have addressed this by adding an additional check for empty permissions in the case where no delegate ledger object exists. This will prevent empty objects from being stored on the ledger.

DEV Community: Yinyi Qian