The XRP Ledger software roadmap is currently split between a small security-focused release and a larger, still-unreleased milestone. As of Aug. 1, 2026, xrpld 3.2.1 remained the latest available version, while the 3.3.0 milestone listed 122 items and had no release date.

That gap is important for validators, exchanges, and developers planning upgrades. The stable branch is centered on hardening validator operations, while the 3.3.0 branch collects a wider set of protocol and operational changes that are at different stages of readiness and, in several cases, would still need network approval before becoming active.

3.2.1 focuses on validator security

The current release, xrpld 3.2.1, is positioned as a targeted update rather than a broad feature expansion. Its main purpose is to address validator manifest propagation issues and reduce risk from messages sent by untrusted peers.

That makes 3.2.1 the practical upgrade target for operators today. In contrast, the 3.3.0 milestone represents work in progress across many parts of the XRP Ledger codebase rather than a finalized release package.

BatchV1_1 replaces the earlier batch approach

One of the most notable items attached to 3.3.0 is BatchV1_1, which replaces a withdrawn batch amendment. The feature keeps the XLS-56 model of grouping multiple transactions under defined execution rules, but changes how signatures are handled.

According to the source material, the newer design corrects inner-signature validation instead of depending on the older fixBatchInnerSigs approach. The result is presented as a safer path for grouped transactions, but it remains part of the unreleased 3.3.0 milestone rather than the current stable version.

Code in 3.3.0 would not mean immediate activation

Even if functionality is included in a software release, that does not automatically switch it on across the XRP Ledger. Amendments still require backing from more than 80% of trusted validators for two weeks before activation.

That distinction is especially relevant for teams assessing batch transaction support or other upcoming changes. Availability in code, inclusion in release notes, and live activation on the network are separate steps.

Privacy and fee sponsorship remain in development

The 3.3.0 branch also includes ConfidentialTransfer, based on XLS-96. The proposal would conceal multi-purpose token balances and transfer amounts using EC-ElGamal cryptography and zero-knowledge proofs, while still allowing disclosure to be limited to authorized issuers, auditors, or other designated entities.

Despite being merged into the branch, official documentation still describes ConfidentialTransfer as in development, with a default 'No' vote in stable releases. Sponsored Fees and Reserves, tracked as XLS-68, is in a similar position. That proposal would let businesses, apps, or issuers pay another account's transaction fees or reserve requirements, while the sponsored account keeps control of its keys and account. The source notes that this feature is not active in 3.2.1 and its presence in a final 3.3.0 release is not yet confirmed.

Broader reliability work is queued next

Beyond headline amendments, the 3.3.0 milestone contains a broader reliability and consistency push. The listed items include delegated-transaction filtering for account_tx, numerical rounding fixes, pseudo-account deletion invariants, aligned freeze checks, and automated market maker safeguards tied to vault shares.

Taken together, those changes suggest that 3.3.0 is being shaped as a wider maintenance and feature release rather than a single-purpose upgrade. For now, though, the confirmed position is unchanged: 3.2.1 is the latest stable xrpld release, and any 3.3.0 features will still depend on the eventual release notes and, where required, validator approval before they become active on the network.

Source: Coin Edition