@xrpinsider: 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. #xrp #ripple #xrpl #xrparmy #xrpcommunity

XRP

Open In TikTok:

Region: US

Saturday 01 August 2026 16:09:03 GMT