XRP Ledger developers released xrpld version 3.3.0 on Aug. 6, moving several protocol changes closer to possible mainnet activation.\u00a0<\/p>\n
\n Summary<\/span>\n <\/p>\n <\/p>\n The official GitHub release<\/a> confirms work on ConfidentialTransfer, BatchV1_1, Sponsor and DynamicMPT, alongside fixes and other protocol changes. The software release itself does not activate those features on the network.<\/p>\n The distinction matters because some reports describe six upgrades as already live. Under the XRP Ledger amendment process, new protocol features require validator support before activation. An amendment must maintain more than 80% support from trusted validators for two continuous weeks before taking effect.<\/p>\n <\/p>\n ConfidentialTransfer is designed to add privacy for Multi-Purpose Tokens, or MPTs. XRPL documentation<\/a> says the amendment uses cryptography to shield individual balances and transfer amounts while preserving mechanisms that let authorized parties, including issuers or auditors, verify information needed for compliance.<\/p>\n The feature remains subject to amendment activation, so private MPT transfers should not yet be described as active on XRPL mainnet.<\/p>\n BatchV1_1 is another major component. The XLS-56 standard<\/a> allows multiple transactions to be packaged and processed together, including transactions involving different accounts. Atomic execution can help settlement workflows where several actions must succeed together rather than leaving one leg completed while another fails.<\/p>\n Batch has an important history. An earlier version was disabled before mainnet activation after a security issue was discovered in transaction-signing logic. The XRPL Foundation later moved toward BatchV1_1 as the corrected replacement. As previously reported in XRPL security coverage<\/a>, developers have increased formal review around recent upgrades.<\/p>\n Permission Delegation followed a similar path. XRPL disclosed in September 2025 that a bug in the earlier amendment could have allowed an unauthorized transaction to charge fees to another account under specific conditions. Validators were advised to vote no, and the vulnerable feature never activated. PermissionDelegationV1_1 was developed as its replacement.<\/p>\n The revised concept lets an account grant defined transaction permissions without handing over its main private key, supporting operational wallets with limited authority.<\/p>\n Sponsor, based on XLS-68, is designed to let another account cover transaction fees or reserve requirements while the user keeps control of the account and keys. The feature could let applications onboard users without requiring them to acquire XRP solely to meet network costs. The XLS-68 proposal<\/a> explicitly supports fee and reserve sponsorship while preserving user key control.<\/p>\n DynamicMPT targets token issuers. The XLS-94 proposal<\/a> lets issuers designate selected MPT properties as mutable when creating a token, then update those permitted fields later. The standard is intended to accommodate changing business or compliance requirements without making every token property freely editable.<\/p>\n\n
![\"XRP](\"https:\/\/media.crypto.news\/2026\/08\/image-37-944x1024.webp\")
XRP Ledger 3.3.0 adds privacy and atomic transaction tools<\/strong><\/h2>\n
Revised features follow earlier security findings<\/strong><\/h2>\n
Sponsor and DynamicMPT target institutional onboarding<\/strong><\/h2>\n