{"id":24434,"date":"2026-08-06T04:49:49","date_gmt":"2026-08-06T04:49:49","guid":{"rendered":"https:\/\/nft.runfyers.com\/index.php\/2026\/08\/06\/xrp-ledger-upgrade-brings-back-features-once-pulled-over-critical-bugs\/"},"modified":"2026-08-06T04:49:49","modified_gmt":"2026-08-06T04:49:49","slug":"xrp-ledger-upgrade-brings-back-features-once-pulled-over-critical-bugs","status":"publish","type":"post","link":"https:\/\/nft.runfyers.com\/index.php\/2026\/08\/06\/xrp-ledger-upgrade-brings-back-features-once-pulled-over-critical-bugs\/","title":{"rendered":"XRP Ledger upgrade brings back features once pulled over critical bugs"},"content":{"rendered":"

<\/p>\n

\n

XRP Ledger<\/b> is preparing for the <\/span>XRPLD 3.3.0 <\/b>release, which Jazzi Cooper, Head of Product at RippleX, announced on July 31, 2026, with an expected target release in the following week. This release will introduce 5 new amendments to the voting schedule, including Confidential MPT, Batch, Permission Delegation, Sponsored Fees and Reserves, and Dynamic MPT. The goal is to expand XRPL\u2019s support for tokenized assets, ranging from private transactions and batch settlement to transaction delegation, fee sponsorship, and post-issuance token configuration updates.<\/span><\/p>\n

Notably, two of these features, <\/span>Batch and Permission Delegation<\/b>, were previously removed from the mainnet roadmap after critical bugs were discovered during the voting phase or in non-production environments.<\/span><\/p>\n

\n

XRPL has already proven it can support tokenized assets at scale. Now it\u2019s time to put these assets to use: global transfers, trading, collateralizing, and settling.<\/p>\n

The upcoming release of xrpld 3.3.0 includes five amendments that move XRPL significantly closer to that goal.\u2026<\/p>\n

\u2014 Jazzi Cooper (@jazzicoop) July 31, 2026<\/a><\/p>\n<\/blockquote>\n

A Cleanup Upgrade With Security Baggage<\/b><\/h2>\n

XRPLD 3.3.0 continues a series of maintenance upgrades that XRPL executed throughout 2026. Before this, <\/span>v3.1.1<\/b>, released on February 23, disabled Batch and fixBatchInnerSigs after a critical bug was discovered.<\/span><\/p>\n

On May 14, the company released <\/span>V3.1.3<\/b>, introducing fixCleanup3_1_3 to address bugs in NFTs, Permissioned Domains, Vaults, Lending Protocol, and MPTs. By <\/span>v3.2.0<\/b> on June 15, XRPL renamed the core server from rippled to XRPLD and added fixCleanup3_2_0 for vaults, lending, permissioned DEX, MPTs, and permissioned domains.<\/span><\/p>\n

These steps reflect efforts to re-establish the network\u2019s security discipline before re-launching major features.<\/span><\/p>\n

The Features Coming Back Into Focus<\/b><\/h2>\n

Confidential MPT<\/b> adds a privacy layer to Multi-Purpose Tokens, enabling the hiding of balances and transfer amounts on the public ledger while maintaining mechanisms for designated issuers or auditors to view transaction data. This is the aspect RippleX emphasizes for financial institutions that require transaction privacy while maintaining auditability.<\/span><\/p>\n

Batch allows grouping up to 8 transactions into a single ledger. Transactions can be processed under various execution modes, such as all-or-nothing (all succeed), single success, execution until an error occurs, or independent execution. This paves the way for workflows like delivery-versus-payment, atomic settlement, or multi-step transactions that must be bundled together.<\/span><\/p>\n

Permission Delegation allows an account to delegate a narrow scope of permissions to another account to execute transactions on its behalf. For financial institutions, this is a familiar model: one party holds custody, while another operates transactions, but permissions are restricted by action type.<\/span><\/p>\n

Sponsored Fees and Reserves allow a sponsor\u2014such as a bank, issuer, or platform\u2014to pay transaction fees and account reserves on behalf of another user. Dynamic MPT allows certain properties of an MPT to be updated post-issuance, rather than fixing the token completely from day one.<\/span><\/p>\n

The Bug That Forced A Reset<\/b><\/h2>\n

According to a vulnerability disclosure from XRPL Labs, on February 19, 2026, Pranamya Keshkamat and Cantina AI\u2019s security tool, Apex, discovered a logic flaw in the signature check mechanism of the Batch amendment.<\/span><\/p>\n

In the Batch design, inner transactions do not carry their own signatures. Delegation is handled at the outer transaction level via a list of batch signers. The bug resided in a signer check loop: when encountering an account that did not yet exist on the ledger but possessed a signing key matching that account, the system could conclude successfully prematurely and skip the remaining signers.<\/span><\/p>\n

If Batch had been activated before the bug was discovered, an attacker could have executed a Payment from a victim\u2019s account without requiring their private key. The XRPL Labs disclosure also highlighted the potential for unauthorized execution of AccountSet, TrustSet, or even AccountDelete. The bug was discovered during the voting phase before becoming active on the mainnet, meaning no user funds were ever at real risk.<\/span><\/p>\n

Permission Delegation also had its own history. A disclosure from September 2025 indicated that a bug in this feature could cause an account to have transaction fees unauthorizedly deducted under certain conditions. This feature was also not active on the mainnet when the bug was found, and validators were advised to vote No. A corrected version was later included in a replacement roadmap.<\/span><\/p>\n

Validators Face The Real Deadline<\/b><\/h2>\n

The amendments in XRPL 3.3.0 will not automatically activate simply because the software is released. On XRPL, changes impacting transaction processing must pass through the amendment process. An amendment requires maintaining over <\/span>80% support <\/b>from trusted validators for two weeks to be permanently activated.<\/span><\/p>\n

This point is crucial as Jazzi Cooper also emphasized that amendments only activate after approval by validator voting. For validators, early upgrading provides them with the code to understand the new rules if the amendments pass. For node operators, exchanges, API providers, or applications building on XRPL, lagging behind on updates could lead to an \u201camendment-blocked\u201d state when the network transitions to the new rule set.<\/span><\/p>\n

According to data on xrpscan, the XRP Ledger has <\/span>546 running nodes.<\/b> Among them, 334 nodes run rippled-3.2.1 (approximately 61%), 113 nodes run rippled-3.2.0 (nearly 21%), and 58 nodes remain on rippled-3.1.3 (nearly 11%).<\/span><\/p>\n