XLS-96: confidentiality and native transfer fees are mutually exclusive, and the choice is permanent

[poetsd]

Discussion #372 is closed now that the spec has been merged, so I'm opening this separately rather than reviving it.

Before writing this I ran the confidential MPT lifecycle end to end on Devnet and then tried both TransferFee transitions, so the behaviour below is observed rather than inferred. The script is here and reproduces in about three minutes from a clean environment: https://github.com/poetsd/xls96-verifier

§14.4 explains why percentage fees and confidential amounts cannot coexist, and I don't dispute that reasoning: a percentage fee needs the amount, and ConfidentialMPTSend hides it. What I'd like to raise is the consequence rather than the mechanism.

The lock runs in both directions

§6.4 makes confidential balances and a nonzero TransferFee mutually exclusive. On Devnet both directions reject with the same code:

B1  setting TransferFee=250 on a confidential issuance
    → tecNO_PERMISSION
B2  enabling the confidential-balance flag on an issuance with TransferFee=250
    → tecNO_PERMISSION

Since tfMPTSetCanHoldConfidentialBalance cannot be cleared once set, an issuer that enables confidentiality gives up native transfer fees permanently, and an issuer already charging a fee cannot adopt confidentiality at all without reissuing under a new issuance ID — losing holders, authorizations and history.

Elsewhere the ledger treats TransferFee as adjustable after creation; that is precisely why the second rule in §6.4 has to exist. Confidentiality is the one thing that freezes it at zero permanently.

Why this collides with the stated motivation

The abstract positions confidential MPTs for institutional and privacy-sensitive contexts, and the metadata conventions lean the same way (asset_class: rwa, asset_subclass: treasury in the tutorial). But funds, treasuries, private credit and distribution arrangements are also the issuers most likely to carry a servicing or distribution fee expressed in basis points. The population that most wants confidentiality overlaps heavily with the population that needs a fee.

That does not make the design wrong. It does mean the amendment may be least available exactly where it was aimed.

Open questions, not proposals

I am not in a position to judge the cryptographic cost of any of these, so I would rather ask than assert:

1. Is a flat per-transfer fee — a fixed token amount rather than a percentage — compatible? It does not require knowing the transferred amount at all.
2. ConfidentialMPTConvert already exposes MPTAmount in plaintext (the verifier prints it). Is the conversion boundary a defensible place to assess a fee, given the amount is public there by design?
3. Were either of these considered and rejected? If so, that reasoning would be valuable in §14.4 — as written, it reads as though percentage fees were the only model examined.

Minimum ask

Independent of the above: there is currently no FAQ entry covering this. An issuer can enable confidential balances — an irreversible operation — without encountering the fee consequence anywhere except §6.4 and §14.4. Given the amendment is in voting, a short FAQ entry stating the trade-off plainly seems worth adding whether or not the design changes. I'm happy to open a PR with draft wording if that would be useful.

---

(Side note, unrelated to the above: xrpl-py raises XRPLReliableSubmissionException on tec-class results, which made both rejections above look like client-side errors until the verifier was changed to recover the code from the exception. Mentioning it in case it is relevant to the recent clarification in #628 about tec results being recorded in validated ledgers.)