Permission Delegation Security Audit Findings

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.