XRPL will resubmit two amendments that failed security review in the next upgrade

xrpld 3.3.0 is expected to be released next week and contains five XRPL revisions

, two of which-Batch and Permission Delegation-had previously failed in a validator vote due to two different vulnerability categories, were fixed and resubmitted with a new revision number.

Two of the five revisions in this release have failed once before

XRPL has demonstrated its ability to support tokenized assets on a large scale. Now is the time to put these assets into practical use: global transfers, transactions, mortgages and settlements.

The upcoming xrpld 3.3.0 includes five revisions that bring XRPL closer to this goal...

--Jazzi Cooper (@jazzicoop) July 31, 2026

xrpld 3.3.0 is the next core server version of the XRP ledger and is expected to be released next week, bundled with five revisions: Confidential MPT, Batch, Permission Delegation, Sponsored Fees and Reserves, and Dynamic MPT. Jazzi Cooper, product leader for RippleX, announced the bundle on the X platform on July 31.

Two of these five items are not new proposals. Batch and Permission Delegation had previously passed XRPL's validator voting process and were withdrawn before activation due to the discovery of serious vulnerabilities. They are resubmitted to verifiers as patched replacement versions, rather than being reviewed for the first time as new code. This distinction is crucial for anyone who decides how to pay close attention to the voting process.

Batch: Found by AI vulnerability hunters during the voting process

Batch allows up to eight transactions from different accounts to be executed atomically: either all succeed or all fail-this is the mechanism behind the "delivery and payment" and "atomic settlement" use cases Cooper mentioned in his post. According to disclosures by the XRPL Foundation, Batch's internal transactions are designed to be unsigned and authorized to be delegated to external batch transactions that list the signers.

A vulnerability exists in this design. On February 19, 2026, security researchers Pranamya Keshkamat and Cantina's autonomous security tool Apex discovered a logical flaw in the signature verification code for this external transaction: an early exit condition that allowed signer checks to be satisfied without properly verifying the actual authorized internal transaction.

If this vulnerability is activated, an attacker could perform internal payment transactions on the target account without holding the private key until its reserves are exhausted, or initiate unauthorized AccountSet, TrustSet, or AccountDelete transactions.

When the vulnerability was discovered, Batch was still in the verifier voting stage, so no exploitation occurred on the main network. It is recommended that trusted verifiers of XRPL vote against the revision and released an emergency version of rippled 3.1.1 on February 23, marking Batch and related revisions fixBatchInnerSgs as unsupported. This prevents them from reaching the activation threshold in this form. According to the XRP Ledger Foundation's vulnerability disclosure report, Batch included in version 3.3.0 uses a different revision number BatchV1_1, removes early exit conditions, and adds additional authorization protection.

Permission Deletion: A more covert fee-consuming vulnerability

Permission Deletion solves another problem: allowing an account to delegate a limited range of transaction rights to another account without having to relinquish full signing rights-an on-chain primitive that institutions expect when separating vault custody from day-to-day transaction operations. This feature was actually deployed in rippled v2.6.1, but was disabled in September 2025.

The vulnerability is not related to signature verification, but involves the order of fee deductions. On XRPL, transactions that fail due to "tec" type errors will still be charged, while errors caught earlier before signature checks will not be charged. The original implementation of Permission Delegation would first check whether the entrusting account had relevant permissions before verifying the transaction signature.

This means that an attacker can submit a transaction with an invalid signature and the entrusting account does not have relevant rights. The transaction will fail due to a tec-type error, but the victim account will still be charged regardless of whether the signature is valid or not. According to the vulnerability disclosure report of the XRP Ledger Foundation, it was recommended that the UNL verifier vote "no" on the amendment, and multiple verifiers did; the repair plan re-adjusted the inspection order so that no fee deduction could be entered before signature verification was run. Wrong path. The replacement version uses its own new revision number PermissionDelegationV1_1 and abandons the original version.

Three other amendments do not disclose security incidents

Confidential MPT, Sponsored Fees and Reserves, and Dynamic MPT are three revisions in this bundle that are not related to previous security incidents.

Confidential MPT combines zero-knowledge proof with elliptic curve encryption to maintain the privacy of multi-purpose token balances and transfer amounts on the public ledger, while allowing designated parties, such as auditors or regulatory agencies, to verify details when needed.

Sponsored Fees and Reserves allow banks, issuers, or platforms to pay XRP transaction fees and reserve requirements for another account, allowing new users to operate on the network without first obtaining XRP.

Dynamic MPT allows issuers to specify exactly which token attributes (transfer fees, metadata, additional functions) can be changed later at the time of issuance, thereby avoiding a complete migration to new tokens.

Same threshold, same 80% of tests

The release of xrpld 3.3.0 does not activate anything. XRPL revisions need to have at least 80% trusted validator support and last for two weeks to take effect-a threshold that also applies to patched resubmissions and new proposals. The network's most recent activation revision, fixCleanup3_2_0, passed the threshold on July 29 with 30 of 35 participating verifiers (an 85.71% support rate), a recent reference point for the actual performance of "sufficient consensus" on the ledger.

Threshold required for revision status

fixCleanup3_2_0 (activated July 29, 2026) activated 85.71%(30/35 validators)

Batch (as BatchV1_1) Pending voting (in 3.3.0) 80% for two weeks

Permission Delegation (As PermissionDelegationV1_1) Pending vote (Medium 3.3.0) 80% lasts for two weeks

Confidential MPT, Sponsored Fees and Reserves, Dynamic MPT pending voting (In 3.3.0, first attempt) 80% lasts for two weeks

Timeline: History of Batch and Permission Delegation

Date Event

September 2025 Permission Delegation is disabled due to a fee consumption vulnerability due to check sequences related to signature verification.

Apex from Keshkamat and Cantina on February 19, 2026 marked a signature verification defect in Batch.

The February 23, 2026 emergency version rippled 3.1.1 marks Batch and fixBatchInnerSgs as unsupported.

fixCleanup3_2_0 was activated on July 29, 2026 with a validator support rate of 85.71%.

On July 31, 2026, Cooper announced the xrpld 3.3.0 bundle, including the patched BatchV1_1 and PermissionDelegation V1_1.

Xrpld 3.3.0 is expected to be released during the week of August 3 - 9, 2026; validator voting begins for all five revisions.

Verifiers who voted against will be given another opportunity

Once 3.3.0 is released, each amendment will still face the same threshold independently, rather than a bundled vote. Whether Batch and Permission Delegation can reach 80% support this time will reflect how much trust the fix has won; any of them is slower or more controversial than the three new revisions, which will be a true sign of residual caution.

As of this report, RippleX's official announcement on the bundle only exists in Cooper's X post; there are currently no technical details specific to 3.3.0, so a more complete specification is still worth reviewing once released.