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
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.
XRPL has already proven it can support tokenized assets at scale. Now it’s time to put these assets to use: global transfers, trading, collateralizing, and settling.
The upcoming release of xrpld 3.3.0 includes five amendments that move XRPL significantly closer to that goal.…
— Jazzi Cooper (@jazzicoop) July 31, 2026
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 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 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.
Confidential MPT, Sponsored Fees and Reserves, and Dynamic MPT are the three amendments in the bundle not tied to a prior security incident.
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.
AmendmentStatusThreshold neededfixCleanup3_2_0 (activated July 29, 2026)Live85.71% (30/35 validators)Batch (as BatchV1_1)Pending vote in 3.3.080% sustained 2 weeksPermission Delegation (as PermissionDelegationV1_1)Pending vote in 3.3.080% sustained 2 weeksConfidential MPT, Sponsored Fees and Reserves, Dynamic MPTPending vote in 3.3.0, first attempt80% sustained 2 weeksOnce 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.
