Exchange Ranking
Top Exchanges
24h Volume Ranking
Popularity Ranking
Exchange BTC Balance
Proof of Reserves
Decentralized Exchanges
Funding Rate
Funding Heatmap
Liquidation Data
Max Pain
Long/Short Ratio
Whale L/S Ratio
Binance/Okex/Huobi L/S
Bitfinex Margin L/S
ETF Tracker
Solana ETF
XRP ETF
Hong Kong ETF
Bitcoin Treasuries
Crypto Reversal
Ethereum Reserves
HyperLiquid Wallet Analysis
Hyperliquid Whale Watch
Large Transactions
On-chain Movement
Bitcoin ROI
Stablecoin Market Cap
Options Analysis
News
Articles
Economic Calendar
Features
Wallet
Contract Calculator
Security
Collections
Watchlist
Following
XRP XRPL withdraws permission delegation function due to security vulnerability, and V1.1 version completed review
Recently, XRP Ledger (XRPL) decided to withdraw the "Permission Delegation" amendment after discovering a high-risk vulnerability during the testing phase. Currently, the reinforced V1.1 version has completed safety reviews and quality assurance (QA) inspections. This incident highlights the need for protocol level delegated functions to provide comprehensive security beyond basic features.
Reconstructing the authority delegation mechanism based on vulnerability reports
Authority delegation (i.e., XLS-75) allows one account to grant another account the right to perform specific operations on its behalf. The design is designed to limit the scope of authority rather than allow the entrusted party to gain control of the entire account.
J. Ayo Akinyele, head of RippleX engineering, said that the original V1.0 implementation was withdrawn before being launched on the XRPL main network due to a vulnerability reported by the Bug Bounty Project. Instead of directly patching this version, the team launched a V1.1 version that separated the original implementation from the hardened release.
A researcher named Shotes identified a severe level of problem involving irrevocable delegation of authority. In this vulnerability, the entrusted party can delete its own account and then recreate and retain any rights obtained from the original account, which cannot be revoked by the original account.
Changes to the V1.1 version are not limited to fixing a single vulnerability. It solves marginal cases involving the identity of the entrusted party and prevents new features such as Vault and Lending from being accidentally delegated. In addition, it fixed reserve accounting issues for delegated payments and closed a multi-signature path that could bypass delegated checks. At the same time, the revocation of authority is also strictly regulated.
The review also found a moderate-severity unsigned integer overflow vulnerability in the isDelegable function, which could cause malformed permission values to be interpreted as delegifiable transaction types. However, the researchers pointed out that unless the client acted maliciously, the issue had no practical impact.
Tests cover all levels of XRPL delegation.
The QA report released by Ramkumar SG on August 26 showed that a total of 179 special authority delegation tests were conducted, including 112 functional tests, 48 adversarial security tests, and 19 cross-functional tests. The tests also covered interactions with batch processing (Batch), confidential MPT, transaction queues, and multiple signatures.
XRP Ledger Operations stated that all identified issues have been fixed in V1.1 and verified by Cantina Security. Its QA team reported no regression errors in 5,088 tests and no open internal vulnerabilities classified as critical levels, concluding that the feature is ready for production use at the test submission level.
The privilege delegation feature was introduced in May 2025. In September 2025, it was marked as "unsupported" due to waiting for security fixes. It was renamed PermissionDelegationV1_1 in October 2025, and was supported again in June 2026.
As previously reported, the public dashboard built by developer Denis Angell has been tracking the adequacy of XRPL amendments on devnet before they were launched on the main network, including the privilege delegation amendment. For users and managed service providers, the expected functionality remains the same. As Akinyele said, V1.1 did not change the XLS-75 function itself, but changed the conditions for its activation.
