RippleX expects xrpld 3.3.0, the XRP Ledger's next core server release, as soon as next week, carrying rewritten versions of the Batch and Permission Delegation amendments. Validators blocked the original amendments before mainnet activation after separate authorization flaws surfaced, one of which could have drained victim accounts through transaction fees alone. Either rewrite still needs validator support above 80% sustained for two weeks once compatible code ships.
RippleX expects xrpld 3.3.0 to ship as soon as next week, the next core server release for the XRP Ledger blockchain, reintroducing rewritten Batch and Permission Delegation amendments into the validator process. As of Aug. 1, xrpld 3.2.1 remained the network's latest stable release, though beta and release-candidate tags for 3.3.0 were already public. RippleX product head Jazzi Cooper listed five proposed features for the release — Confidential MPT, Batch, Permission Delegation, Sponsored Fees and Reserves, and Dynamic MPT — and said each would still require validator approval before activation.
Why validators stopped the originals
The original Batch amendment carried a flaw that could have let an attacker execute inner transactions for arbitrary victim accounts without their private keys, including unauthorized payments and ledger changes. Researchers reportedly found the issue while the amendment was still in voting, and validators blocked activation before any funds were put at risk.
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, so repeated submissions could drain XRP through fees alone. The feature never activated on mainnet, and validators disabled support for it once the flaw surfaced.
The 3.3 development registry now marks the rewrites, BatchV1_1 and PermissionDelegationV1_1, as supported with default No votes — meaning the server code understands them, while validator approval and activation remain separate steps.
A validator supermajority still stands between here and activation
XRPL amendments activate only after compatible code ships and support from more than 80% of trusted validators holds for two weeks straight; if support drops to 80% or below before that window closes, the countdown restarts. On Aug. 1, the validated mainnet Amendments object at ledger 105,997,300 carried no Majorities field and listed neither replacement among enabled amendments, indicating no two-week clock had begun for either rewrite.
The stakes reach beyond the two amendments themselves. Under XRPL's rules for the network's consensus mechanism, a server that fails to recognize an amendment that does activate can become "amendment blocked," losing the ability to determine ledger validity, process transactions, join consensus, or vote — a risk that applies to any operator regardless of how they voted, if either rewrite activates this time.
Source: CryptoSlate
Trading involves risk.