XRPL’s Next Upgrade Resubmits Two Amendments That Failed Security Review

MakeCryippreferred on

xrpld 3.3.0, expected next week, bundles five XRPL amendments. Two of them, Batch and Permission Delegation, already failed validator voting once, for two different bug classes, before being patched and resubmitted under new amendment IDs.

Two of five amendments in this release already failed once

xrpld 3.3.0, the next core-server release for the XRP Ledger, is expected next week and bundles five amendments: Confidential MPT, Batch, Permission Delegation, Sponsored Fees and Reserves, and Dynamic MPT. Jazzi Cooper, head of product at RippleX, announced the bundle in a post on X on July 31.

Two of those five aren’t new proposals. Batch and Permission Delegation have each already been through XRPL’s validator voting process once, and each was pulled after a critical bug was found before it could activate. They’re going back in front of validators as patched replacements, not as fresh code getting its first look. That distinction matters for anyone deciding how closely to watch the vote.

Batch: caught mid-vote by an AI bug hunter

Batch lets up to eight transactions from different accounts execute atomically: either all of them succeed or none do, the mechanism behind delivery-versus-payment and atomic settlement use cases Cooper’s thread cites. According to the XRPL Foundation’s disclosure, Batch’s inner transactions are intentionally left unsigned, with authorization delegated to an outer batch transaction that lists the signers.

That design is exactly where the bug lived. On Feb. 19, 2026, security researcher Pranamya Keshkamat and Cantina’s autonomous security tool, Apex, found a logic flaw in that outer transaction’s signature-validation code: an early-exit condition that meant the signer check could be satisfied without properly verifying who was actually authorizing the inner transactions.

Had it activated, an attacker could have executed inner Payment transactions against a victim account down to its reserve, or fired off unauthorized AccountSet, TrustSet, or AccountDelete transactions, without ever holding that account’s private keys.

Batch was still in its validator voting phase when the flaw surfaced, so nothing was exploited on mainnet. XRPL’s trusted validators were advised to vote it down, and on Feb. 23 the team shipped an emergency release, rippled 3.1.1, marking both Batch and a related amendment, fixBatchInnerSigs, as unsupported. That blocked either one from ever crossing the activation threshold in that form. The version going into 3.3.0 carries a different amendment ID, BatchV1_1, with the early-exit condition removed and additional authorization guards added, according to the XRP Ledger Foundation’s own vulnerability disclosure report.

Permission Delegation: a subtler fee-drain flaw

Permission Delegation works on a different problem: letting an account hand off narrowly scoped transaction permissions to another account without giving up full signing authority, the on-chain primitive institutions want for separating treasury custody from day-to-day trading operations. It actually shipped once, in rippled v2.6.1, before being disabled in September 2025.

Its bug wasn’t about signature verification at all. It was about fee-charging order. On XRPL, a transaction that fails with a “tec”-class error still gets charged a fee, while an error caught earlier in the process, before signature checks, doesn’t. Permission Delegation’s original implementation checked whether the delegate account actually had the relevant permission before it verified the transaction’s signature.

That meant an attacker could submit a transaction with an invalid signature and a permission the delegate didn’t have, watch it fail with a tec-type error, and still have a fee deducted from the victim account, regardless of whether the signature was ever valid. The XRP Ledger Foundation’s vulnerability disclosure report states that UNL validators were advised to vote “No” on the amendment, and several did so; the fix reorders the checks so no fee-charging error path can be reached before signature verification runs. The replacement carries its own new amendment ID, PermissionDelegationV1_1, deprecating the original.

The other three carry no disclosed security incident

Confidential MPT, Sponsored Fees and Reserves, and Dynamic MPT are the three amendments in the bundle not tied to a prior security incident.

• Confidential MPT combines zero-knowledge proofs with elliptic-curve encryption to keep Multi-Purpose Token balances and transfer amounts private on a public ledger, while still letting designated parties, auditors or regulators – verify details when required.
• Sponsored Fees and Reserves lets a bank, issuer, or platform cover another account’s XRP transaction fees and reserve requirement, so a new user doesn’t need to acquire XRP before they can do anything on the network.
• Dynamic MPT lets an issuer specify, at the moment of issuance, exactly which token properties (transfer fees, metadata, added capabilities) can still be changed later, avoiding a full migration to a new token.

Same threshold, same 80% test either way

Shipping xrpld 3.3.0 doesn’t activate anything. XRPL amendments require support from at least 80% of trusted validators, sustained for two consecutive weeks, before they take effect: the same bar applies to a patched resubmission as to a brand-new proposal. The network’s most recent activation, fixCleanup3_2_0, cleared that bar on July 29 with 30 of 35 participating validators, or 85.71% support, a recent reference point for what “enough consensus” has actually looked like on this ledger.

Timeline: how Batch and Permission Delegation got here

The same validators who voted these down get another chance

Once 3.3.0 ships, each amendment still faces that same bar independently: there’s no bundled up-or-down vote. Whether Batch and Permission Delegation clear 80% this time will say something about how much trust the fixes have earned back; a slower or more contested vote on either one, relative to the three new amendments, would be a real signal of that residual caution.

As of this reporting, RippleX’s own announcement of the bundle exists only as Cooper’s X post; there’s no dedicated release note yet on the XRP Ledger’s own blog laying out the technical detail for 3.3.0 specifically, so the fuller specification is still worth checking for once it’s published.

Zcash advanced its Ironwood network upgrade to improve performance and privacy, while Binance founder CZ proposed that a future quantum-security upgrade could freeze Satoshi Nakamoto’s dormant Bitcoin if quantum computing ever posed a threat to the network.