- xrpld 3.2.1 fixes validator manifest risks, while 3.3.0 expands protocol features.
- BatchV1_1 restores grouped transactions with corrected inner-signature validation.
- Confidential transfers and sponsored fees are under development and not active.
The next XRP Ledger software cycle is separating a focused security repair from a broader set of protocol changes for validators, exchanges, and application developers. As of August 1, 2026, xrpld 3.2.1 remained the latest version, while the 3.3.0 milestone showed 122 items without a release date.
That status creates a distinction for validators, exchanges, and developers preparing a 2026 xrpld upgrade plan. Essentially, version 3.2.1 strengthens node resilience by addressing validator manifest propagation problems and limiting risks from untrusted peer messages.
By contrast, XRPL 3.3.0 vs. 3.2.1 offers a broader package that includes transaction batching, privacy tools, sponsorship functions, and operational safeguards.
BatchV1_1 Brings Safer Grouped Transactions to XRPL 3.3.0
Version 3.2.1 was released on July 31 as a targeted response to risks in the validator manifest. It bounded the untrusted manifest cache, rejected oversized validator manifests, and limited the number of untrusted manifests carried in peer messages. These changes reduced exposure to malformed or excessive data without introducing broader protocol functions.
Against that narrower security focus, the first major difference in the 3.3.0 milestone is BatchV1_1, which replaces the withdrawn batch amendment. XRPL previously disabled Batch and fixBatchInnerSigs in version 3.1.1 after researchers found an inner-transaction authorization flaw. Because inner transactions lack independent signatures, certain conditions could have allowed unauthorized instructions to execute.
To address that weakness, the 3.3.0 development milestone includes the merged BatchV1_1 implementation and amendment-enabling code. The design retains the XLS-56 approach of combining several transactions under defined execution rules. However, it adds corrected signature validation instead of relying on the obsolete fixBatchInnerSigs amendment.
| Comparison Area | xrpld 3.2.1 | Expected xrpld 3.3.0 |
| Release status | Latest stable production version | Development milestone with 122 completed items |
| Main purpose | Validator manifest security hotfix | Broader protocol and reliability update |
| Batch transactions | The withdrawn batch remains disabled | BatchV1_1 adds redesigned authorization checks |
| Confidential transfers | Not supported | Development code supports confidential transfer. |
| Sponsored fees | Not active | Sponsor-related work remains under development |
XRPL 3.3.0 Features Still Require Validator Approval
The second difference concerns activation. Software support does not automatically activate XRP Ledger amendments on Mainnet. An amendment must maintain support from more than 80% of trusted validators for two weeks. Therefore, operators must separate code availability from network activation when reviewing the XRPL batch transactions bug fix.
Confidential Transfers Add Privacy Tools to XRPL 3.3.0
The third difference is ConfidentialTransfer, based on XLS-96. Merged development work enables the amendment inside the 3.3.0 branch. The proposal would hide multi-purpose token balances and transfer amounts through EC-ElGamal cryptography and zero-knowledge proofs.
Authorized issuers, auditors, or designated entities could still receive access to disclosure. That Confidential MPT XRP Ledger structure targets regulated tokenized assets while reducing public exposure of transaction details. Nevertheless, official documentation still lists ConfidentialTransfer as “In Development,” while the stable release maintains a default “No” vote.
Sponsored Fees Could Remove XRP Onboarding Barriers
The fourth difference involves the Sponsored Fees and Reserves amendment, also called Sponsor or XLS-68. It would let businesses, applications, or issuers cover another account’s transaction fees, reserve requirements, or both. Sponsored users would still control their accounts and private keys.
Related: XRP Community Shifts Focus to XRPL Utility Ahead of Major Upgrades
This approach could reduce onboarding barriers as new users would not immediately require XRP for fees or ledger-object reserves. Still, Sponsor remains under development and is not active in 3.2.1. Its inclusion in the final 3.3.0 package also remains unconfirmed until official release notes define the complete feature set.
XRPL 3.3.0 Expands Ledger Reliability and Safeguards
Beyond these proposed features, the fifth difference is the broader range of operational improvements. The 3.3.0 milestone includes delegated-transaction filtering for account_tx, numerical rounding fixes, pseudo-account deletion invariants, aligned freeze checks, and AMM safeguards involving vault shares.
Together, these changes extend the upgrade beyond individual amendments into wider ledger reliability and consistency improvements. Accordingly, XRPL 3.3.0 vs. 3.2.1 represents a shift from defensive maintenance to broader protocol capabilities.
Yet 3.2.1 remains the stable target for operators. Moreover, Ripple’s rotated package-signing key must be trusted for automatic upgrades. Meanwhile, testing should remain separate until signed packages and final notes confirm the XRP Ledger 3.3.0 release.
Disclaimer: The information presented in this article is for informational and educational purposes only. The article does not constitute financial advice or advice of any kind. Coin Edition is not responsible for any losses incurred as a result of the utilization of content, products, or services mentioned. Readers are advised to exercise caution before taking any action related to the company.
