A critical flaw in proposed XRP Ledger amendments could have let attackers drain user accounts through transaction fees. Validators intervened before mainnet activation, prompting a rewrite and delaying new features.
Developers and validators on the XRP Ledger have moved to address a serious security risk after discovering that two proposed protocol upgrades-Batch and Permission Delegation-contained flaws that could have exposed user accounts to unauthorized fee draining and transaction execution. The incident highlights the importance of validator oversight in blockchain governance, as the amendments were halted before they could be activated on the mainnet.
Amendment Flaws and Validator Response
According to RippleX, the next major release of the XRP Ledger's core server software, xrpld 3.3.0, is expected soon and will include rewritten versions of the Batch and Permission Delegation amendments. The original Batch proposal contained an authorization vulnerability that could have allowed attackers to initiate transactions from victim accounts without access to their private keys, potentially enabling unauthorized payments and ledger modifications. Meanwhile, the initial Permission Delegation amendment risked allowing attackers to repeatedly submit invalid offline-signed transactions, draining XRP from user accounts through transaction fees even if the transactions themselves failed authorization.
Activation Process and Security Safeguards
Both amendments were stopped before mainnet activation after researchers identified the issues during the validator voting phase. Validators-who play a critical role in approving protocol changes-blocked the flawed amendments, ensuring that no user funds were put at risk. The revised amendments, now labeled BatchV1_1 and PermissionDelegationV1_1, are included in the 3.3.0 prerelease but remain inactive by default. For any amendment to go live on the XRP Ledger, it must be supported by at least 80% of trusted validators for a continuous two-week period. As of August 1, no such majority had formed for the rewritten proposals, and the mainnet was still running xrpld 3.2.1 as the latest stable version.
Feature Roadmap and User Impact
RippleX product lead Jazzi Cooper outlined five features proposed for xrpld 3.3.0: Confidential MPT, Batch, Permission Delegation, Sponsored Fees and Reserves, and Dynamic MPT. All require separate validator approval before activation. If either the Batch or Permission Delegation amendments are eventually enabled, node operators will need to upgrade to compatible software or risk becoming amendment blocked-losing the ability to process transactions, participate in consensus, or vote on future changes. This operational safeguard is designed to prevent incompatible nodes from disrupting ledger integrity.
Market and Security Context
The XRP Ledger's amendment process is designed to balance innovation with network safety, but the recent incident underscores the risks of protocol upgrades. In a similar vein, other blockchain networks have faced critical vulnerabilities in the past, such as when Zcash addressed a major supply flaw that threatened protocol integrity-a case detailed in EgonCoin's coverage of Zcash's Ironwood upgrade and its impact on market confidence. For XRP Ledger users and developers, the current situation means that no new features from the affected amendments will be available until the validator community reaches consensus on the revised code.
As of August 1, 2026, the XRP Ledger's mainnet had not activated any of the rewritten amendments, and the network continued to operate on the 3.2.1 release. The amendment process requires a two-week supermajority among validators for activation, and the Amendments object on mainnet did not show any active countdown for the new proposals. This delay ensures that only thoroughly vetted changes reach production, but it also means that new features and fixes may take longer to reach users.
Amendment governance on the XRP Ledger is designed to minimize the risk of accidental forks or incompatible upgrades. When an amendment is activated, any server running outdated or incompatible software becomes amendment blocked, losing the ability to validate ledgers or participate in consensus. This mechanism helps maintain network integrity but places a burden on node operators to stay current with protocol changes. The process also demonstrates the importance of transparent review and community oversight in blockchain development, as even well-intentioned upgrades can introduce new risks if not carefully scrutinized.
