XLS-draft Confidential MPT Key Rotation

[yinyiqian1]

High Level Overview of Change

Context of Change

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)

[mvadari]

Please follow the format for drafts expected in the CONTRIBUTING document and the templates (namely, the file naming)

[Copilot]

Pull request overview

Introduces an amendment draft for rotating and recovering Confidential MPT ElGamal keys.

Changes:

• Adds issuer, auditor, and holder key-rotation flows.
• Defines three transactions and new ledger fields.
• Documents migration, recovery, permissions, and security behavior.

---

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

[Tapanito]

Please update the table to follow this format exactly: https://github.com/XRPLF/XRPL-Standards/blob/master/templates/AMENDMENT_TEMPLATE.md#22-fields

The table is missing:

• Constant column
• The ? (question mark) must be dropped from Required column
• Default Value column

[Tapanito]

Please update the columns

[Tapanito]

This table is missing the Default Value column.

[Tapanito]

Missing Default Value column

[Tapanito]

The spec also requires XLS-33

[Tapanito]

Complexity concern: mode explosion, especially in ConfidentialMPTMirrorUpdate

Overall the three-role rotation design (issuer/auditor two-phase, holder self-contained, holder-loss two-step recovery) is a reasonable shape for the problem. But a few places look accretive rather than designed top-down, and I'd like the authors to consider tightening before this goes further:

1. ConfidentialMPTMirrorUpdate has too many modes for one transaction type.
Mode is selected by Holder presence (issuer vs. holder-self-migration), further split by which of IssuerEncryptedAmount/AuditorEncryptedAmount are present (issuer-only / auditor-only / both) — 6-7 distinct behaviors, each discharged by its own sigma protocol (Section 9.7). Two of those relations ("holder both-mirrors" and "auditor-only") are explicitly "not yet covered" by the companion proof spec. That's a lot of surface for a transaction that's meant to do one conceptual thing ("re-encrypt a stale mirror").

Compare this to ConfidentialMPTHolderKeyUpdate, which deliberately uses explicit flags rather than field-presence overloading for mode selection, and the rationale given (18.5) is that flags "make validator logic unambiguous and eliminate edge cases with partial field sets." That rationale applies with equal force to ConfidentialMPTMirrorUpdate, which doesn't follow it. Suggest either:

• splitting issuer-mode and holder-self-migration-mode into two transaction types (mirroring the flag-based approach), or
• collapsing issuer-only/auditor-only/both into a single relation by always requiring both encrypted-amount fields, with a no-op/null delta for the mirror not being rotated.

2. The same staleness invariant is enforced in at least three separate places — validator preclaim (4 existing transactions × 2 conditions each, Section 14.1), wallet-side pre-submission checks (14.3), and off-chain regulator verification (14.5) — with no single source of truth beyond "compare two epoch fields." This isn't wrong, but it's a sign the epoch model is being threaded through the whole system rather than contained. Worth double-checking all three call sites stay in sync as the spec evolves.

3. Historical key retention is a correctness requirement with no protocol enforcement. Per 15.9, if the issuer destroys a pre-rotation secret key before all holders at that epoch have migrated, those holders lose the actively-migrated path permanently and must fall back to self-migration — which requires the holder to have sk_H and to have already merged their inbox. There's no on-chain signal that would stop an issuer from destroying a key too early, and no enforcement mechanism suggested beyond "issuers should retain historical secret keys." For a protocol otherwise built on formal ZK guarantees, this correctness property resting entirely on issuer operational discipline stands out.

4. Issuer-key-loss recovery has a real, acknowledged gap for inactive holders (13.5) with no on-chain fallback — permanent suspension of clawback authority is listed as an accepted outcome. Given how much of the rest of the spec is built specifically to close comparable gaps (e.g. the entire holder-key-loss recovery flow exists to solve exactly this class of problem for the holder side), it's worth asking whether the same asymmetry is acceptable for the issuer side, or whether it deserves the same design attention.

5. Permission delegation for ConfidentialMPTHolderKeyUpdate recovery mode is left as "TBD" (17.2/17.3) in a spec that's otherwise fully specified down to proof byte-sizes. Recommend resolving this before merge — it's a security-relevant decision (whether a custody provider can trigger recovery without holder consent), not an implementation detail.

Given the number of interacting moving parts (5 new ledger fields, 8 new invariants, 4 new/modified transactions, 6+ proof relations), I'd suggest the authors provide a state-machine diagram per role (issuer, auditor, holder) showing valid epoch/mirror-epoch transitions — it would make it much easier to verify there's no missed corner case, and would likely surface further opportunities to collapse modes.