Pattern maintenance from the Private MMF approach cycle

CHANGELOG.md

@@ -4,6 +4,9 @@ All notable changes to the EthSystems Map are documented here.
 
 ## [Unreleased]
 
+- feat(pattern): [Selective Disclosure](patterns/pattern-regulatory-disclosure-keys-proofs.md) adds standing register disclosure, a second mode in which a register of record (such as a transfer agent) receives a continuous encrypted feed and rebuilds beneficial ownership for any point in time without holder cooperation. It covers the key, protocol steps, the in-circuit ciphertext constraint and the added threat-model entries, and flags feed granularity as an open trade-off.
+- feat(pattern): [ERC-3643 Tokenized RWAs](patterns/pattern-erc3643-rwa.md) adds a confidentiality-boundary section: the policy layer (claim topics, trusted issuers, ONCHAINID claims) is reusable, and the execution layer (`balanceOf`, `identity`, `isVerified`, `canTransfer`) is replaced.
+- chore(pattern): re-review [Shielding](patterns/pattern-shielding.md), [Private Shared State (FHE)](patterns/pattern-private-shared-state-fhe.md) and [TEE Key Manager](patterns/pattern-tee-key-manager.md) against the Private Money Market Funds approach; no content change.
 - fix: factual audit of the [Private RWA Tokenization](use-cases/private-rwa-tokenization.md) entry and the cards one hop out. Refresh RWA market figures to rwa.xyz (29 Sep 2026) and repair moved category links; correct Merces gas, MPC model and throughput in [Private Bonds](approaches/approach-private-bonds.md) and note the Aztec Alpha V5 soundness disclosure and decentralized sequencer set; scope the no-trusted-setup claim to the PoC in both approaches and mark Fhenix CoFHE testnet-only in [Private Payments](approaches/approach-private-payments.md); fix co-SNARK threat model (a colluding coalition breaks privacy, not soundness) and licensing in [co-SNARK](patterns/pattern-co-snark.md); fix HNDL misuse and post-quantum mitigations in [ERC-3643](patterns/pattern-erc3643-rwa.md), [ZK-KYC](patterns/pattern-zk-kyc-ml-id-erc734-735.md) and [L2 Encrypted Off-chain Audit](patterns/pattern-l2-encrypted-offchain-audit.md); scope amount privacy in [Private PvP via ERC-7573](patterns/pattern-private-pvp-stablecoins-erc7573.md) to contracts running inside the shielded layer; replace dead ERC-734/735 and EAS docs links
 - fix: factual audit of the private-stablecoins entry and the cards one hop out
 - fix(pattern): clarify [ERC-3643 Tokenized RWAs](patterns/pattern-erc3643-rwa.md) transfer-path semantics; distinguish investor-initiated transfer checks from mint and forced-transfer paths, and separate owner and agent controls.

patterns/pattern-erc3643-rwa.md

@@ -40,7 +40,7 @@ standards: [ERC-3643, ERC-734, ERC-735]
 
 related_patterns:
   composes_with: [pattern-crypto-registry-bridge-ewpg-eas, pattern-regulatory-disclosure-keys-proofs, pattern-zk-kyc-ml-id-erc734-735]
-  see_also: [pattern-shielding, pattern-compliance-monitoring]
+  see_also: [pattern-shielding, pattern-compliance-monitoring, pattern-private-mtp-auth]
 ---
 
 ## Intent
@@ -71,6 +71,21 @@ Enable compliant tokenization of real-world assets with built-in identity manage
 
 ERC-3643 distinguishes investor-initiated transfers from administrative actions. The canonical specification states that `mint` and `forcedTransfer` can bypass compliance rules while still requiring a verified recipient. Implementations can differ: the current ERC-3643 reference contract invokes `canTransfer` for `mint` but not for `forcedTransfer`. Integrators should verify the exact deployed version before treating the token as enforcing one uniform rule on every movement of value.
 
+## Confidentiality boundary
+
+This pattern treats transaction-level confidentiality as out of scope. For designs that add it, the boundary runs between two layers:
+
+- **The policy layer can be reused.** Claim topics, the Trusted Issuers Registry and ONCHAINID claims define rules without requiring any particular data to be public. ONCHAINID claims already carry `signature` and `data` byte fields that can hold a zero-knowledge proof, which hides a claim's content but not its existence.
+- **The execution layer cannot be made confidential without interface changes:**
+  - `balanceOf` and `Transfer` events, kept for ERC-20 compatibility
+  - the identity registry's `identity(address)` and `isVerified(address)`, which publish the wallet-to-identity mapping
+  - the compliance contract's `canTransfer(from, to, amount)`, which takes both parties and the amount in the clear
+
+A confidential design therefore reuses the policy layer and replaces some or all of the execution layer. Two directions exist:
+
+- **Encrypted balances, registry kept.** Amounts and balances become FHE ciphertexts, while the identity registry and compliance rules stay as they are. For example, Zama's confidentiality layer for the T-REX Ledger (which follows the ERC-3643 standard) takes this route; it hides amounts, not who transacts (see [Zama](../vendors/zama.md)).
+- **Notes, registry replaced.** Shielded notes and a membership proof also replace the identity registry, which additionally hides who transacts within the anonymity set (see [Private Client Authentication for Institutional EOAs](pattern-private-mtp-auth.md)).
+
 ## Guarantees & threat model
 
 Guarantees:
@@ -104,3 +119,4 @@ An issuer tokenizes a bond as a permissioned token with investor accreditation r
 - [Private Bonds Approach](../approaches/approach-private-bonds.md)
 - [ERC-3643 documentation](https://docs.erc3643.org/erc-3643)
 - [CMTAT (CMTA Token) standard](https://cmta.ch/standards/cmta-token-cmtat)
+- [Zama's confidentiality layer for the T-REX Ledger](https://www.zama.org/post/zama-becomes-the-confidentiality-layer-for-the-t-rex-ledger)

patterns/pattern-private-shared-state-fhe.md

@@ -4,7 +4,7 @@ status: ready
 maturity: testnet
 type: standard
 layer: hybrid
-last_reviewed: 2026-06-18
+last_reviewed: 2026-09-23
 
 works-best-when:
   - Multiple institutions share a ledger, pool, or order book and must hide individual positions from each other.

patterns/pattern-regulatory-disclosure-keys-proofs.md

@@ -4,12 +4,13 @@ status: ready
 maturity: testnet
 type: standard
 layer: hybrid
-last_reviewed: 2026-06-17
+last_reviewed: 2026-09-29
 
 works-best-when:
   - A regulator needs targeted visibility into specific trades or accounts without blanket transparency.
   - The workflow can require an approval step that is logged and revocable.
   - Zero-knowledge predicates can answer most regulator questions without releasing raw data.
+  - A register of record (for example, a transfer agent or a securities registrar) must be able to rebuild beneficial ownership for any point in time.
 avoid-when:
   - Policy requires fully public plaintext of all transactions.
   - The organisation cannot support the operational complexity of threshold key custody and audit storage.
@@ -28,7 +29,7 @@ crops_profile:
 crops_context:
   cr: "Regulator-mandated disclosure is normal institutional operation and does not block transaction flow, so CR stays `medium`. Drops to `low` when disclosure is imposed on end users outside the institution's governance boundary. Threshold custody with independent operators can push CR toward `high` by preventing any single party from forcing a reveal."
   o: "Openness depends on the implementation. Pool-native viewing keys and open predicate circuits are inspectable; proprietary threshold KMS deployments are not. Disclosure policy code, mandate verification logic, and revocation flows should be auditable for the pattern to remain interoperable."
-  p: "Disclosure is scoped: the regulator learns only what the mandate authorises. Zero-knowledge predicate responses leak no raw data. Viewing-key responses leak everything inside the key's scope, so key segmentation and time-boxing are important."
+  p: "Disclosure is scoped: the regulator learns only what the mandate authorises. Zero-knowledge predicate responses leak no raw data. Viewing-key responses leak everything inside the key's scope, so key segmentation and time-boxing are important. The standing register mode discloses register data to the register of record by design, at a granularity the deployment sets; privacy against everyone else is unchanged."
   s: "Rides on threshold key custody, hardware-rooted policy engines, correct mandate parsing, and tamper-evident audit storage. Key compromise yields retroactive loss of privacy across the key's scope."
 
 post_quantum:
@@ -41,7 +42,7 @@ standards: []
 related_patterns:
   composes_with: [pattern-shielding, pattern-user-controlled-viewing-keys, pattern-compliance-monitoring]
   alternative_to: [pattern-proof-of-innocence]
-  see_also: [pattern-l2-encrypted-offchain-audit, pattern-private-pvp-stablecoins-erc7573]
+  see_also: [pattern-l2-encrypted-offchain-audit, pattern-private-pvp-stablecoins-erc7573, pattern-reproducible-audit-extraction, pattern-crypto-registry-bridge-ewpg-eas]
 
 open_source_implementations:
   - url: https://github.com/ethereum-attestation-service/eas-contracts
@@ -51,7 +52,11 @@ open_source_implementations:
 
 ## Intent
 
-Provide on-demand, scoped visibility into confidential trades and positions via threshold-controlled viewing keys or zero-knowledge predicate proofs that answer specific regulator questions. The institution keeps plaintext private by default and releases only the minimum information required to satisfy a specific, logged mandate.
+The pattern has two modes.
+
+**Mandate-based disclosure** provides on-demand, scoped visibility into confidential trades and positions via threshold-controlled viewing keys or zero-knowledge predicate proofs that answer specific regulator questions. The institution keeps plaintext private by default and releases only the minimum information required to satisfy a specific, logged mandate.
+
+**Standing register disclosure** serves a register of record such as a transfer agent or a securities registrar. The register receives a continuous feed sufficient to rebuild beneficial ownership for any point in time, without holder cooperation. This mode trades least privilege for completeness, so it suits only a party that is already entitled to the full register. How much the feed carries beyond ownership is a deployment choice; see Trade-offs.
 
 ## Components
 
@@ -60,29 +65,43 @@ Provide on-demand, scoped visibility into confidential trades and positions via
 - Predicate circuit library that can answer common regulator questions ("total volume in ISIN X on date Y"; "no trades with sanctioned parties in quarter Q") without releasing raw data.
 - Attestation log that records every access grant as a signed, hashed entry; a public registry can anchor these hashes for tamper-evidence without revealing content.
 - Approval workflow used by the institution's compliance team to review and sign off on requests before the policy engine acts.
+- Register-of-record key (standing register mode): an encryption key held by the register of record, ideally under threshold custody. Every value-moving operation encrypts the resulting position data to it.
 
 ## Protocol
 
+Mandate-based disclosure:
+
 1. [regulator] Submit a scoped request specifying account, instrument, time window, and mandate.
 2. [operator] The policy engine checks the request against the active mandate and approvals; an attestation logs the grant.
 3. [operator] Assemble the response: either a time-limited viewing key reconstituted from threshold shares, or a zero-knowledge proof generated by the predicate circuit over the relevant private state.
 4. [operator] Deliver the response to the regulator over an authenticated channel.
 5. [auditor] Verify the disclosure record against the anchored hash to confirm that the response matches the approved mandate.
 
+Standing register disclosure:
+
+1. [operator] The register of record publishes its encryption key and anchors the key's hash in the attestation log.
+2. [user] Every value-moving operation (issuance, transfer, redemption) encrypts the resulting position data, such as owner identifier and amount, to the register key.
+3. [prover] The circuit constrains that ciphertext to encrypt the same values the proof commits to. Without this constraint, completeness rests on the holder's legal obligation to encrypt honestly.
+4. [contract] The ciphertext is published with the transaction, so the feed needs no separate delivery channel.
+5. [operator] The register of record decrypts the feed, rebuilds beneficial ownership for any point in time, and reconciles it against its off-chain records.
+
 ## Guarantees & threat model
 
 Guarantees:
 
 - Least-privilege, revocable access: viewing keys are time-boxed; predicate proofs leak no raw data.
 - Full audit trail: every grant is recorded, signed, and anchored.
 - Predicate proofs can answer common compliance questions without exposing transaction content.
+- Standing register disclosure: the register of record can rebuild beneficial ownership for any point in time without holder cooperation, provided the circuit constrains the ciphertext.
 
 Threat model:
 
 - Threshold key custody integrity. A coalition of operators above the threshold can forge responses or leak keys.
 - Mandate parsing correctness. A bug in the policy engine can widen scope beyond what the mandate authorises.
 - Attestation log availability. If the log is rewritable or unobserved, disclosures can be retroactively denied.
 - Predicate circuit soundness and input binding. A misbound predicate may answer a different question than the one logged.
+- Register key compromise (standing register mode) exposes the entire register for every period the feed covers. Threshold custody and key rotation carry more weight than in the mandate-based mode.
+- Unconstrained ciphertexts. If the circuit does not bind the register ciphertext to the committed values, a holder can publish data the register cannot decrypt, and completeness falls back to legal enforcement.
 - Side channels in custody infrastructure are out of scope for this pattern.
 
 ## Trade-offs
@@ -91,11 +110,14 @@ Threat model:
 - Predicate authoring requires discipline: circuits must mirror mandate semantics exactly, and changes need auditable version control.
 - Response latency increases with threshold reconstitution or proof generation time; batch workflows absorb this better than real-time supervisory queries.
 - Regulator tooling maturity varies: some supervisory authorities still require raw data formats, limiting applicable use cases.
+- The standing register mode inverts least privilege, and feed granularity has no free option. Per-operation data lets the register rebuild holdings for any date, and with them most flows, since two holders' balances changing together reveal the pair. Coarser feeds, such as periodic snapshots, reveal less but may not meet record-keeping duties. What a register of record must minimally see is an open question. Constraining the ciphertext in-circuit also adds proving cost to every value-moving operation.
 
 ## Example
 
 A supervisory authority asks for trades on a given date in a specific instrument. The policy engine matches the request against the institution's active mandate, an approval record is logged, and a 24-hour viewing key reconstituted from threshold shares is issued. The regulator reviews the trades during the window; at expiry the key is revoked automatically, and the attestation log retains a hashed record for future audit.
 
+The transfer agent of a tokenized security holds the register key. Each issuance, transfer and redemption publishes position data encrypted to that key, bound to the proof by the circuit, so the register can reproduce holder records, eligibility status and tax reports for any date without asking holders.
+
 ## See also
 
 - [EAS documentation](https://easscan.org/docs)

patterns/pattern-shielding.md

@@ -4,7 +4,7 @@ status: ready
 maturity: production
 type: standard
 layer: hybrid
-last_reviewed: 2026-04-22
+last_reviewed: 2026-09-23
 
 works-best-when:
   - You need confidential transfer amounts and counterparties.

patterns/pattern-tee-key-manager.md

@@ -4,7 +4,7 @@ status: ready
 maturity: testnet
 type: standard
 layer: offchain
-last_reviewed: 2026-06-18
+last_reviewed: 2026-09-23
 
 works-best-when:
   - An institution needs hot or warm key custody with stronger isolation than a software-only wallet.