diff --git a/CHANGELOG.md b/CHANGELOG.md index 8a5cdc5..e43007e 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,6 +4,7 @@ All notable changes to the EthSystems Map are documented here. ## [Unreleased] +- 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. - fix(pattern): correct cross-chain atomicity claims. [Private PvP via ERC-7573](patterns/pattern-private-pvp-stablecoins-erc7573.md) now follows the ERC-7573 shape (one leg locked, the other paid through the decryption contract, an oracle-released key that releases or returns the locked leg) and states conditional settlement instead of "both legs settle or both revert"; the old recipe finalised one leg and then claimed both escrows revert. [Atomic DvP via ERC-7573](patterns/pattern-dvp-erc7573.md) drops the timeout reclaim that ERC-7573 does not define and names the oracle condition. [Permissioned Ledger Interoperability](patterns/pattern-permissioned-ledger-interoperability.md) states the coordinator trust assumption of two-phase commit ([#198](https://github.com/ethsystems/map/pull/198)) diff --git a/approaches/approach-private-bonds.md b/approaches/approach-private-bonds.md index 532bf70..dde19c7 100644 --- a/approaches/approach-private-bonds.md +++ b/approaches/approach-private-bonds.md @@ -1,7 +1,7 @@ --- title: "Approach: Private Bond Issuance & Trading" status: ready -last_reviewed: 2026-06-24 +last_reviewed: 2026-09-29 use_case: private-bonds related_use_cases: [private-corporate-bonds, private-government-debt] @@ -43,7 +43,7 @@ open_source_implementations: - url: https://github.com/AztecProtocol/aztec-packages description: "Aztec privacy-native L2" language: TypeScript / Noir - - url: https://github.com/0xMiden/miden-base + - url: https://github.com/0xMiden/protocol description: "Miden client-side ZK rollup" language: Rust --- @@ -54,7 +54,7 @@ open_source_implementations: ### Scenario -A bank issues a EUR 100M corporate bond series with private allocation amounts to 50 institutional investors and operates an active secondary market with RFQ-based price discovery. The bank needs hidden positions and trade sizes, atomic same-chain DvP against EURC, jurisdiction-specific selective disclosure (eWpG, MiCA), and an automated 24/7 market with daily settlement. +A bank issues a EUR 100M corporate bond series with private allocation amounts to 50 institutional investors and operates an active secondary market with RFQ-based price discovery. The bank needs hidden positions and trade sizes, atomic same-chain DvP against EURC, jurisdiction-specific selective disclosure (eWpG for the bond; MiCA for the EURC leg, since bonds that are MiFID II financial instruments fall outside MiCA), and an automated 24/7 market with daily settlement. ### Requirements @@ -92,7 +92,7 @@ example_vendors: [paladin, railgun] - L1 consensus and the verifier contract - Gas relayer for liveness on private withdrawals - Issuer for the global-note-to-holder-notes split at issuance -- No per-circuit trusted setup (UltraHonk uses a universal KZG SRS) +- No per-circuit trusted setup in the PoC (UltraHonk uses a universal KZG SRS); Groth16-based vendors (Railgun, Paladin Zeto) rely on per-circuit setup ceremonies **Threat model:** - A circuit or verifier soundness bug (e.g., an under-constrained circuit) lets an attacker forge or double-spend notes; metadata leakage at deposit/withdraw boundaries is the practical privacy exposure @@ -126,14 +126,14 @@ example_vendors: [aztec, miden] **How it works:** Aztec exposes private notes and contracts as native primitives. Bond issuance, transfer, and coupon logic run in private functions with client-side proving. Incoming Viewing Keys (IVKs) provide account-level read access; nullifier keys are app-siloed for damage containment. **Trust assumptions:** -- Sequencer for ordering (currently centralized in early deployments) +- Sequencer set for ordering (Aztec Alpha mainnet uses a staked, decentralized sequencer set; Alpha is early-stage and Aztec advises limiting deposits) - Bridge contract for L1 settlement -- Aztec proving system soundness +- Aztec proving system soundness (a critical soundness vulnerability in the Alpha V5 proving system was disclosed on 2026-07-27) **Threat model:** - Sequencer outage or censorship; rollup escape paths leak linkage during forced exit - Bridge boundary leaks deposit and withdraw amounts -- IVK compromise reveals all account-level flows +- IVK compromise reveals every note the account receives, including its own change notes; it grants no spending authority **Works best when:** - Bond logic is complex (coupons, lifecycle) and benefits from native privacy primitives @@ -159,7 +159,7 @@ example_vendors: [taceo-merces] **How it works:** Bond state lives offchain under MPC sharing; institutional senders submit shares, the committee computes the transition under MPC, and emits a co-SNARK on chain. Account-model simplicity is preserved at the application layer; addresses remain visible. **Trust assumptions:** -- Honest-majority 3-party MPC committee (TACEO coNoir uses REP3 / 3-party Shamir, tolerating one corrupt node) +- Honest-majority 3-party MPC committee (Merces uses semi-honest 3-party replicated secret sharing, tolerating one corrupt node) - Co-SNARK soundness - Committee liveness @@ -171,7 +171,7 @@ example_vendors: [taceo-merces] **Works best when:** - Institutional custodial models are acceptable - Amount confidentiality is sufficient and counterparty privacy is not required -- Throughput target matches batched proving (~200 TPS, TACEO-reported) +- Throughput target matches batched proving (~200-300 TPS, TACEO-reported) **Avoid when:** - Honest-majority assumption among MPC nodes is incompatible with the threat model @@ -198,9 +198,9 @@ example_vendors: [zama, fhenix] - ACL model adoption by all bond participants **Threat model:** -- Threshold compromise reveals ciphertexts +- Compromise of the threshold network above its threshold decrypts all ciphertexts - No revocation per ciphertext; revocation requires a re-encryption / re-grant on balance update -- Shared throughput (500-1000 TPS, vendor-reported) is a network-wide bottleneck +- Shared per-chain throughput (over 20 TPS on CPU; 500-1000 TPS projected with GPUs by end-2026, vendor-reported) is a bottleneck **Works best when:** - Bond logic involves complex calculations (coupon accruals, derivatives) that map naturally to FHE @@ -220,7 +220,7 @@ example_vendors: [zama, fhenix] | **CROPS** | CR:hi O:y P:full S:hi | CR:med O:part P:full S:med | CR:med O:part P:part S:med | CR:med O:part P:part S:med | | **Trust model** | Self-custody (L1 + ZK) | Sequencer + bridge | Honest-majority 3-party MPC | t-of-n threshold network | | **Privacy scope** | Amounts + addresses (via gas relayer) | Amounts + addresses (account level) | Amounts only; addresses public | Amounts only; addresses public | -| **Performance** | High gas, chain-dependent throughput | L2-internal fees, unknown TPS | ~95K gas/tx batched, ~200 TPS (vendor) | ~300K gas/tx, 500-1000 TPS shared (vendor) | +| **Performance** | High gas, chain-dependent throughput | L2-internal fees, unknown TPS | ~0.9M gas per transfer intent plus ~3.8M per 50-tx batch, ~200-300 TPS (vendor) | ~300K gas/tx, 20+ TPS shared, 500-1000 projected (vendor) | | **Operator req.** | No (gas relayer optional) | Yes (sequencer) | Yes (MPC committee) | Yes (threshold network) | | **Cost class** | High (L1 verify) | Low (L2-internal) | Low (batched) | Medium | | **Regulatory fit** | Strong (per-note view keys) | Strong (IVKs, app-siloed nullifiers) | Strong for known counterparty | Strong (per-balance ACL) | @@ -230,7 +230,7 @@ example_vendors: [zama, fhenix] ### Business perspective -For institutional bond issuance and trading at scale, UTXO Shielded Notes is the default: production maturity (Railgun ~USD 5b lifetime shielded volume as of 2026), white-label vendor coverage (Paladin), privacy over amounts, counterparties, and addresses (addresses via gas relayer), and a regulatory story built on per-note viewing keys that maps cleanly onto eWpG and MiCA disclosure regimes. Privacy L2 fits where bond logic is complex (coupons, structured lifecycle) because it removes circuit-engineering work, but the issuer must accept the rollup's decentralization timeline. co-SNARKs and FHE fit specific institutional contexts: bilateral or club-mode markets where address visibility is acceptable, or coupon-heavy products where homomorphic arithmetic is the natural model. +For institutional bond issuance and trading at scale, UTXO Shielded Notes is the default: production maturity (Railgun ~USD 5b lifetime shielded volume as of 2026), white-label vendor coverage (Paladin), privacy over amounts, counterparties, and addresses (addresses via gas relayer), and a disclosure story built on per-note viewing keys that can be assessed against eWpG (and MiCA for the EURC leg). Privacy L2 fits where bond logic is complex (coupons, structured lifecycle) because it removes circuit-engineering work, but the issuer must accept the rollup's decentralization timeline. co-SNARKs and FHE fit specific institutional contexts: bilateral or club-mode markets where address visibility is acceptable, or coupon-heavy products where homomorphic arithmetic is the natural model. ### Technical perspective @@ -244,7 +244,7 @@ This is a perspective for legal review by the deploying issuer, not legal advice ### Default -For institutional bond issuance and trading on a 1-2 year production timeline, default to UTXO Shielded Notes with [Paladin](../vendors/paladin.md) or [Railgun](../vendors/railgun.md) as the underlying shielded pool. This is the category with documented production volume, vendor coverage, and a disclosure interface that has been mapped onto eWpG / MiCA expectations. +For institutional bond issuance and trading on a 1-2 year production timeline, default to UTXO Shielded Notes with [Paladin](../vendors/paladin.md) or [Railgun](../vendors/railgun.md) as the underlying shielded pool. This is the category with documented production volume, vendor coverage, and a per-note viewing-key disclosure interface that can be assessed against eWpG expectations. ### Decision factors diff --git a/approaches/approach-private-payments.md b/approaches/approach-private-payments.md index 54c0abd..4cf5fcd 100644 --- a/approaches/approach-private-payments.md +++ b/approaches/approach-private-payments.md @@ -1,7 +1,7 @@ --- title: "Approach: Private Payments" status: ready -last_reviewed: 2026-09-18 +last_reviewed: 2026-09-29 use_case: private-stablecoins related_use_cases: [resilient-disbursement-rails, private-treasuries] @@ -40,6 +40,10 @@ pocs: sub_approach: "Stateless Plasma" spec: pocs/private-payment/plasma/SPEC.md status: benchmarked + - name: "Resilient Disbursement Rails" + sub_approach: "Resilient Disbursement Rails" + spec: pocs/private-payment/resilient-disbursement-rails/SPEC.md + status: implemented open_source_implementations: - url: https://github.com/Railgun-Privacy/contract @@ -105,7 +109,7 @@ example_vendors: [railgun] - L1 consensus and the verifier contract - Gas relayer is willing to relay (liveness only; not custodial) -- No per-circuit trusted setup (UltraHonk uses a universal KZG SRS) +- No per-circuit trusted setup in the PoC (UltraHonk uses a universal KZG SRS); Groth16-based vendors (Railgun, Paladin Zeto) rely on per-circuit setup ceremonies **Threat model:** @@ -155,11 +159,11 @@ example_vendors: [aztec, fhenix] **Summary:** Confidential transfers run inside a privacy-native rollup where state is hidden by default at the protocol layer. -**How it works:** Users post transactions with client-side zero-knowledge proofs to a privacy-native sequencer (Aztec) or use FHE-based confidential balances (Fhenix). Hidden state, encrypted memo, and account-level viewing keys give institutional readers controlled access. Bridging to L1 is the privacy boundary. +**How it works:** Users post transactions with client-side zero-knowledge proofs to a privacy-native sequencer (Aztec) or use FHE-based confidential balances computed by a coprocessor on an existing EVM chain (Fhenix CoFHE, testnet only). Hidden state, encrypted memo, and account-level viewing keys give institutional readers controlled access. Bridging to L1 is the privacy boundary. **Trust assumptions:** -- Sequencer for ordering (currently centralized in early deployments) +- Sequencer set for ordering (centralized on most privacy L2s; Aztec runs a permissionless staked sequencer set) - Bridge contract for L1 settlement integrity - Viewing-key custody at the institution @@ -219,7 +223,7 @@ poc_spec: pocs/private-payment/plasma/SPEC.md - User-side state custody is operationally infeasible - Exit-delay risk is not tolerable for the asset class -**Implementation notes:** PoC uses Plonky2 with operator-side recursive aggregation; client proofs run in 5.9-9.8s, operator proofs in 42-49s. PlasmaBlind (folding-scheme aggregation) is a tracked alternative. +**Implementation notes:** PoC uses Plonky2 with operator-side recursive aggregation; client proofs run in 5.9-9.8s, operator proofs in 38-49s. PlasmaBlind (folding-scheme aggregation) is a tracked alternative. #### Benchmarks @@ -230,7 +234,7 @@ poc_spec: pocs/private-payment/plasma/SPEC.md | Gas: withdraw | ~343K (operator, amortized) | | Gas: batch | ~255K (operator, amortized) | | Proof gen (client) | 5.9-9.8s | -| Proof gen (operator) | 42-49s | +| Proof gen (operator) | 38-49s | ### TEE-Based Privacy @@ -325,6 +329,7 @@ uses_patterns: pattern-forced-withdrawal, pattern-verifiable-attestation, ] +poc_spec: pocs/private-payment/resilient-disbursement-rails/SPEC.md example_vendors: [] ``` @@ -363,7 +368,7 @@ example_vendors: [] | Axis | L1 Shielded | Privacy L2 | Stateless Plasma | TEE | MPC | Resilient Disbursement | | ------------------ | --------------------------------------- | ----------------------------------- | ---------------------------------------------------- | -------------------------------- | ----------------------------------- | -------------------------------------------------------- | -| **Maturity** | prototyped | prototyped | prototyped | documented | prototyped | documented | +| **Maturity** | prototyped | prototyped | prototyped | documented | prototyped | prototyped | | **Context** | both | both | both | i2i | i2i | i2u | | **CROPS** | CR:hi O:y P:part S:hi | CR:med O:part P:full S:med | CR:med O:part P:full S:med | CR:med O:no P:full S:lo | CR:med O:part P:part S:med | CR:hi O:y P:full S:hi | | **Trust model** | L1 + relayer liveness | Sequencer + bridge | Operator + L1 anchor | TEE vendor + supply chain | Honest-majority MPC | Multi-relay + smartcard + IResilientIdentity | @@ -392,7 +397,7 @@ This is a perspective for legal review by the deploying institution, not legal a ### Default -For institutional treasury and payment operations at moderate volume with standard compliance, default to a Hybrid L1/L2 composition: Privacy L2 (Aztec for native confidential transfers, Fhenix for FHE-based balances) handles frequent operations; L1 Shielded Payments (Railgun-style) handles high-value transfers or anonymity-sensitive flows. Selective disclosure runs through user-controlled viewing keys plus regulator viewing keys with time-bound, threshold-controlled scope. ISO 20022 message interpreters handle SWIFT compatibility; ERC-3643 handles compliance gating where the asset is a regulated security. +For institutional treasury and payment operations at moderate volume with standard compliance, default to a Hybrid L1/L2 composition: Privacy L2 (Aztec for native confidential transfers, Fhenix CoFHE for FHE-based balances once it leaves testnet) handles frequent operations; L1 Shielded Payments (Railgun-style) handles high-value transfers or anonymity-sensitive flows. Selective disclosure runs through user-controlled viewing keys plus regulator viewing keys with time-bound, threshold-controlled scope. ISO 20022 message interpreters handle SWIFT compatibility; ERC-3643 handles compliance gating where the asset is a regulated security. ### Decision factors diff --git a/patterns/pattern-co-snark.md b/patterns/pattern-co-snark.md index 792abb3..6d40c7d 100644 --- a/patterns/pattern-co-snark.md +++ b/patterns/pattern-co-snark.md @@ -4,7 +4,7 @@ status: ready maturity: testnet type: standard layer: hybrid -last_reviewed: 2026-06-18 +last_reviewed: 2026-09-29 works-best-when: - A user or institution lacks the compute, memory, or battery to generate a zero-knowledge proof client-side and wants to offload the work without disclosing the witness. @@ -26,14 +26,14 @@ crops_profile: crops_context: cr: "Reaches `high` when the prover network is permissionless and bond-backed with slashing for Byzantine behaviour. Drops to `low` when a single proving service controls the pipeline." - o: "Proving-framework implementations are published under permissive licenses; production deployments may bundle proprietary orchestration." + o: "Proving-framework implementations are open source (TACEO co-snarks: MIT/Apache-2.0, with the co-circom components under GPL-3.0); production deployments may bundle proprietary orchestration." p: "The witness stays hidden from each individual prover and from the verifier. Metadata about who requested a proof, when, and against which circuit can still leak." - s: "Rides on the soundness of the underlying SNARK and the honest-majority assumption of the MPC protocol. Trusted-setup requirements inherit from the SNARK (Groth16 needs per-circuit setup; PLONK/KZG uses universal setup)." + s: "Rides on the soundness of the underlying SNARK and the corruption threshold of the MPC protocol (honest majority for GSZ, replicated, or Shamir sharing; one honest node for SPDZ-style protocols). Trusted-setup requirements inherit from the SNARK (Groth16 needs per-circuit setup; PLONK/KZG uses universal setup)." post_quantum: risk: high vector: "Pairing-based SNARKs (Groth16, PLONK/KZG) broken by CRQC. MPC communication inherits the underlying key-exchange assumptions." - mitigation: "co-STARK alternatives with hash-based commitments. See [Post-Quantum Threats](../domains/post-quantum.md)." + mitigation: "Collaborative versions of hash-based proof systems exist only as research (Ozdemir & Boneh adapt Fractal, at N-times proof size and verification cost). See [Post-Quantum Threats](../domains/post-quantum.md)." standards: [] @@ -44,20 +44,20 @@ related_patterns: open_source_implementations: - url: https://github.com/TaceoLabs/co-snarks - description: "co-SNARK proving framework supporting Groth16 and PLONK (research/testnet)" + description: "co-SNARK proving framework: Groth16 and PLONK (coCircom), UltraHonk (coNoir); README marks it experimental and un-audited" language: "Rust" --- ## Intent -Offload zero-knowledge proof generation to a distributed prover network without revealing the witness. The user secret-shares their witness across several proving nodes; the nodes jointly run an MPC protocol to compute a single SNARK proof; no individual node ever reconstructs the full witness. The resulting proof is identical to one produced client-side and is verified on-chain or off-chain with no changes on the verifier side. +Offload zero-knowledge proof generation to a distributed prover network without revealing the witness. The user secret-shares their witness across several proving nodes; the nodes jointly run an MPC protocol to compute a single SNARK proof; no individual node ever reconstructs the full witness. The resulting proof is indistinguishable from one produced client-side and is verified on-chain or off-chain with no changes on the verifier side. This pattern covers delegated proving for a single prover's witness. For multi-party joint computation over shared secret inputs (e.g. a consortium ledger), see `pattern-private-shared-state-cosnark`. ## Components - User or application holds the witness and wants a proof generated without exposing the witness. -- Share-distribution layer splits the witness using secret-sharing (additive or Shamir) and routes shares to proving nodes. +- Share-distribution layer splits the witness using secret-sharing (additive, replicated, or Shamir) and routes shares to proving nodes. - Distributed prover network runs the MPC protocol to jointly compute the SNARK. Each node sees only its share. - Coordinator sequences MPC rounds and assembles the final proof. Can be one of the proving nodes or a separate role. - Verifier checks the final proof exactly as it would check a client-side SNARK. No changes on the verification side. @@ -76,21 +76,21 @@ Guarantees: - The witness stays hidden from every individual prover and from the verifier. - Verification cost is identical to a client-side SNARK for the same circuit. -- Preserves trade secrets, user balances, or model weights under honest-majority assumptions. +- Preserves trade secrets, user balances, or model weights while fewer nodes collude than the MPC protocol tolerates. Threat model: - Soundness of the underlying SNARK, including any trusted-setup ceremony. -- Honest-majority assumption across proving nodes. A colluding majority can recover the witness and, in some constructions, forge proofs. +- Corruption threshold of the MPC protocol: honest majority for GSZ, replicated, or Shamir sharing (TACEO co-snarks uses 3-party replicated and Shamir sharing), or one honest node for SPDZ. A coalition above the threshold can recover the witness. It cannot forge proofs of false statements: knowledge soundness comes from the underlying SNARK even if all provers collude. - Non-censoring coordinator. A malicious coordinator can refuse to finalize or selectively drop requests. - Authenticated and confidential channels between nodes. Metadata about participation and timing is out of scope. ## Trade-offs -- Heavy communication overhead. Round count and bandwidth scale with both the number of provers and circuit size. +- Communication overhead. Bandwidth grows with circuit size and the number of provers; round count is sub-linear in constraint count. PLONK-style provers need more communication than Groth16. - New infrastructure requirements: MPC nodes, share routing, key management. - Liveness depends on all designated nodes remaining online through the proving session. Dropouts typically force a restart. -- Latency is higher than client-side proving because of MPC round trips; not suitable for sub-second proving budgets. +- Latency is higher than a single prover on the same hardware for small circuits, where MPC round trips dominate. Ozdemir & Boneh measure near-single-prover runtime for large circuits with honest-majority GSZ over 3 Gb/s links, 2x for SPDZ, and slowdown growing on low-bandwidth links. Not suitable for sub-second proving budgets. ## Example @@ -98,6 +98,6 @@ Threat model: ## See also -- [Collaborative zk-SNARKs (Ozdemir & Boneh, 2021)](https://eprint.iacr.org/2021/1530.pdf) +- [Collaborative zk-SNARKs (Ozdemir & Boneh, USENIX Security 2022)](https://eprint.iacr.org/2021/1530.pdf) - [TACEO private proof delegation](https://core.taceo.io/articles/private-proof-delegation/) - [TACEO Merces vendor page](../vendors/taceo-merces.md) diff --git a/patterns/pattern-erc3643-rwa.md b/patterns/pattern-erc3643-rwa.md index 6d160d5..b2fcb71 100644 --- a/patterns/pattern-erc3643-rwa.md +++ b/patterns/pattern-erc3643-rwa.md @@ -4,7 +4,7 @@ status: ready maturity: production type: standard layer: L1 -last_reviewed: 2026-08-11 +last_reviewed: 2026-09-29 works-best-when: - Regulatory compliance is mandatory. @@ -27,13 +27,13 @@ crops_profile: crops_context: cr: "Investor-initiated transfers are gated by the identity registry and compliance modules. The standard also gives owner- and agent-controlled administrative paths such as freezing and forced transfer, so censorship resistance is structurally `none` without strong governance constraints." - o: "Standard specification is open and the reference implementations are source-available, but claim issuer ecosystems are gatekept. Could reach `yes` by requiring copyleft licensing on compliance modules and a permissionless attestation registry for claim issuers." + o: "Standard specification is open and the reference implementations (T-REX, ONCHAINID) are open source under GPL-3.0, but claim issuer ecosystems are gatekept. Could reach `yes` by requiring copyleft licensing on third-party compliance modules and a permissionless attestation registry for claim issuers." p: "Identities and transfer parameters are public on chain. Could reach `partial` by replacing on-chain identity checks with zero-knowledge proofs of claim validity, enabling transfer validation without exposing PII." s: "Rides on correctness of the compliance modules and operational security of the token-agent key. Could reach `high` with multisig governance and time-locked upgrades on the issuer admin path." post_quantum: risk: medium - vector: "ECDSA signatures on agent and holder keys are broken by a CRQC. HNDL risk is moderate since on-chain identity data is public but linkable to off-chain PII." + vector: "ECDSA signatures on agent and holder keys are broken by a CRQC. On-chain identity data is public rather than encrypted, so there is no harvest-now-decrypt-later exposure; the risk is forged agent actions and forged identity claims." mitigation: "Migrate agent and governance keys to post-quantum signature schemes; anchor claims via hash-based attestation schemes rather than ECDSA-signed claims." standards: [ERC-3643, ERC-734, ERC-735] @@ -55,7 +55,7 @@ Enable compliant tokenization of real-world assets with built-in identity manage - On-chain identity contract per participant stores claims (KYC, accreditation, jurisdiction) and exposes verification endpoints. - Identity registry maps wallet addresses to identity contracts and gates who is eligible to hold the token. - Compliance module suite is a pluggable rules engine that evaluates per-transfer restrictions (caps, lockups, eligibility classes). -- Claim issuers are off-chain actors that sign claims written into identity contracts; the registry tracks trusted issuers. +- Claim issuers sign claims written into identity contracts and are represented on chain by claim-issuer contracts; the Trusted Issuers Registry lists which issuers the token trusts for which claim topics. ## Protocol @@ -78,7 +78,7 @@ Guarantees: - Every investor-initiated `transfer` or `transferFrom` path passes identity verification and compliance checks before execution. - Transfer rules can enforce KYC/AML status, investor accreditation, and jurisdictional restrictions automatically, subject to the configured claim issuers and compliance modules. - Administrative actions such as freezes and forced transfers are observable on chain, but their authority and policy constraints must be documented separately. -- Interface compatibility with ERC-20 tooling, with additional transfer restrictions opaque to the caller. +- Interface compatibility with ERC-20 tooling. Transfer restrictions sit outside the ERC-20 interface, but callers can pre-check them through the identity registry's `isVerified` and the compliance contract's `canTransfer`. Threat model: diff --git a/patterns/pattern-l2-encrypted-offchain-audit.md b/patterns/pattern-l2-encrypted-offchain-audit.md index 9c4469e..4601b11 100644 --- a/patterns/pattern-l2-encrypted-offchain-audit.md +++ b/patterns/pattern-l2-encrypted-offchain-audit.md @@ -4,7 +4,7 @@ status: ready maturity: testnet type: standard layer: hybrid -last_reviewed: 2026-09-18 +last_reviewed: 2026-09-29 works-best-when: - You need hidden amounts and positions with a minimal on-chain footprint. @@ -33,8 +33,8 @@ crops_context: post_quantum: risk: medium - vector: "Symmetric record encryption (AES-GCM) is PQ-safe; key wrapping under EC-based threshold schemes is broken by CRQC, with HNDL risk for long-retention archives." - mitigation: "Rotate wrapped keys using ML-KEM or hash-based threshold schemes before CRQC arrival. See [Post-Quantum Threats](../domains/post-quantum.md)." + vector: "Symmetric record encryption with AES-256-GCM is PQ-safe; key wrapping under EC-based threshold schemes is broken by CRQC, with HNDL risk for long-retention archives." + mitigation: "Wrap record keys under ML-KEM or lattice-based threshold decryption. Re-wrapping before CRQC arrival does not protect copies of the log harvested earlier, so long-retention archives need PQ wrapping from the start. See [Post-Quantum Threats](../domains/post-quantum.md)." standards: [ERC-7573, EIP-4844, EAS] @@ -59,7 +59,7 @@ Run settlement on a low-cost L2, publish only commitments and hashes on chain, a - Append-only encrypted log, replicated across regions, storing per-trade records keyed by a content address. - Per-trade symmetric key, wrapped to a threshold set of authorities so that disclosure requires a quorum rather than a single custodian. - Atomic settlement contract implementing cross-leg delivery-versus-payment over cash and asset legs. -- Access-logging attestations emitted on chain whenever a scoped key is issued or used. +- Access-logging attestations emitted on chain whenever a scoped key is issued. ## Protocol @@ -74,10 +74,10 @@ Run settlement on a low-cost L2, publish only commitments and hashes on chain, a Guarantees: -- Public observers see only commitments and hashes; amounts, identities, and positions remain off chain. +- Public observers see only commitments and hashes of the audit records; amounts, identities, and positions in the log remain off chain. The settlement legs expose what the L2 token transfers expose: plain ERC-20 transfers on a public L2 reveal sender, recipient, and amount unless the legs use confidential or netted balances. - Merkle anchoring makes the log tamper-evident: any silent rewrite breaks the on-chain root. -- Atomic delivery-versus-payment prevents one-sided settlement failure. -- Disclosure is scoped and logged, so access is auditable after the fact. +- Atomic delivery-versus-payment prevents one-sided settlement failure when both legs settle on the same L2. Across networks, [ERC-7573](https://ercs.ethereum.org/ERCS/erc-7573) settlement is conditional on the decryption oracle. +- Disclosure is scoped and logged, so access is auditable after the fact. A released record key cannot be revoked or time-limited. Threat model: @@ -95,10 +95,10 @@ Threat model: ## Example -A dealer sells a bond to an asset manager on the L2. The chain records only the commitment and the hourly Merkle root; full trade details sit encrypted in the log. Delivery-versus-payment finalizes atomically on chain. The national supervisor later receives a 24-hour scoped key for that record, and the issuance is attested on chain so the disclosure is itself auditable. +A dealer sells a bond to an asset manager on the L2. The audit contract records only the commitment and the hourly Merkle root; full trade details sit encrypted in the log. Delivery-versus-payment finalizes atomically on chain. The national supervisor later receives the decryption key for that record, and the issuance is attested on chain so the disclosure is itself auditable. ## See also - [ERC-7573 spec](https://ercs.ethereum.org/ERCS/erc-7573) - [EIP-4844 (blobs)](https://eips.ethereum.org/EIPS/eip-4844) -- [EAS docs](https://easscan.org/docs) +- [EAS docs](https://docs.attest.org/) diff --git a/patterns/pattern-private-pvp-stablecoins-erc7573.md b/patterns/pattern-private-pvp-stablecoins-erc7573.md index fcec47d..f088bf2 100644 --- a/patterns/pattern-private-pvp-stablecoins-erc7573.md +++ b/patterns/pattern-private-pvp-stablecoins-erc7573.md @@ -4,7 +4,7 @@ status: ready maturity: concept type: standard layer: hybrid -last_reviewed: 2026-09-18 +last_reviewed: 2026-09-29 works-best-when: - Two permissioned or regulated stablecoins (same L2 or cross-L2) must settle against each other with amount privacy, and both parties accept an oracle as the settlement trigger. @@ -30,8 +30,8 @@ crops_context: post_quantum: risk: medium - vector: "Signatures over oracle reports, cross-domain proofs, and shielded-layer zero-knowledge proofs use elliptic-curve primitives that are broken by a CRQC." - mitigation: "Migrate oracle attestations and cross-domain proofs to post-quantum signature schemes; compose with a post-quantum shielding layer on each leg. See [Post-Quantum Threats](../domains/post-quantum.md)." + vector: "Outcome keys are encrypted to the decryption oracle's public key and posted on chain. That encryption, signatures over oracle reports, cross-domain proofs, and shielded-layer zero-knowledge proofs typically use elliptic-curve primitives that are broken by a CRQC." + mitigation: "Move outcome-key encryption to a post-quantum KEM such as ML-KEM (FIPS 203); migrate oracle attestations and cross-domain proofs to post-quantum signature schemes; compose with a post-quantum shielding layer on each leg. See [Post-Quantum Threats](../domains/post-quantum.md)." standards: [ERC-7573, ERC-20] @@ -75,7 +75,7 @@ Guarantees: - Conditional settlement across two chains or two assets: the locked leg moves only on the key for the paying leg's actual result. Assuming verified key setup, correct contracts, an honest and available oracle, finality on both chains, and eventual key delivery and inclusion, both legs settle or the locked leg returns. - No cross-chain revert: if the success key is withheld after payment, the locked leg stays locked with no protocol exit, and the payer has already paid. Recovery is then bilateral or legal. -- Amount privacy: amounts are hidden on the chains themselves; only stakeholders and auditors with the viewing keys see the full trade. +- Amount privacy: amounts are hidden on the chains themselves; only stakeholders and auditors with the viewing keys see the full trade. This holds only if the [ERC-7573](https://ercs.ethereum.org/ERCS/erc-7573) contracts execute inside the shielded layer, because the standard's calls and events carry `amount`, `from`, and `to` in the clear. - Scoped disclosure: attestations log regulator access without exposing amounts publicly. Threat model: diff --git a/patterns/pattern-verifiable-attestation.md b/patterns/pattern-verifiable-attestation.md index 73e46c1..28e5532 100644 --- a/patterns/pattern-verifiable-attestation.md +++ b/patterns/pattern-verifiable-attestation.md @@ -4,7 +4,7 @@ status: ready maturity: production type: standard layer: hybrid -last_reviewed: 2026-09-18 +last_reviewed: 2026-09-29 works-best-when: - Smart-contract logic must gate on off-chain attested facts (KYC status, accreditation, membership). diff --git a/patterns/pattern-zk-kyc-ml-id-erc734-735.md b/patterns/pattern-zk-kyc-ml-id-erc734-735.md index 75fdffd..4dce438 100644 --- a/patterns/pattern-zk-kyc-ml-id-erc734-735.md +++ b/patterns/pattern-zk-kyc-ml-id-erc734-735.md @@ -4,7 +4,7 @@ status: ready maturity: testnet type: standard layer: hybrid -last_reviewed: 2026-06-18 +last_reviewed: 2026-09-29 works-best-when: - Onboarding identities must be publicly verifiable on-chain, for example to enable instant settlement without manual gate-keeping. @@ -33,7 +33,7 @@ crops_context: post_quantum: risk: high - vector: "Pairing-based proof systems used in current zero-knowledge machine-learning stacks are broken by a CRQC. HNDL risk applies to any long-lived on-chain proof that will still be relied on when CRQCs arrive." + vector: "Pairing-based proof systems used in current zero-knowledge machine-learning stacks (for example, Halo2 with KZG in EZKL) and ECDSA issuer signatures on ERC-735 claims are broken by a CRQC, which allows forged proofs and claims. Any long-lived on-chain claim still relied on when CRQCs arrive loses soundness. The zero-knowledge property does not rest on the broken assumptions, so harvested proofs do not expose the private inputs." mitigation: "Migrate the proof backend to hash-based systems (STARK or hash-based SNARK). PQ-safe arithmetization of institutional signature schemes currently imposes a large circuit-size penalty and remains a research frontier. See [Post-Quantum Threats](../domains/post-quantum.md)." standards: [ERC-734, ERC-735] @@ -48,7 +48,7 @@ open_source_implementations: description: "ONCHAINID reference implementation of ERC-734/735 (production)" language: "Solidity" - url: https://github.com/zkonduit/ezkl - description: "EZKL zero-knowledge machine-learning proving framework (research/testnet)" + description: "EZKL zero-knowledge machine-learning proving framework, Halo2-based (research/testnet; source-available, no open-source license since January 2024)" language: "Rust" --- @@ -98,12 +98,12 @@ Threat model: ## Example -A bank onboarding an investor runs a standard KYC and AML check off-chain. The bank's issuer service produces a zero-knowledge proof that the investor passed the bank's published policy. The investor submits the proof to their ERC-734/735 identity contract via the verifier contract, which writes an accredited-investor claim. A tokenized bond contract reads the claim when the investor subscribes and settles the transfer atomically, without ever seeing the investor's personal data. +A bank onboarding an investor runs a standard KYC and AML check off-chain. The bank's issuer service produces a zero-knowledge proof that the investor passed the bank's published policy. The investor submits the proof to their ERC-734/735 identity contract via the verifier contract, which writes a KYC/AML claim. A tokenized bond contract reads the claim when the investor subscribes and settles the transfer atomically, without ever seeing the investor's personal data. ## See also -- [ERC-734](https://eips.ethereum.org/EIPS/eip-734) -- [ERC-735](https://eips.ethereum.org/EIPS/eip-735) +- [ERC-734 (unmerged, GitHub issue)](https://github.com/ethereum/EIPs/issues/734) +- [ERC-735 (unmerged, GitHub issue)](https://github.com/ethereum/EIPs/issues/735) - [EZKL documentation](https://docs.ezkl.xyz/) - [Approach: Private Identity](../approaches/approach-private-identity.md) - [Domain: Identity and Compliance](../domains/identity-compliance.md) diff --git a/use-cases/private-rwa-tokenization.md b/use-cases/private-rwa-tokenization.md index b003afd..a0d367f 100644 --- a/use-cases/private-rwa-tokenization.md +++ b/use-cases/private-rwa-tokenization.md @@ -14,10 +14,10 @@ Regulated real-world assets (RWAs) are tokenized on-chain to enable permissioned ### Market Signals -- **Market size:** ~$15.8B on-chain RWA TVL (Sep 2025, [DefiLlama](https://defillama.com/protocols/RWA), excludes stablecoins); broader trackers (e.g. [rwa.xyz](https://app.rwa.xyz/)) report higher under wider scope -- **Growth:** [Coinbase](https://assets.ctfassets.net/sygt3q11s4a9/6oinXHvVekdIUw2Ch7yIQw/22d0185eba3c49322ce7cf0d287ea872/SOCQ2Report_final.pdf) reported ~245× growth, $85M (April 2020) to $21B (April 2025); different scope from DefiLlama, not directly comparable -- **Asset distribution:** Private credit (61%), Treasuries (30%), Commodities (7%), Institutional funds (2%) -- **Deployed categories:** [US Treasuries](https://app.rwa.xyz/treasuries), [Global Bonds](https://app.rwa.xyz/global-bonds), [Private Credits](https://app.rwa.xyz/private-credit), [Commodities](https://app.rwa.xyz/commodities), [Institutional Funds](https://app.rwa.xyz/institutional-funds), [Stocks](https://app.rwa.xyz/stocks) +- **Market size:** ~$38.6B distributed on-chain RWA value, excluding stablecoins (29 Sep 2026, [rwa.xyz](https://app.rwa.xyz/)); rwa.xyz counts a further ~$358B of [represented assets](https://rwa.xyz/blog/a-new-framework-for-tokenized-assets-distributed-and-represented), which are recorded on-chain but cannot leave the issuing platform or move peer-to-peer. [Binance Research](https://www.binance.com/en/research/analysis/the-rwa-activation-era), using [DefiLlama](https://defillama.com/rwa) data, reports $34.18B (15 Sep 2026) +- **Growth:** [Coinbase](https://assets.ctfassets.net/sygt3q11s4a9/6oinXHvVekdIUw2Ch7yIQw/22d0185eba3c49322ce7cf0d287ea872/SOCQ2Report_final.pdf) reported ~245× growth, $85M (April 2020) to $21B (April 2025), using RWA.xyz data under its methodology at the time; not directly comparable to the figures above +- **Asset distribution:** Share of distributed value (29 Sep 2026, rwa.xyz): US Treasuries (38%), credit (20%), commodities (13%), active strategies (10%), stocks (8%), private equity / venture capital (6%), non-US government debt (3%), real estate (<1%) +- **Deployed categories:** [US Treasuries](https://app.rwa.xyz/treasuries), [Non-US Government Debt](https://app.rwa.xyz/government-bonds), [Credit](https://app.rwa.xyz/credit), [Commodities](https://app.rwa.xyz/commodities), [Active Strategies](https://app.rwa.xyz/active-strategies), [Private Equity / VC](https://app.rwa.xyz/private-equity-venture-capital), [Real Estate](https://app.rwa.xyz/real-estate), [Stocks](https://app.rwa.xyz/stocks) ## 3) Actors