Ripple has introduced one of the most consequential privacy proposals in XRP Ledger’s recent development cycle: Confidential MPT, a new amendment designed to hide token balances and transfer amounts while keeping account identities visible on-chain.
The feature is included in XRP Ledger version 3.3.0, released on August 6, 2026, but it is not yet active on the mainnet.
Activation requires at least
The central distinction is what the amendment chooses to keep visible.
Under Confidential MPT, sender and receiver addresses remain public.
The token being transferred is visible.
The transaction itself remains visible.
What third parties cannot see are the transfer amount and the resulting balances.
That makes the system very different from privacy coins that attempt to conceal the full transaction graph.
For institutions, this narrower model may be easier to reconcile with compliance requirements because counterparties remain traceable.
The balances are stored as encrypted values
Instead of keeping token balances as plaintext values, Confidential MPT would store them using EC-ElGamal encryption.
When a user transfers a token, the amount is encrypted.
The sender’s and recipient’s new balances also remain encrypted.
Validators can still verify that the transaction is valid without seeing the underlying values.
That is the key function of the zero-knowledge proof system embedded in the proposal.
Multiple cryptographic tools work together
The design uses several cryptographic components rather than relying on one proof mechanism.
Each confidential transfer includes a sigma proof that binds the relevant ciphertexts under a single Fiat-Shamir challenge.
It also uses Pedersen commitments for the transfer amount and remaining balance.
An aggregated Bulletproof range proof then confirms that balances do not become negative and that supply remains consistent.
A linkage proof connects the encrypted transfer amount with the range-proof commitment.
This is intended to prevent a sender from proving one amount while actually transferring another.
The architecture addresses token-creation attacks
Without those links between proofs, a malicious participant could theoretically produce a valid range proof for one value while encrypting a different amount in the actual transfer.
That could create an opening for unauthorized token creation.
The design also requires proof of knowledge when an account registers its confidential-transfer key.
This is intended to prevent rogue-key attacks in which a malicious account creates a public key related to another user’s key in order to manipulate aggregate ciphertexts.
Validators do not need access to the hidden values
The verification process is designed so that validators can enforce the rules without decrypting balances.
According to the source, a single confidential-transfer proof adds roughly 1.5 kilobytes to the transaction.
The use of Bulletproofs keeps verification costs logarithmic in relation to the proof range.
The stated objective is to add confidentiality without making transaction verification impractically expensive.
Privacy is controlled by the issuer
Another major difference from traditional privacy coins is who decides whether privacy applies.
Confidential MPT is opt-in at the issuer level.
A token issuer decides at creation whether balances and transfers will be encrypted.
Individual users cannot enable or disable privacy themselves.
That means every holder of a particular confidential MPT follows the same visibility rules.
The privacy policy is therefore embedded in the asset design rather than selected transaction by transaction.
Authorized parties can still decrypt information
Issuers can designate specific entities that are allowed to access hidden balances and transfer amounts.
Those parties could include auditors, regulators or compliance teams.
This feature is central to the institutional case for Confidential MPT.
The system does not attempt to make transaction values permanently inaccessible.
Instead, it creates selective disclosure controlled by the issuer.
Existing freeze and clawback functions also remain available.
The model differs sharply from Monero
Monero uses privacy by default.
Its transactions hide sender, receiver and amount.
Users cannot opt out.
The source notes that after the FCMP++ upgrade in early 2026, reliable transaction tracing at scale became even more difficult.
XRPL takes the opposite approach.
It preserves the entire address graph.
Observers can still see that one account sent a token to another.
They simply cannot see the amount.
Zcash uses yet another model
Zcash allows users to choose whether to use shielded transactions.
That creates a different privacy structure.
Shielded transactions can conceal sender, receiver and value.
But because privacy is optional at the user level, the decision to use a shielded transaction can itself reveal information.
Confidential MPT avoids that particular pattern by making privacy uniform for the asset.
The issuer decides once, rather than each user deciding independently.
The proposal arrives as tokenized assets expand on XRPL
The amendment is not being introduced into an empty ecosystem.
The source states that approximately $1.38 billion in tokenized real-world assets are already on XRP Ledger.
After excluding RLUSD’s roughly $845.7 million contribution, more than $530 million in other tokenized assets remain.
Ondo Finance accounts for about $212.6 million.
VERT Capital represents approximately $116.1 million.
Archax contributes around $55.4 million.
Institutional issuers have a direct reason to want privacy
For issuers of tokenized funds and securities, public balances can reveal sensitive commercial information.
Subscriptions, redemptions and rebalances can be observed in real time by competitors and other market participants.
As tokenized positions become larger, that visibility becomes more consequential.
Confidential MPT gives issuers a way to hide those amounts while preserving a public transaction record.
That is the core institutional use case Ripple appears to be targeting.
Version one remains limited to direct transfers
The first version of the proposal does not provide privacy across every XRPL function.
It supports direct Multi-Purpose Token payments between accounts.
Decentralized exchange activity is excluded.
Escrow is excluded.
Payment channels are excluded.
That means secondary-market activity involving these systems would remain transparent unless later versions extend the privacy model.
Sponsor may be just as important as Confidential MPT
Another amendment in version 3.3.0 could have immediate implications for institutional onboarding.
Sponsor, known as XLS-68, allows third parties to pay transaction fees and reserve requirements for users.
Today, accounts on XRP Ledger need XRP to satisfy reserves and pay fees.
That creates friction for institutions onboarding customers who may not want to acquire a crypto asset just to use a tokenized financial product.
Sponsor is designed to remove that requirement from the user experience.
Institutions could absorb blockchain costs themselves
Under the proposed model, a bank, issuer or platform could pay fees on behalf of customers.
The sponsor could co-sign individual transactions or use a prefunded structure.
Users would retain control of their accounts and private keys.
This means an investor could interact with a tokenized fund without ever purchasing XRP.
For enterprise deployment, that simplifies onboarding substantially.
Confidential MPT and Sponsor form a broader institutional stack
The combination is significant.
An issuer could theoretically create a token with hidden balances, allow regulated parties to decrypt the values, and sponsor all transaction fees for end users.
The public chain would remain accessible.
The token itself could be private at the balance level.
The customer would not need to understand XRP or transaction-fee mechanics.
This is a materially different user experience from a typical public blockchain application.
BatchV1_1 adds atomic settlement
Another proposal, BatchV1_1, allows up to eight transactions across different accounts to execute as one atomic group.
Either all transactions succeed or the whole batch fails.
The institutional use case is delivery-versus-payment.
A security transfer and cash payment could be completed together rather than relying on separate settlement steps.
That reduces counterparty risk.
The batch proposal had to be rewritten after a critical flaw
The current version replaces an earlier Batch implementation.
A $550,000 Sherlock security contest identified 96 vulnerabilities across the five proposed amendments.
Among them were two critical issues.
One involved signature validation in the original Batch code and could have allowed unauthorized transactions.
The revised BatchV1_1 addresses those findings.
Permission Delegation also required fixes
Another critical issue affected Permission Delegation.
The bug could have allowed repeated fee charges to silently drain balances.
The proposal was also revised.
The broader point is that none of these amendments moved directly from development into activation.
They went through external review before being presented for mainnet approval.
Regulation remains the unresolved question
The technical design attempts to preserve compliance access, but regulators have not yet fully defined how issuer-controlled confidential tokens should be treated.
In Europe, travel-rule requirements generally require sender, receiver and amount information to accompany certain transfers.
Confidential MPT keeps sender and receiver visible but encrypts the amount.
Whether designated access for regulators is sufficient remains untested in practice.
Europe could become an important test case
The source notes that EU anti-money-laundering rules are expected to restrict privacy coins at licensed exchanges by July 2027.
Those rules target assets where authorities cannot obtain transaction information.
Confidential MPT may fall outside that category because authorized entities can access the encrypted data.
However, that legal interpretation has not yet been formally tested.
U.S. regulators have also acknowledged legitimate privacy use cases
A U.S. Treasury report published in March 2026 recognized legitimate commercial and financial privacy applications for blockchain technology.
That supports the broader idea that privacy itself is not necessarily incompatible with regulation.
The unresolved issue is whether the specific design of Confidential MPT satisfies future statutory and supervisory requirements.
Adoption is not guaranteed
The strongest challenge to the amendment is simple: issuers may not use it.
Privacy is optional at the asset-issuer level.
If major XRPL issuers decide that encrypted balances create too much operational or compliance complexity, the feature could remain largely unused.
The system requires additional cryptographic processing and key management.
Some institutions may prefer transparent assets even if the privacy option exists.
Partial privacy may also leave metadata exposed
Even when amounts are hidden, addresses remain visible.
That allows transaction graphs to be analyzed.
Sophisticated observers may still infer information from transaction timing, frequency and known wallet identities.
A competitor might not know the exact size of a transfer but could still observe when large institutional accounts become active.
The privacy model therefore reduces exposure without eliminating it.
XRP itself does not gain confidentiality
The amendment applies to MPTs.
XRP remains transparent.
This matters for investors who assume that adding privacy features automatically changes the investment characteristics of the native token.
It does not.
The protocol can become more useful for institutions without necessarily increasing direct demand for XRP.
Sponsored fees may actually reduce end-user XRP demand
Sponsor introduces another important tension.
If institutions pay fees for customers, end users no longer need to hold XRP.
The fees are still paid in XRP, but demand becomes concentrated among sponsors rather than distributed among every participant.
This could improve usability while weakening one traditional argument for widespread native-token demand.
Conclusion
XRP Ledger version 3.3.0 introduces a privacy architecture designed specifically for tokenized institutional assets.
Confidential MPT hides balances and transfer amounts while keeping accounts visible and allowing authorized entities to decrypt the data.
Combined with sponsored fees and atomic batch settlement, the proposal creates a broader institutional framework around public-ledger settlement.
The technology is already included in the software, but it still requires validator approval before becoming active.
Final Takeaway
Confidential MPT is not a privacy-coin feature in the traditional sense. It is a selective confidentiality system built around issuer control, visible counterparties and regulated access to hidden values. Its long-term importance will depend less on the cryptography itself than on whether major token issuers activate it, regulators accept the disclosure model, and institutions decide that partial privacy is sufficient for real-world financial workflows.
