Validators blocked activation of two XRPL amendments before they reached the mainnet, and now RippleX is rolling out a fix. The next version of the core server software, xrpld 3.3.0, is expected as soon as next week. It includes rewritten versions of the Batch and Permission Delegation amendments, along with several other features.
Why the original amendments were blocked
The original Batch amendment had an authorization flaw. An attacker could have executed inner transactions for arbitrary victim accounts without their private keys. That meant unauthorized payments and ledger changes were possible. The original Permission Delegation amendment had a different problem: an invalid offline-signed transaction could still charge a victim account a transaction fee before failing authorization. Repeated submissions could drain XRP through fees. Validators caught both issues before activation, so no funds were ever at risk.
What's in the new amendments
The rewritten amendments are called BatchV1_1 and PermissionDelegationV1_1. They're part of xrpld 3.3.0, which also includes Confidential MPT, Sponsored Fees and Reserves, and Dynamic MPT. In the 3.3 development registry, the rewritten amendments are marked as supported with default No votes. That means validator approval and activation remain separate steps — the code is ready, but the network still has to decide.
The activation process and timeline
XRPL amendments can activate only after compatible code ships and support stays above 80% of trusted validators for two weeks. If support drops to 80% or less before activation, the two-week clock restarts. As of Aug. 1, the validated mainnet Amendments object at ledger 26,000,000 contained no Majorities field. That means no two-week clock was active for either replacement amendment. If either replacement does activate, operators will need compatible software to avoid becoming amendment blocked. The question now is whether validators will vote yes, and whether operators will upgrade in time.
