How XRPL validators quietly killed a silent exploit that could have drained victim accounts through transaction fees alone

RippleX expects the next version of the XRP Ledger's core server software, xrpld 3.3.0, as soon as next week. The release would put rewritten Batch and Permission Delegation amendments back into the validator process after authorization flaws led operators to block their predecessors before mainnet activation.

The rollout remains at the prerelease stage. xrpld 3.2.1 was still the latest stable release on Aug. 1, while official beta and release-candidate tags for 3.3.0 were public. A mainnet majority countdown had yet to begin for either replacement amendment.

RippleX product head Jazzi Cooper listed five proposed XRP Ledger features for 3.3.0: Confidential MPT, Batch, Permission Delegation, Sponsored Fees and Reserves, and Dynamic MPT. Cooper said all five would still require validator approval before activation.

Why validators stopped the original features

The original Batch amendment contained an authorization flaw that could have allowed an attacker to execute inner transactions for arbitrary victim accounts without their private keys, including unauthorized payments and ledger changes.

The official disclosure said researchers found the problem while the amendment was still in voting. Validators blocked activation, and no funds were put at risk. CryptoSlate reported on that intervention in February.

Permission Delegation exposed a different path to loss. An invalid offline-signed transaction could still charge a victim account a transaction fee before failing authorization, allowing repeated submissions to drain XRP through fees. XRPL's disclosure said the feature never activated on mainnet, and validators disabled support for the affected amendment.

The 3.3 development registry now marks BatchV1_1 and PermissionDelegationV1_1 as supported with default No votes. “Supported” in that registry means the server code understands the amendments; validator approval and activation remain separate steps.

XRPL amendments can activate only after compatible code ships and support remains above 80% of trusted validators for two weeks. If support falls to 80% or less before activation, the period restarts.

On Aug. 1, the validated mainnet Amendments object at ledger 105,997,300 contained no Majorities field and neither replacement among enabled amendments. The field records pending amendments that have crossed the majority threshold, establishing that no two-week clock was active. The ledger object only records active majority clocks, leaving exact subthreshold support undisclosed.

Activation would also impose an operational deadline. XRPL's amendment rules say a server that does not understand an activated amendment can become amendment blocked, losing the ability to determine ledger validity, process transactions, join consensus, or vote. If either replacement activates, operators will need compatible software regardless of how they personally voted.

XRPL's next measurable milestone is a stable release, followed by a sustained validator supermajority for either amendment. Until then, the rewrites remain proposals for features stopped before activation, with no mainnet exploit or loss to recover from.