Update and finalize XLS-96

[yinyiqian1]

High Level Overview of Change

Context of Change

update the spec and make the status from Draft to Final

Type of Change

• New XLS Draft
• XLS Update (changes to an existing XLS)
• XLS Status Change (e.g., Draft → Final, Draft → Stagnant)
• Process/Meta (changes to CONTRIBUTING.md, XLS-1, templates, etc.)
• Infrastructure (CI, workflows, scripts, website)
• Documentation (README updates, typo fixes)

[Copilot]

Pull request overview

Updates the XLS-0096 specification document for Confidential MPTs, including changing its preamble status to Final and refining several normative parts of the spec.

Changes:

• Updates XLS-0096 preamble status from Draft to Final.
• Adds/clarifies delegation rules, additional failure conditions, and auditor-related state updates across transactions.
• Adds additional transfer semantics details (including re-randomization rationale/mitigation text).

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[mvadari]

bump

[mvadari]

/ai-review

[xrplf-ai-reviewer]

This is a well-executed finalization pass on XLS-96: status flips Draft→Final, the MaxAmount→MaximumAmount and EncryptedBalanceIssuer/EncryptedBalanceAuditor→sfIssuerEncryptedBalance/sfAuditorEncryptedBalance renames are applied consistently everywhere I checked, several genuine spec bugs are fixed in the process (duplicate OA decrement in Clawback's ledger-effects list, incorrect 'OA ↓ 30' in the ConvertBack worked example, the stale 'returning funds to the issuer's reserve' language on ConvertBack), and the new MPToken ledger-entry section (§7) is internally consistent with the field names used later in Convert/Send/ConvertBack/Clawback. Section renumbering (7→16) throughout looks correct and cross-references I could verify (e.g. §9.4, §15.8) line up. I didn't find any clear correctness bugs in the added lines; the two items below are lower-confidence process/consistency checks worth a quick look before merge.

[mvadari]

/ai-reviewer --adopt

[xrplf-ai-reviewer]

Repository XRPLF/XRPL-Standards has been adopted for auto-reviews by @mvadari.

[mvadari]

Some discrepancies with the source code that Claude found:

#	Area	Finding	File
1	§7.2 invariant	No ledger-wide invariant checks that ConfidentialMPTMergeInbox leaves sfIssuerEncryptedBalance/sfAuditorEncryptedBalance unchanged. The transactor itself doesn't touch them (verified separately), but MPTInvariant.cpp's changesConfidentialFields doesn't gate by transaction type, so nothing at the invariant layer would catch a future regression.	MPTInvariant.cpp:606-612
2	§8.4 deletion blocker	Two different deletion-blocker implementations with different conditions: MPTokenAuthorize.cpp blocks only when COA≠0 (matches spec exactly); MPTokenHelpers.cpp's removeEmptyHolding (used by vault/loan-broker paths) blocks whenever any confidential field is present, regardless of COA — stricter than spec.	MPTokenAuthorize.cpp:90-104, MPTokenHelpers.cpp:352-359
3	§9 invariants	ConfidentialMPTSend::visitInvariantEntry/finalizeInvariants are empty no-ops — this transactor mutates four ciphertext balances per call with no ledger-invariant coverage at all.	ConfidentialMPTSend.cpp:468-485
4	Not verified	MPTokenIssuanceDestroy.cpp (rule: issuer can delete MPTokenIssuance only when COA=0) wasn't in any sub-agent's file set — worth a follow-up read.	—
5	Consistency nit	temDISABLED enforcement is inconsistent across transactors: MPTokenIssuanceSet/MPTokenIssuanceCreate duplicate an explicit local check, while all five ConfidentialMPT* transactors rely solely on the generic Transactor::invokePreflight amendment gate. Not a bug, just worth flagging for consistency.	Transactor.h:640-643

A few items are naming/granularity differences only (e.g. checkFrozen covering both individual-lock and issuance-lock spec items in one call; sigma-proof vs. bulletproof failures both surfacing as one tecBAD_PROOF) — cosmetic, not functional gaps.

Some missing parts of the spec that are missing:

1. Missing mandatory Test Plan.
XLS_TEMPLATE.md:53 states: "An implementation test plan is mandatory for XLSes that affect rippled." This is an Amendment with an open rippled implementation (PR #5860) — it unambiguously affects rippled. There is zero mention of "test," "test plan," or "testing" anywhere in the document. For a Final-status spec (which by definition should have things worked out, including how it was tested) this is a real gap, not just a nitpick. You should be able to get this from the QA folks.

2. "Transaction Fee" subsection missing for all 5 new transaction types.
AMENDMENT_TEMPLATE.md:178-182 is explicit: the Transaction Fee subsection is optional only for existing transactions; "For new transaction types, all subsections are required." ConfidentialMPTConvert, ConfidentialMPTSend, ConfidentialMPTMergeInbox, ConfidentialMPTConvertBack, and ConfidentialMPTClawback are all brand-new transaction types (new TransactionType codes 85–89) — none have a Transaction Fee subsection (xls96.md §8-12). The fee info does exist, but it's buried as a single sentence in §16.2 ("charges 10x the normal base fee for each Confidential MPT transaction") rather than documented per-transaction as the template requires — so it's unclear whether all five transactions share that 10x multiplier or if it varies.

3. No real top-level Rationale section (confirmed, worth restating with more weight).
Beyond just "it's missing" — the content that would go in a Rationale section (why compact sigma proofs were chosen over separate proofs, why the Split-Balance/Dedicated-Account models were chosen over alternatives) is actually scattered as asides inside FAQ answers (A.11, A.14) and the Motivation section, rather than consolidated where reviewers and future readers would expect it per the template's structure.

4. Backwards Compatibility section omission is likely fine but worth a sanity check.
The spec introduces a real behavioral constraint on the existing MPTokenIssuanceSet/MPTokenIssuanceCreate transactions (§6.4: can't combine non-zero TransferFee with confidential balances) and a restriction on who can hold confidential balances (issuer excluded). These are opt-in gates on new functionality, not breaks to existing token behavior, so omitting this section is defensible — but it's a judgment call the authors didn't explicitly justify anywhere in text.

Net: the two solid, reportable gaps are (1) no test plan despite it being template-mandatory for a rippled-affecting spec, and (2) missing per-transaction Transaction Fee subsections for all 5 new transactions, with the fee rationale/multiplier undocumented outside a performance-analysis aside.