XRPL Ships xrpld 3.3.0 With Confidential Transfers and Batching

The XRP Ledger shipped version 3.3.0 of xrpld, its reference server implementation, on 6 August, five days after the release was announced. "Version 3.3.0 of xrpld, the reference server implementation of the XRP Ledger protocol, is now available," the XRPL blog said that day, and the GitHub release tag confirmed the build. The release notes list ConfidentialTransfer and BatchV1_1 as enabled in the software, alongside an XLS-68 Sponsor feature and a change to Lending 1.1. Shipping the code is not switching it on. An amendment is a change to consensus rules that travels inside the server software but stays inactive until validators approve it, and each needs 80% of trusted validators behind it for two consecutive weeks. The amendments named in the 1 August announcement all default to a "No" vote, so nothing activates by inertia.

Five amendments in voting, or six

The announcement and most of the coverage that followed counted five amendments:

Batch (BatchV1_1): bundles up to eight cross-account transactions atomically.
Permission Delegation (PermissionDelegationV1_1): lets one account act for another under granted permissions.
Confidential MPT: hides balances and transfer amounts using zero-knowledge proofs.
Sponsored Fees and Reserves: lets an institution cover its users' fees and reserve requirements.
Dynamic MPT: lets an issuer modify a token's properties after issuance.

Two outlets say otherwise. Crypto Economy's tally, put out the day after the release, does not match the announcement's five: it counted six amendments in validator voting, naming Confidential Transfers, Batch, Permission Delegation, Sponsor, Dynamic MPT and fixCleanup. BraveNewCoin also put the number at six. The extra entry is fixCleanup, absent from the five-amendment lists. The published counts do not reconcile, and we could not establish which is definitive.

Second attempts at features researchers broke

Batch and Permission Delegation are second attempts at features pulled from earlier builds after security researchers broke them. Batch reached validator voting in February 2026 before researcher Pranamya Keshkamat and the audit firm Cantina found a signature-validation flaw that would have let an attacker execute transactions from any account without holding its keys; Ripple disabled the amendment in version 3.1.1. The rewrite redesigns the signer-validation logic to correct a loop-exit error, the point at which the check stopped iterating too early. Permission Delegation failed differently. It was disclosed vulnerable in September 2025, when it emerged that one account could charge its transaction fees to another and drain that balance. Its rewrite reorders the permission checks so fees are no longer deducted before a signature has been verified — the sequence, not the cryptography, was the defect.

Five retirements and a move to C++23

The same release retired five amendments whose behavior has long since become permanent: Clawback, fixDisallowIncomingV1, fixInnerObjTemplate, fixNFTokenReserve and fixUniversalNumber. RippleX engineer Mayukha Vadari called the removal "purely a codebase cleanup", with the rules unchanged and only the pre-amendment conditional code paths taken out; ledger rules allow retirement two years after an amendment activates on mainnet. The codebase also moved to C++23, and the release was reported to cut memory use by 10% to 15% and speed node synchronization. Pre-release testing by the audit platform Sherlock turned up 2 critical, 6 high, 29 medium and 59 low severity issues, all resolved before launch, and the bug bounty paid out 309,000 RLUSD. The exercise fits a wider move to put large open-source codebases through systematic adversarial review before a release rather than after one.

The vote now waits on upgrades

Shipping the binary starts the clock. It does not stop it. A validator cannot signal on an amendment its software does not carry, and support that slips below 80% resets the two-week count, so the pace at which operators upgrade to 3.3.0 is the practical constraint. Rewrites of withdrawn features may move more slowly still, since the operators voting on them watched the originals get pulled. Other ledgers have moved the same decision on-chain differently, with Cardano's Van Rossem fork the first upgrade it ratified entirely by on-chain vote. Two questions stay open here: whether the count settles at five or six as voting is reported, and whether the two rewritten features complete the trip back from disabled to active.