From e2a0c5ad7a9676f9bad2acb98a426d610673932e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?David=20Nu=CC=81n=CC=83ez?= Date: Tue, 29 Sep 2026 13:47:24 +0200 Subject: [PATCH 1/4] Re-review Shielding, Private Shared State (FHE), TEE Key Manager agains the private MMF approach. --- CHANGELOG.md | 1 + patterns/pattern-private-shared-state-fhe.md | 2 +- patterns/pattern-shielding.md | 2 +- patterns/pattern-tee-key-manager.md | 2 +- 4 files changed, 4 insertions(+), 3 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index e43007e..6957f05 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,6 +4,7 @@ All notable changes to the EthSystems Map are documented here. ## [Unreleased] +- 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. diff --git a/patterns/pattern-private-shared-state-fhe.md b/patterns/pattern-private-shared-state-fhe.md index b6c4fac..ac725d0 100644 --- a/patterns/pattern-private-shared-state-fhe.md +++ b/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. diff --git a/patterns/pattern-shielding.md b/patterns/pattern-shielding.md index e04fd35..5cefa4a 100644 --- a/patterns/pattern-shielding.md +++ b/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. diff --git a/patterns/pattern-tee-key-manager.md b/patterns/pattern-tee-key-manager.md index f89b3d3..7b6c1d5 100644 --- a/patterns/pattern-tee-key-manager.md +++ b/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. From 94e60decd361b5d1bc0936b351ec8d1cbc4576b2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?David=20Nu=CC=81n=CC=83ez?= Date: Tue, 29 Sep 2026 15:28:50 +0200 Subject: [PATCH 2/4] ERC-3643: add DS Protocol and a confidentiality-boundary section --- CHANGELOG.md | 1 + patterns/pattern-erc3643-rwa.md | 16 +++++++++++++++- 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 6957f05..5e425f5 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,6 +4,7 @@ All notable changes to the EthSystems Map are documented here. ## [Unreleased] +- feat(pattern): [ERC-3643 Tokenized RWAs](patterns/pattern-erc3643-rwa.md) adds Securitize's DS Protocol as an alternative permissioned-token model, and a confidentiality-boundary section: the policy layer (claim topics, trusted issuers, ONCHAINID claims) is reusable, and the execution layer (`balanceOf`, `identity`, `isVerified`, `canTransfer`) has to be 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 diff --git a/patterns/pattern-erc3643-rwa.md b/patterns/pattern-erc3643-rwa.md index b2fcb71..7b9c5c6 100644 --- a/patterns/pattern-erc3643-rwa.md +++ b/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,18 @@ 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 the execution layer, for example with shielded notes and a membership proof in place of the identity registry (see [Private Client Authentication for Institutional EOAs](pattern-private-mtp-auth.md)). The same split applies to DS Protocol (see Trade-offs): its compliance configuration is policy, while the registry's public investor and country views and the per-transfer investor lookup are execution. + ## Guarantees & threat model Guarantees: @@ -94,6 +106,7 @@ Threat model: - Not suitable for permissionless DeFi composition. Many protocols will reject permissioned tokens. - Compliance rules must be maintained and updated as regulations evolve, which requires ongoing governance. - CMTAT covers the same intent through a rule-engine and allowlist model instead of an identity registry with claim issuers; it is blockchain-agnostic (EVM, Tezos, Solana) and has an existing privacy-preserving implementation in Noir for Aztec, relevant where transaction-level confidentiality is a goal. +- Securitize's DS Protocol covers the same intent with a different architecture. The token resolves its registry service, compliance service, compliance configuration, lock manager, wallet manager and trust service through a service registry, and investors are identified by an issuer-assigned investor ID rather than an ONCHAINID contract. Tokenized funds on Ethereum use it. Two generations are in production: the omnibus-wallet mechanism was removed upstream in July 2025, and deployments that predate the change still carry it. ## Example @@ -104,3 +117,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) +- [DS Protocol (Securitize)](https://github.com/securitize-io/dstoken) and the [omnibus removal commit](https://github.com/securitize-io/dstoken/commit/e406ee17322ee1c1dc3fef669bf9a63fd479e5dc) From 94af68ca9d5bd8c28e6a34280f89455de453e254 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?David=20Nu=CC=81n=CC=83ez?= Date: Tue, 29 Sep 2026 19:24:52 +0200 Subject: [PATCH 3/4] Add standing register mode to Selective disclouse pattern --- CHANGELOG.md | 1 + ...ttern-regulatory-disclosure-keys-proofs.md | 30 ++++++++++++++++--- 2 files changed, 27 insertions(+), 4 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 5e425f5..efa2727 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,6 +4,7 @@ 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 Securitize's DS Protocol as an alternative permissioned-token model, and a confidentiality-boundary section: the policy layer (claim topics, trusted issuers, ONCHAINID claims) is reusable, and the execution layer (`balanceOf`, `identity`, `isVerified`, `canTransfer`) has to be 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 diff --git a/patterns/pattern-regulatory-disclosure-keys-proofs.md b/patterns/pattern-regulatory-disclosure-keys-proofs.md index bd96cfd..370c48b 100644 --- a/patterns/pattern-regulatory-disclosure-keys-proofs.md +++ b/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,15 +65,26 @@ 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: @@ -76,6 +92,7 @@ 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: @@ -83,6 +100,8 @@ Threat model: - 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) From b9d72f74df8cd358994b880e7bbafead481c34fe Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?David=20Nu=CC=81n=CC=83ez?= Date: Wed, 30 Sep 2026 08:02:37 +0200 Subject: [PATCH 4/4] Drop references to DS protocol in erc3643 pattern card, and add to Zama & T-REX --- CHANGELOG.md | 2 +- patterns/pattern-erc3643-rwa.md | 8 +++++--- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index efa2727..09f86d8 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -5,7 +5,7 @@ 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 Securitize's DS Protocol as an alternative permissioned-token model, and a confidentiality-boundary section: the policy layer (claim topics, trusted issuers, ONCHAINID claims) is reusable, and the execution layer (`balanceOf`, `identity`, `isVerified`, `canTransfer`) has to be replaced. +- 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 diff --git a/patterns/pattern-erc3643-rwa.md b/patterns/pattern-erc3643-rwa.md index 7b9c5c6..c95d38a 100644 --- a/patterns/pattern-erc3643-rwa.md +++ b/patterns/pattern-erc3643-rwa.md @@ -81,7 +81,10 @@ This pattern treats transaction-level confidentiality as out of scope. For desig - 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 the execution layer, for example with shielded notes and a membership proof in place of the identity registry (see [Private Client Authentication for Institutional EOAs](pattern-private-mtp-auth.md)). The same split applies to DS Protocol (see Trade-offs): its compliance configuration is policy, while the registry's public investor and country views and the per-transfer investor lookup are execution. +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 @@ -106,7 +109,6 @@ Threat model: - Not suitable for permissionless DeFi composition. Many protocols will reject permissioned tokens. - Compliance rules must be maintained and updated as regulations evolve, which requires ongoing governance. - CMTAT covers the same intent through a rule-engine and allowlist model instead of an identity registry with claim issuers; it is blockchain-agnostic (EVM, Tezos, Solana) and has an existing privacy-preserving implementation in Noir for Aztec, relevant where transaction-level confidentiality is a goal. -- Securitize's DS Protocol covers the same intent with a different architecture. The token resolves its registry service, compliance service, compliance configuration, lock manager, wallet manager and trust service through a service registry, and investors are identified by an issuer-assigned investor ID rather than an ONCHAINID contract. Tokenized funds on Ethereum use it. Two generations are in production: the omnibus-wallet mechanism was removed upstream in July 2025, and deployments that predate the change still carry it. ## Example @@ -117,4 +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) -- [DS Protocol (Securitize)](https://github.com/securitize-io/dstoken) and the [omnibus removal commit](https://github.com/securitize-io/dstoken/commit/e406ee17322ee1c1dc3fef669bf9a63fd479e5dc) +- [Zama's confidentiality layer for the T-REX Ledger](https://www.zama.org/post/zama-becomes-the-confidentiality-layer-for-the-t-rex-ledger)