From 5b83e152c342834dbbdda733fcbcd66db51c96d3 Mon Sep 17 00:00:00 2001 From: rymnc <43716372+rymnc@users.noreply.github.com> Date: Thu, 9 Jul 2026 18:08:55 +0530 Subject: [PATCH] chore: cleanup, rebrand --- .claude/CLAUDE.md | 8 +- .coderabbit.yaml | 2 +- .github/markdown-link-check-config.json | 2 +- .husky/pre-commit | 2 +- .vale.ini | 32 ++-- .vale/styles/{IPTF => EthSystems}/Hedging.yml | 2 +- .../styles/{IPTF => EthSystems}/Marketing.yml | 2 +- .../{IPTF => EthSystems}/Terminology.yml | 2 +- .../Vocab/{IPTF => EthSystems}/accept.txt | 2 +- CHANGELOG.md | 180 +++++++++--------- CONTRIBUTING.md | 2 +- GLOSSARY.md | 4 +- Makefile | 4 +- QA-AUDIT.md | 12 +- README.md | 6 +- approaches/_template.md | 6 +- approaches/approach-dvp-atomic-settlement.md | 4 +- approaches/approach-private-bonds.md | 4 +- approaches/approach-private-identity.md | 4 +- approaches/approach-private-payments.md | 2 +- .../approach-private-trade-settlement.md | 2 +- approaches/approach-white-label-deployment.md | 4 +- domains/post-quantum.md | 20 +- package.json | 6 +- patterns/README.md | 24 +-- patterns/_template.md | 14 +- patterns/pattern-plasma-stateless-privacy.md | 4 +- patterns/pattern-privacy-l2s.md | 4 +- patterns/pattern-shielding.md | 8 +- rfps/README.md | 6 +- rfps/rfp-benchmark-dashboard.md | 10 +- rfps/rfp-trust-assurance.md | 4 +- scripts/check-terminology.js | 2 +- scripts/llm-review.js | 10 +- scripts/package.json | 4 +- scripts/schemas/jurisdiction.json | 6 +- scripts/schemas/pattern.json | 6 +- scripts/schemas/use-case.json | 6 +- scripts/schemas/vendor.json | 6 +- scripts/validate-patterns.js | 2 +- use-cases/README.md | 2 +- use-cases/private-bonds.md | 4 +- use-cases/private-derivatives.md | 2 +- use-cases/private-government-debt.md | 2 +- use-cases/private-identity.md | 4 +- use-cases/private-oracles.md | 4 +- use-cases/private-payments.md | 4 +- use-cases/private-procurement.md | 2 +- use-cases/private-registry.md | 6 +- use-cases/private-stablecoins.md | 14 +- use-cases/private-supply-chain.md | 2 +- use-cases/resilient-disbursement-rails.md | 4 +- use-cases/resilient-identity-continuity.md | 2 +- vendors/README.md | 4 +- vendors/fairblock.md | 2 +- vendors/fhenix.md | 12 +- vendors/miden.md | 2 +- vendors/peer.md | 8 +- vendors/space-and-time.md | 2 +- vendors/tx-shield.md | 8 +- 60 files changed, 261 insertions(+), 259 deletions(-) rename .vale/styles/{IPTF => EthSystems}/Hedging.yml (97%) rename .vale/styles/{IPTF => EthSystems}/Marketing.yml (97%) rename .vale/styles/{IPTF => EthSystems}/Terminology.yml (97%) rename .vale/styles/Vocab/{IPTF => EthSystems}/accept.txt (95%) diff --git a/.claude/CLAUDE.md b/.claude/CLAUDE.md index ea84192..9925c84 100644 --- a/.claude/CLAUDE.md +++ b/.claude/CLAUDE.md @@ -1,8 +1,8 @@ -# IPTF Map - AI Assistant Context +# EthSystems Map - AI Assistant Context ## Project Overview -The **Institutional Privacy Task Force (IPTF) Map** is a public reference repository for privacy-preserving solutions in enterprise/institutional Ethereum adoption. Contains technical patterns, use cases, regulatory frameworks, and vendor evaluations. +The **EthSystems Map** is a public reference repository for privacy-preserving solutions in enterprise/institutional Ethereum adoption. Contains technical patterns, use cases, regulatory frameworks, and vendor evaluations. **License:** CC0 (public domain) @@ -80,11 +80,11 @@ Each directory has `_template.md` and `README.md`. Key structures: 1. Add entry to `[Unreleased]` section 2. Use semantic prefix: `feat(pattern):`, `feat(vendor):`, `fix:`, `docs:`, etc. 3. Link to the file: `[Name](path/to/file.md)` -4. Link to PR: `([#123](https://github.com/ethereum/iptf-map/pull/123))` +4. Link to PR: `([#123](https://github.com/ethsystems/map/pull/123))` Example: ```markdown -- feat(pattern): [New pattern name](patterns/pattern-slug.md) ([#123](https://github.com/ethereum/iptf-map/pull/123)) +- feat(pattern): [New pattern name](patterns/pattern-slug.md) ([#123](https://github.com/ethsystems/map/pull/123)) ``` ## Content Organization diff --git a/.coderabbit.yaml b/.coderabbit.yaml index 128d2ef..50c347c 100644 --- a/.coderabbit.yaml +++ b/.coderabbit.yaml @@ -57,7 +57,7 @@ reviews: **Structure & frontmatter:** Validate against the template at `vendors/_template.md`. **Ethereum alignment (CRITICAL):** - Per `vendors/README.md`, IPTF only lists vendors whose products are Ethereum-aligned. + Per `vendors/README.md`, EthSystems only lists vendors whose products are Ethereum-aligned. Check that the product is built for or deployed on Ethereum mainnet or production L2s, or is a multichain solution that benefits the Ethereum ecosystem (supports EIPs/ERCs, advances shared privacy patterns, or brings institutional adoption to Ethereum). diff --git a/.github/markdown-link-check-config.json b/.github/markdown-link-check-config.json index b0f235e..c6df581 100644 --- a/.github/markdown-link-check-config.json +++ b/.github/markdown-link-check-config.json @@ -124,7 +124,7 @@ "pattern": "^approaches/approach-privacy-standards-survey\\.md$" }, { - "pattern": "^https://github\\.com/ethereum/iptf-map/compare/" + "pattern": "^https://github\\.com/ethsystems/map/compare/" }, { "pattern": "^https://forum\\.l2beat\\.com/t/the-data-availability-risk-framework/318" diff --git a/.husky/pre-commit b/.husky/pre-commit index 76fa324..0bae740 100644 --- a/.husky/pre-commit +++ b/.husky/pre-commit @@ -1,4 +1,4 @@ -# Pre-commit hook for IPTF Map +# Pre-commit hook for EthSystems Map # Runs validation checks on staged markdown files # Run lint-staged for markdown validation diff --git a/.vale.ini b/.vale.ini index b3843df..773e36e 100644 --- a/.vale.ini +++ b/.vale.ini @@ -1,4 +1,4 @@ -# Vale prose linter configuration for IPTF Map +# Vale prose linter configuration for EthSystems Map # See https://vale.sh/docs/topics/config/ StylesPath = .vale/styles @@ -6,7 +6,7 @@ StylesPath = .vale/styles MinAlertLevel = suggestion [*.md] -BasedOnStyles = IPTF +BasedOnStyles = EthSystems # Skip code blocks and frontmatter BlockIgnores = (?s) *```.*?``` @@ -14,7 +14,7 @@ TokenIgnores = (`[^`]+`) # Content directories - full linting [patterns/*.md] -BasedOnStyles = IPTF +BasedOnStyles = EthSystems # Skip template and README Skip = _template.md, README.md # Disable overly strict rules for technical documentation @@ -23,35 +23,35 @@ write-good.TooWordy = NO write-good.Passive = suggestion [vendors/*.md] -BasedOnStyles = IPTF, +BasedOnStyles = EthSystems, Skip = _template.md, README.md write-good.E-Prime = NO write-good.TooWordy = NO write-good.Passive = suggestion [approaches/*.md] -BasedOnStyles = IPTF, +BasedOnStyles = EthSystems, Skip = _template.md, README.md write-good.E-Prime = NO write-good.TooWordy = NO write-good.Passive = suggestion [use-cases/*.md] -BasedOnStyles = IPTF, +BasedOnStyles = EthSystems, Skip = _template.md, README.md write-good.E-Prime = NO write-good.TooWordy = NO write-good.Passive = suggestion [jurisdictions/*.md] -BasedOnStyles = IPTF, +BasedOnStyles = EthSystems, Skip = _template.md, README.md write-good.E-Prime = NO write-good.TooWordy = NO write-good.Passive = suggestion [domains/*.md] -BasedOnStyles = IPTF, +BasedOnStyles = EthSystems, Skip = _template.md, README.md write-good.E-Prime = NO write-good.TooWordy = NO @@ -59,17 +59,17 @@ write-good.Passive = suggestion # Lighter linting for root docs [README.md] -BasedOnStyles = IPTF -IPTF.Hedging = NO +BasedOnStyles = EthSystems +EthSystems.Hedging = NO [GLOSSARY.md] -BasedOnStyles = IPTF -IPTF.Marketing = NO -IPTF.Hedging = NO +BasedOnStyles = EthSystems +EthSystems.Marketing = NO +EthSystems.Hedging = NO [CONTRIBUTING.md] -BasedOnStyles = IPTF -IPTF.Hedging = NO +BasedOnStyles = EthSystems +EthSystems.Hedging = NO [CHANGELOG.md] -BasedOnStyles = IPTF +BasedOnStyles = EthSystems diff --git a/.vale/styles/IPTF/Hedging.yml b/.vale/styles/EthSystems/Hedging.yml similarity index 97% rename from .vale/styles/IPTF/Hedging.yml rename to .vale/styles/EthSystems/Hedging.yml index 4598329..46b64ef 100644 --- a/.vale/styles/IPTF/Hedging.yml +++ b/.vale/styles/EthSystems/Hedging.yml @@ -1,4 +1,4 @@ -# IPTF AI Hedging Language Detector +# EthSystems AI Hedging Language Detector # Catches non-committal language often produced by LLMs # Technical docs should be precise and confident diff --git a/.vale/styles/IPTF/Marketing.yml b/.vale/styles/EthSystems/Marketing.yml similarity index 97% rename from .vale/styles/IPTF/Marketing.yml rename to .vale/styles/EthSystems/Marketing.yml index 593da04..ed9b288 100644 --- a/.vale/styles/IPTF/Marketing.yml +++ b/.vale/styles/EthSystems/Marketing.yml @@ -1,4 +1,4 @@ -# IPTF Marketing Language Detector +# EthSystems Marketing Language Detector # Catches promotional/marketing language that should not appear in technical docs # Mirrors patterns from .marketing-exceptions.txt diff --git a/.vale/styles/IPTF/Terminology.yml b/.vale/styles/EthSystems/Terminology.yml similarity index 97% rename from .vale/styles/IPTF/Terminology.yml rename to .vale/styles/EthSystems/Terminology.yml index c454186..08118c7 100644 --- a/.vale/styles/IPTF/Terminology.yml +++ b/.vale/styles/EthSystems/Terminology.yml @@ -1,4 +1,4 @@ -# IPTF Terminology Consistency +# EthSystems Terminology Consistency # Enforces canonical spellings from GLOSSARY.md # See also: scripts/check-terminology.js for programmatic checking diff --git a/.vale/styles/Vocab/IPTF/accept.txt b/.vale/styles/Vocab/EthSystems/accept.txt similarity index 95% rename from .vale/styles/Vocab/IPTF/accept.txt rename to .vale/styles/Vocab/EthSystems/accept.txt index c14757e..4d7c841 100644 --- a/.vale/styles/Vocab/IPTF/accept.txt +++ b/.vale/styles/Vocab/EthSystems/accept.txt @@ -1,4 +1,4 @@ -# IPTF Accepted Vocabulary +# EthSystems Accepted Vocabulary # Technical terms from GLOSSARY.md and blockchain domain # Core privacy concepts diff --git a/CHANGELOG.md b/CHANGELOG.md index 2b786a6..3f29a37 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,45 +1,45 @@ # Changelog -All notable changes to the IPTF Map are documented here. +All notable changes to the EthSystems Map are documented here. ## [Unreleased] ## [0.4.0] - 2026-07-02 -23 commits, 166 files changed since [v0.3.0](https://github.com/ethereum/iptf-map/releases/tag/v0.3.0) (Apr 2026). Major additions: resilience use cases (civic participation, disbursement rails, identity continuity), I2U protection patterns, pattern/approach schema v2 (strict flip) with CROPS and post-quantum analysis, domain reframing beyond FIs, and a Q2 2026 content QA audit. - -- chore: Q2 2026 content audit pass across all patterns, use cases, approaches, domains, jurisdictions, and vendors; corrections tracked in [QA-AUDIT.md](QA-AUDIT.md) ([#130](https://github.com/ethereum/iptf-map/pull/130)) -- chore: remove the dormant `weekly-updates/` directory and `scripts/weekly-summary.sh` (single entry, unused since 2026-01) ([#130](https://github.com/ethereum/iptf-map/pull/130)) -- docs(domains): reframe [Domains index](domains/README.md), [Payments](domains/payments.md), [Identity & Compliance](domains/identity-compliance.md), [Funds & Assets](domains/funds-assets.md), [Trading](domains/trading.md), and [Data & Oracles](domains/data-oracles.md) to cover public-sector, NGO, and resilience contexts alongside FIs; add [Civic Coordination & Governance](domains/governance.md) domain; add `governance` to the use-case schema enum ([#170](https://github.com/ethereum/iptf-map/pull/170), closes [#169](https://github.com/ethereum/iptf-map/issues/169)) -- refactor(use-cases): rename `## 2) Additional Business Context` to `## 2) Additional Context` across [_template](use-cases/_template.md) and 23 use-case cards; strip reader-facing "Confidential context" placeholder line from 20 private-* cards ([#170](https://github.com/ethereum/iptf-map/pull/170), closes [#169](https://github.com/ethereum/iptf-map/issues/169)) -- feat(use-case): [Resilient Civic Participation](use-cases/resilient-civic-participation.md) -- credentialed petition protocol with per-signer forward-secure ratcheting, blob-anchored signature batches, and a chain-state-only resolution SNARK (ECI, repository governance, workplace organising); adds [Approach: Civic Participation](approaches/approach-civic-participation.md) and generic patterns [Forward-Secure Pseudorandom Tree](patterns/pattern-forward-secure-pseudorandom-tree.md) and [Blob-Anchored State With KZG Dispute](patterns/pattern-blob-anchored-state-with-dispute.md) ([#165](https://github.com/ethereum/iptf-map/pull/165)) -- chore(approach): I2U analysis pass across [Private Payments](approaches/approach-private-payments.md), [White-Label Deployment](approaches/approach-white-label-deployment.md), and [Private Broadcasting](approaches/approach-private-broadcasting.md). Adds [Self-Custodial Deployment](approaches/approach-white-label-deployment.md) (context: i2u) to White-Label. Relabels L1 Shielded Payments, Stateless Plasma, and Private Rollups from `i2i` to `both` where the underlying technology already serves end users. Closes [`#124`](https://github.com/ethereum/iptf-map/issues/124) ([`#167`](https://github.com/ethereum/iptf-map/pull/167)) -- feat(pattern): [Private Information Retrieval](patterns/pattern-private-information-retrieval.md), plugs client-side query leakage in shielded-pool path retrieval and note discovery, and applies to any indexed lookup whose index is itself sensitive ([`#168`](https://github.com/ethereum/iptf-map/pull/168), companion to [iptf-pocs#68](https://github.com/ethereum/iptf-pocs/issues/68)) -- feat(pattern): [Immutable Guarantees](patterns/pattern-immutable-guarantees.md), separating mutable operational parameters from immutable safety invariants, with a published invariant set that survives hostile operators ([#166](https://github.com/ethereum/iptf-map/pull/166), closes [#127](https://github.com/ethereum/iptf-map/issues/127)) -- fix(domains): refresh Adjacent vendors across [payments](domains/payments.md), [custody](domains/custody.md), [data-oracles](domains/data-oracles.md), [funds-assets](domains/funds-assets.md), [identity-compliance](domains/identity-compliance.md), and [trading](domains/trading.md). Remove Chainlink ACE (weak CROPS fit on openness and censorship resistance) and backfill with CROPS-aligned vendors already documented in [vendors/](vendors/) ([#164](https://github.com/ethereum/iptf-map/pull/164)). -- fix(ci): stabilize [full markdown link checks](.github/workflows/link-check-full.yml) by ignoring bot-blocked external references and repairing stale internal links ([#163](https://github.com/ethereum/iptf-map/pull/163)) -- feat(schema): flip [pattern.json](scripts/schemas/pattern.json) and [validate-patterns.js](scripts/validate-patterns.js) to strict v2. All v1 aliases (`os`, `privacy`, `security` CROPS keys; `PoC`/`pilot`/`prod`/`experimental` maturity values; `privacy_goal`, `assumptions`, `dependencies`, `## Ingredients`, `## Guarantees` section names) now fail validation instead of warning. ([#156](https://github.com/ethereum/iptf-map/pull/156)) -- feat(schema): approach template v2 -- replace [_template.md](approaches/_template.md) with the v2 skeleton from [#151](https://github.com/ethereum/iptf-map/issues/151) and update [validate-patterns.js](scripts/validate-patterns.js) to check v2 sections (`## Problem framing`, `## Approaches`, `## Comparison`, `## Persona perspectives`, `## Recommendation`, `## Open questions`), required frontmatter (`title`, `status`, `last_reviewed`, `use_case`, `primary_patterns`), and the `^Approach:\s` title prefix. Lenient mode (warnings only) until a future strict-flip ([#161](https://github.com/ethereum/iptf-map/pull/161)) -- refactor(approach): port 9 approach cards in [approaches/](approaches/) to v2 schema (frontmatter, per-sub-approach YAML blocks, comparison table, persona perspectives, recommendation) ([#160](https://github.com/ethereum/iptf-map/pull/160), [#151](https://github.com/ethereum/iptf-map/issues/151)) -- chore(approach): remove `approaches/approach-privacy-standards-survey.md` (does not fit v2 schema; relocation tracked in [#159](https://github.com/ethereum/iptf-map/issues/159)) ([#160](https://github.com/ethereum/iptf-map/pull/160)) -- feat(use-case): [Resilient Disbursement Rails](use-cases/resilient-disbursement-rails.md) -- humanitarian disbursement to recipients in adversarial jurisdictions, with off-ramp unlinkability as the primary cryptographic requirement ([#157](https://github.com/ethereum/iptf-map/pull/157)) -- feat(pattern): [Forward-Secure Signatures](patterns/pattern-forward-secure-signatures.md), [Mesh Store-and-Forward Submission](patterns/pattern-mesh-store-forward-submission.md), [Relay-Mediated Proving](patterns/pattern-relay-mediated-proving.md), and [Recipient-Derived Receive Addresses](patterns/pattern-recipient-derived-receive-addresses.md) -- generic patterns supporting constrained-signer participation in proof-gated systems ([#157](https://github.com/ethereum/iptf-map/pull/157)) -- feat(approach): Resilient Disbursement Rails section in [Private Payments](approaches/approach-private-payments.md) for humanitarian disbursement under adversarial-jurisdiction threat models ([#157](https://github.com/ethereum/iptf-map/pull/157)) -- feat(schema): pattern template v2 -- structured `crops_context`, `post_quantum`, `context_differentiation`, `related_patterns`, `open_source_implementations`, `sub_patterns`, and `type: meta` flag in [_template.md](patterns/_template.md), [pattern.json](scripts/schemas/pattern.json), and [validate-patterns.js](scripts/validate-patterns.js). Validator stays permissive during migration; existing v1 patterns continue to pass with deprecation warnings. ([#152](https://github.com/ethereum/iptf-map/pull/152), [#150](https://github.com/ethereum/iptf-map/issues/150)) -- feat(pattern): [ZK Wrappers](patterns/pattern-zk-wrappers.md) -- verify off-chain signatures (passport, DKIM, attestation) inside a ZK circuit for attribute proofs without credential disclosure ([#153](https://github.com/ethereum/iptf-map/pull/153)) -- feat(pattern): [Social Recovery](patterns/pattern-social-recovery.md) -- guardian-quorum rotation of account keys or identity anchors without issuer or custodian involvement ([#153](https://github.com/ethereum/iptf-map/pull/153)) -- feat(pattern): [Onion Routing](patterns/pattern-onion-routing.md) -- Tor-based multi-hop relay for sender IP anonymity (PSE tor-js, Flashbots .onion) ([#146](https://github.com/ethereum/iptf-map/pull/146)) -- feat(pattern): [Mixnet Anonymity](patterns/pattern-mixnet-anonymity.md) -- batching, reordering, and cover traffic for strongest network anonymity (Nym, HOPR) ([#146](https://github.com/ethereum/iptf-map/pull/146)) -- refactor(pattern): split [Network-Level Anonymity](patterns/pattern-network-anonymity.md) into umbrella pattern linking onion routing, mixnet, and TEE sub-patterns ([#146](https://github.com/ethereum/iptf-map/pull/146)) -- feat(pattern): [User-Controlled Viewing Keys](patterns/pattern-user-controlled-viewing-keys.md) -- user-held viewing key custody for I2U privacy sovereignty ([#146](https://github.com/ethereum/iptf-map/pull/146)) -- feat(pattern): enhance [Network-Level Anonymity](patterns/pattern-network-anonymity.md) with I2U analysis ([#146](https://github.com/ethereum/iptf-map/pull/146)) -- feat(pattern): [zk-promises](patterns/pattern-zk-promises.md) -- stateful anonymous credentials with async callbacks for blind compliance enforcement ([#132](https://github.com/ethereum/iptf-map/pull/132)) -- feat(pattern): [Proof of Innocence](patterns/pattern-proof-of-innocence.md) -- association set membership/exclusion proofs for compliance without surveillance ([#132](https://github.com/ethereum/iptf-map/pull/132)) -- feat(approach|use-case): [Resilient Identity Continuity](use-cases/resilient-identity-continuity.md) and [added approach](approaches/approach-private-identity.md) ([#145](https://github.com/ethereum/iptf-map/pull/145)) +23 commits, 166 files changed since [v0.3.0](https://github.com/ethsystems/map/releases/tag/v0.3.0) (Apr 2026). Major additions: resilience use cases (civic participation, disbursement rails, identity continuity), I2U protection patterns, pattern/approach schema v2 (strict flip) with CROPS and post-quantum analysis, domain reframing beyond FIs, and a Q2 2026 content QA audit. + +- chore: Q2 2026 content audit pass across all patterns, use cases, approaches, domains, jurisdictions, and vendors; corrections tracked in [QA-AUDIT.md](QA-AUDIT.md) ([#130](https://github.com/ethsystems/map/pull/130)) +- chore: remove the dormant `weekly-updates/` directory and `scripts/weekly-summary.sh` (single entry, unused since 2026-01) ([#130](https://github.com/ethsystems/map/pull/130)) +- docs(domains): reframe [Domains index](domains/README.md), [Payments](domains/payments.md), [Identity & Compliance](domains/identity-compliance.md), [Funds & Assets](domains/funds-assets.md), [Trading](domains/trading.md), and [Data & Oracles](domains/data-oracles.md) to cover public-sector, NGO, and resilience contexts alongside FIs; add [Civic Coordination & Governance](domains/governance.md) domain; add `governance` to the use-case schema enum ([#170](https://github.com/ethsystems/map/pull/170), closes [#169](https://github.com/ethsystems/map/issues/169)) +- refactor(use-cases): rename `## 2) Additional Business Context` to `## 2) Additional Context` across [_template](use-cases/_template.md) and 23 use-case cards; strip reader-facing "Confidential context" placeholder line from 20 private-* cards ([#170](https://github.com/ethsystems/map/pull/170), closes [#169](https://github.com/ethsystems/map/issues/169)) +- feat(use-case): [Resilient Civic Participation](use-cases/resilient-civic-participation.md) -- credentialed petition protocol with per-signer forward-secure ratcheting, blob-anchored signature batches, and a chain-state-only resolution SNARK (ECI, repository governance, workplace organising); adds [Approach: Civic Participation](approaches/approach-civic-participation.md) and generic patterns [Forward-Secure Pseudorandom Tree](patterns/pattern-forward-secure-pseudorandom-tree.md) and [Blob-Anchored State With KZG Dispute](patterns/pattern-blob-anchored-state-with-dispute.md) ([#165](https://github.com/ethsystems/map/pull/165)) +- chore(approach): I2U analysis pass across [Private Payments](approaches/approach-private-payments.md), [White-Label Deployment](approaches/approach-white-label-deployment.md), and [Private Broadcasting](approaches/approach-private-broadcasting.md). Adds [Self-Custodial Deployment](approaches/approach-white-label-deployment.md) (context: i2u) to White-Label. Relabels L1 Shielded Payments, Stateless Plasma, and Private Rollups from `i2i` to `both` where the underlying technology already serves end users. Closes [`#124`](https://github.com/ethsystems/map/issues/124) ([`#167`](https://github.com/ethsystems/map/pull/167)) +- feat(pattern): [Private Information Retrieval](patterns/pattern-private-information-retrieval.md), plugs client-side query leakage in shielded-pool path retrieval and note discovery, and applies to any indexed lookup whose index is itself sensitive ([`#168`](https://github.com/ethsystems/map/pull/168), companion to [ethsystems/pocs#68](https://github.com/ethsystems/pocs/issues/68)) +- feat(pattern): [Immutable Guarantees](patterns/pattern-immutable-guarantees.md), separating mutable operational parameters from immutable safety invariants, with a published invariant set that survives hostile operators ([#166](https://github.com/ethsystems/map/pull/166), closes [#127](https://github.com/ethsystems/map/issues/127)) +- fix(domains): refresh Adjacent vendors across [payments](domains/payments.md), [custody](domains/custody.md), [data-oracles](domains/data-oracles.md), [funds-assets](domains/funds-assets.md), [identity-compliance](domains/identity-compliance.md), and [trading](domains/trading.md). Remove Chainlink ACE (weak CROPS fit on openness and censorship resistance) and backfill with CROPS-aligned vendors already documented in [vendors/](vendors/) ([#164](https://github.com/ethsystems/map/pull/164)). +- fix(ci): stabilize [full markdown link checks](.github/workflows/link-check-full.yml) by ignoring bot-blocked external references and repairing stale internal links ([#163](https://github.com/ethsystems/map/pull/163)) +- feat(schema): flip [pattern.json](scripts/schemas/pattern.json) and [validate-patterns.js](scripts/validate-patterns.js) to strict v2. All v1 aliases (`os`, `privacy`, `security` CROPS keys; `PoC`/`pilot`/`prod`/`experimental` maturity values; `privacy_goal`, `assumptions`, `dependencies`, `## Ingredients`, `## Guarantees` section names) now fail validation instead of warning. ([#156](https://github.com/ethsystems/map/pull/156)) +- feat(schema): approach template v2 -- replace [_template.md](approaches/_template.md) with the v2 skeleton from [#151](https://github.com/ethsystems/map/issues/151) and update [validate-patterns.js](scripts/validate-patterns.js) to check v2 sections (`## Problem framing`, `## Approaches`, `## Comparison`, `## Persona perspectives`, `## Recommendation`, `## Open questions`), required frontmatter (`title`, `status`, `last_reviewed`, `use_case`, `primary_patterns`), and the `^Approach:\s` title prefix. Lenient mode (warnings only) until a future strict-flip ([#161](https://github.com/ethsystems/map/pull/161)) +- refactor(approach): port 9 approach cards in [approaches/](approaches/) to v2 schema (frontmatter, per-sub-approach YAML blocks, comparison table, persona perspectives, recommendation) ([#160](https://github.com/ethsystems/map/pull/160), [#151](https://github.com/ethsystems/map/issues/151)) +- chore(approach): remove `approaches/approach-privacy-standards-survey.md` (does not fit v2 schema; relocation tracked in [#159](https://github.com/ethsystems/map/issues/159)) ([#160](https://github.com/ethsystems/map/pull/160)) +- feat(use-case): [Resilient Disbursement Rails](use-cases/resilient-disbursement-rails.md) -- humanitarian disbursement to recipients in adversarial jurisdictions, with off-ramp unlinkability as the primary cryptographic requirement ([#157](https://github.com/ethsystems/map/pull/157)) +- feat(pattern): [Forward-Secure Signatures](patterns/pattern-forward-secure-signatures.md), [Mesh Store-and-Forward Submission](patterns/pattern-mesh-store-forward-submission.md), [Relay-Mediated Proving](patterns/pattern-relay-mediated-proving.md), and [Recipient-Derived Receive Addresses](patterns/pattern-recipient-derived-receive-addresses.md) -- generic patterns supporting constrained-signer participation in proof-gated systems ([#157](https://github.com/ethsystems/map/pull/157)) +- feat(approach): Resilient Disbursement Rails section in [Private Payments](approaches/approach-private-payments.md) for humanitarian disbursement under adversarial-jurisdiction threat models ([#157](https://github.com/ethsystems/map/pull/157)) +- feat(schema): pattern template v2 -- structured `crops_context`, `post_quantum`, `context_differentiation`, `related_patterns`, `open_source_implementations`, `sub_patterns`, and `type: meta` flag in [_template.md](patterns/_template.md), [pattern.json](scripts/schemas/pattern.json), and [validate-patterns.js](scripts/validate-patterns.js). Validator stays permissive during migration; existing v1 patterns continue to pass with deprecation warnings. ([#152](https://github.com/ethsystems/map/pull/152), [#150](https://github.com/ethsystems/map/issues/150)) +- feat(pattern): [ZK Wrappers](patterns/pattern-zk-wrappers.md) -- verify off-chain signatures (passport, DKIM, attestation) inside a ZK circuit for attribute proofs without credential disclosure ([#153](https://github.com/ethsystems/map/pull/153)) +- feat(pattern): [Social Recovery](patterns/pattern-social-recovery.md) -- guardian-quorum rotation of account keys or identity anchors without issuer or custodian involvement ([#153](https://github.com/ethsystems/map/pull/153)) +- feat(pattern): [Onion Routing](patterns/pattern-onion-routing.md) -- Tor-based multi-hop relay for sender IP anonymity (PSE tor-js, Flashbots .onion) ([#146](https://github.com/ethsystems/map/pull/146)) +- feat(pattern): [Mixnet Anonymity](patterns/pattern-mixnet-anonymity.md) -- batching, reordering, and cover traffic for strongest network anonymity (Nym, HOPR) ([#146](https://github.com/ethsystems/map/pull/146)) +- refactor(pattern): split [Network-Level Anonymity](patterns/pattern-network-anonymity.md) into umbrella pattern linking onion routing, mixnet, and TEE sub-patterns ([#146](https://github.com/ethsystems/map/pull/146)) +- feat(pattern): [User-Controlled Viewing Keys](patterns/pattern-user-controlled-viewing-keys.md) -- user-held viewing key custody for I2U privacy sovereignty ([#146](https://github.com/ethsystems/map/pull/146)) +- feat(pattern): enhance [Network-Level Anonymity](patterns/pattern-network-anonymity.md) with I2U analysis ([#146](https://github.com/ethsystems/map/pull/146)) +- feat(pattern): [zk-promises](patterns/pattern-zk-promises.md) -- stateful anonymous credentials with async callbacks for blind compliance enforcement ([#132](https://github.com/ethsystems/map/pull/132)) +- feat(pattern): [Proof of Innocence](patterns/pattern-proof-of-innocence.md) -- association set membership/exclusion proofs for compliance without surveillance ([#132](https://github.com/ethsystems/map/pull/132)) +- feat(approach|use-case): [Resilient Identity Continuity](use-cases/resilient-identity-continuity.md) and [added approach](approaches/approach-private-identity.md) ([#145](https://github.com/ethsystems/map/pull/145)) ### Removed -- chore: Retire `PRD-IPTF-PUBLIC-Q1-2026.md` -- Q1 closed; remaining unfinished items tracked in [#143](https://github.com/ethereum/iptf-map/issues/143) ([#144](https://github.com/ethereum/iptf-map/pull/144)) +- chore: Retire `PRD-IPTF-PUBLIC-Q1-2026.md` -- Q1 closed; remaining unfinished items tracked in [#143](https://github.com/ethsystems/map/issues/143) ([#144](https://github.com/ethsystems/map/pull/144)) ## [0.3.0] - 2026-04-13 @@ -48,10 +48,10 @@ All notable changes to the IPTF Map are documented here. ### Added #### Patterns -- feat(pattern): [Forced Withdrawal](patterns/pattern-forced-withdrawal.md) — L1 escape hatch for asset recovery without operator cooperation ([#125](https://github.com/ethereum/iptf-map/issues/125)) -- feat(pattern): [TLS Payment Bridge](patterns/pattern-tls-payment-bridge.md) — trust-minimized fiat-to-onchain swaps via zk-TLS proofs on instant payment rails ([#88](https://github.com/ethereum/iptf-map/issues/88)) -- feat(pattern): [Native Account Abstraction](patterns/pattern-native-account-abstraction.md) — EIP-8141 modular verification logic for PQ auth agility ([#121](https://github.com/ethereum/iptf-map/pull/121)) -- feat(pattern): [ZK Proof Systems](patterns/pattern-zk-proof-systems.md) — taxonomy of proving systems with PQ safety analysis ([#121](https://github.com/ethereum/iptf-map/pull/121)) +- feat(pattern): [Forced Withdrawal](patterns/pattern-forced-withdrawal.md) — L1 escape hatch for asset recovery without operator cooperation ([#125](https://github.com/ethsystems/map/issues/125)) +- feat(pattern): [TLS Payment Bridge](patterns/pattern-tls-payment-bridge.md) — trust-minimized fiat-to-onchain swaps via zk-TLS proofs on instant payment rails ([#88](https://github.com/ethsystems/map/issues/88)) +- feat(pattern): [Native Account Abstraction](patterns/pattern-native-account-abstraction.md) — EIP-8141 modular verification logic for PQ auth agility ([#121](https://github.com/ethsystems/map/pull/121)) +- feat(pattern): [ZK Proof Systems](patterns/pattern-zk-proof-systems.md) — taxonomy of proving systems with PQ safety analysis ([#121](https://github.com/ethsystems/map/pull/121)) - feat(pattern): [Private Set Intersection (DH-based)](patterns/pattern-private-set-intersection-dh.md) - Bilateral ECDH-PSI for private matching of identifier sets - feat(pattern): [Private Set Intersection (OPRF-based)](patterns/pattern-private-set-intersection-oprf.md) - OT/OPRF-based PSI scaling to millions of elements - feat(pattern): [Private Set Intersection (Circuit-based)](patterns/pattern-private-set-intersection-circuit.md) - Garbled circuit PSI for computing arbitrary functions over intersections @@ -60,62 +60,62 @@ All notable changes to the IPTF Map are documented here. - feat(pattern): [Safe Proof Delegation](patterns/pattern-safe-proof-delegation.md) - Intent-based delegation to non-custodial provers with revocable visibility (EIP-8182) - feat(pattern): [Network-Level Anonymity](patterns/pattern-network-anonymity.md) - Umbrella pattern for transport-layer sender anonymity (Tor, mixnets, private RPC, TEE-assisted, VPN) - feat(pattern): [TEE-Assisted Network Anonymity](patterns/pattern-tee-network-anonymity.md) - TEE+secret-sharing approach for low-latency sender anonymity (Flashbots Flashnet) -- feat(pattern): Private Shared State split into [co-SNARKs](patterns/pattern-private-shared-state-cosnark.md), [FHE](patterns/pattern-private-shared-state-fhe.md), [TEE](patterns/pattern-private-shared-state-tee.md) — each with distinct CROPS profile and trust model ([#104](https://github.com/ethereum/iptf-map/issues/104)) -- feat(pattern): Enhanced [Hybrid TEE + ZK Settlement](patterns/pattern-tee-zk-settlement.md) with trust framework, TEE API surface, stealth address design, anti-pattern table, and PoC learnings ([#79](https://github.com/ethereum/iptf-map/issues/79)) -- feat(pattern): [Compliance Monitoring](patterns/pattern-compliance-monitoring.md) - Transaction screening with privacy-preserving audit trails ([#73](https://github.com/ethereum/iptf-map/pull/73)) +- feat(pattern): Private Shared State split into [co-SNARKs](patterns/pattern-private-shared-state-cosnark.md), [FHE](patterns/pattern-private-shared-state-fhe.md), [TEE](patterns/pattern-private-shared-state-tee.md) — each with distinct CROPS profile and trust model ([#104](https://github.com/ethsystems/map/issues/104)) +- feat(pattern): Enhanced [Hybrid TEE + ZK Settlement](patterns/pattern-tee-zk-settlement.md) with trust framework, TEE API surface, stealth address design, anti-pattern table, and PoC learnings ([#79](https://github.com/ethsystems/map/issues/79)) +- feat(pattern): [Compliance Monitoring](patterns/pattern-compliance-monitoring.md) - Transaction screening with privacy-preserving audit trails ([#73](https://github.com/ethsystems/map/pull/73)) - feat(pattern): [L2 Privacy Evaluation Framework](patterns/pattern-l2-privacy-evaluation.md) - Methodology for institutions to compare privacy L2s (PR-011) - feat(pattern): [Cross-chain Privacy Bridge](patterns/pattern-cross-chain-privacy-bridge.md) - Bridge assets between chains while preserving privacy - feat(pattern): [Stateless Plasma Privacy](patterns/pattern-plasma-stateless-privacy.md) - Client-side proving with minimal on-chain footprint (Intmax-style) -- feat(pattern): [vOPRF Nullifiers](patterns/pattern-voprf-nullifiers.md) - Threshold vOPRF-based nullifier generation for credentials/signals ([#61](https://github.com/ethereum/iptf-map/pull/61)) -- feat(pattern): [Modular Privacy Stack](patterns/pattern-modular-privacy-stack.md) - Four-layer privacy architecture ([#54](https://github.com/ethereum/iptf-map/pull/54)) +- feat(pattern): [vOPRF Nullifiers](patterns/pattern-voprf-nullifiers.md) - Threshold vOPRF-based nullifier generation for credentials/signals ([#61](https://github.com/ethsystems/map/pull/61)) +- feat(pattern): [Modular Privacy Stack](patterns/pattern-modular-privacy-stack.md) - Four-layer privacy architecture ([#54](https://github.com/ethsystems/map/pull/54)) - feat(pattern): [Hybrid public-private modes](patterns/pattern-hybrid-public-private-modes.md) -- feat(pattern): [Private transaction broadcasting](patterns/pattern-private-transaction-broadcasting.md) ([#43](https://github.com/ethereum/iptf-map/pull/43)) -- feat(pattern): [TEE-based privacy](patterns/pattern-tee-based-privacy.md) ([#44](https://github.com/ethereum/iptf-map/pull/44)) -- feat(pattern): [Threshold encrypted mempool](patterns/pattern-threshold-encrypted-mempool.md) ([#45](https://github.com/ethereum/iptf-map/pull/45)) +- feat(pattern): [Private transaction broadcasting](patterns/pattern-private-transaction-broadcasting.md) ([#43](https://github.com/ethsystems/map/pull/43)) +- feat(pattern): [TEE-based privacy](patterns/pattern-tee-based-privacy.md) ([#44](https://github.com/ethsystems/map/pull/44)) +- feat(pattern): [Threshold encrypted mempool](patterns/pattern-threshold-encrypted-mempool.md) ([#45](https://github.com/ethsystems/map/pull/45)) #### Approaches - feat(approach): [Private Money Market Funds](approaches/approach-private-money-market-funds.md) - Privacy-preserving MMF operations with ZK NAV proofs -- feat(approach): Restructured [Private Trade Settlement](approaches/approach-private-trade-settlement.md) — separated single-chain and cross-chain approaches, added TEE+ZK, MPC, and intent-based settlement with trade-off matrices ([#77](https://github.com/ethereum/iptf-map/issues/77)) +- feat(approach): Restructured [Private Trade Settlement](approaches/approach-private-trade-settlement.md) — separated single-chain and cross-chain approaches, added TEE+ZK, MPC, and intent-based settlement with trade-off matrices ([#77](https://github.com/ethsystems/map/issues/77)) - feat(approach): Enhanced [Private Bonds](approaches/approach-private-bonds.md) with PoC learnings, coprocessor model analysis (co-SNARKs vs FHE), comparison matrix, and implementation guidance -- feat(approach): [Privacy Standards Survey](approaches/approach-privacy-standards-survey.md) - Standards catalog, gap analysis, and decision guidance ([#64](https://github.com/ethereum/iptf-map/pull/64)) -- feat(approach): [White-label infrastructure deployment](approaches/approach-white-label-deployment.md) ([#55](https://github.com/ethereum/iptf-map/pull/55)) -- feat(approach): [Atomic DvP Settlement](approaches/approach-dvp-atomic-settlement.md) ([#56](https://github.com/ethereum/iptf-map/pull/56)) +- feat(approach): [Privacy Standards Survey](approaches/approach-privacy-standards-survey.md) - Standards catalog, gap analysis, and decision guidance ([#64](https://github.com/ethsystems/map/pull/64)) +- feat(approach): [White-label infrastructure deployment](approaches/approach-white-label-deployment.md) ([#55](https://github.com/ethsystems/map/pull/55)) +- feat(approach): [Atomic DvP Settlement](approaches/approach-dvp-atomic-settlement.md) ([#56](https://github.com/ethsystems/map/pull/56)) - feat(approach): Expanded [Private Payments](approaches/approach-private-payments.md) with Plasma and TEE approaches #### Use Cases - feat(use-case): [Private Supply Chain](use-cases/private-supply-chain.md), [Private Procurement](use-cases/private-procurement.md), [Private Registry](use-cases/private-registry.md), [Private Read](use-cases/private-read.md), [Private Corporate Bonds](use-cases/private-corporate-bonds.md), [Private Government Debt](use-cases/private-government-debt.md), [Private FX](use-cases/private-fx.md), [Private Stocks](use-cases/private-stocks.md), [Private Commodities](use-cases/private-commodities.md), [Private Repo](use-cases/private-repo.md), [Private Money Market Funds](use-cases/private-money-market-funds.md), [Private Treasuries](use-cases/private-treasuries.md), [Private Payments](use-cases/private-payments.md), [Private Oracles](use-cases/private-oracles.md), [Private Messaging](use-cases/private-messaging.md) #### Domains & Vendors -- feat(domain): [Post-Quantum Threats](domains/post-quantum.md) — PQ threat landscape, Ethereum layer analysis, and application-layer breakage index ([#121](https://github.com/ethereum/iptf-map/pull/121)) -- feat(vendor): [Peer](vendors/peer.md) — P2P fiat-to-crypto onramp using TLSNotary proofs ([#88](https://github.com/ethereum/iptf-map/issues/88)) +- feat(domain): [Post-Quantum Threats](domains/post-quantum.md) — PQ threat landscape, Ethereum layer analysis, and application-layer breakage index ([#121](https://github.com/ethsystems/map/pull/121)) +- feat(vendor): [Peer](vendors/peer.md) — P2P fiat-to-crypto onramp using TLSNotary proofs ([#88](https://github.com/ethsystems/map/issues/88)) - feat(vendor): [EY Starlight](vendors/ey.md#starlight) - Solidity transpiler for private on-chain state - feat(vendor): [TACEO Merces](vendors/taceo-merces.md) - MPC + ZK approach for private stablecoin transfers -- feat(vendor): [Fhenix](vendors/fhenix.md) - FHE privacy ([#32](https://github.com/ethereum/iptf-map/pull/32)) -- feat(vendor): [Space and Time](vendors/space-and-time.md) ([#46](https://github.com/ethereum/iptf-map/pull/46)) +- feat(vendor): [Fhenix](vendors/fhenix.md) - FHE privacy ([#32](https://github.com/ethsystems/map/pull/32)) +- feat(vendor): [Space and Time](vendors/space-and-time.md) ([#46](https://github.com/ethsystems/map/pull/46)) #### CROPS Framework & Evaluation -- feat(template): [crops_profile](patterns/_template.md) frontmatter block added to pattern template for CROPS dimension indexing ([#101](https://github.com/ethereum/iptf-map/issues/101)) -- feat(template): [crops_profile](vendors/_template.md) frontmatter block and CROPS evaluation criteria added to vendor template and README ([#102](https://github.com/ethereum/iptf-map/issues/102)) -- docs(glossary): [CROPS, I2I, I2U](GLOSSARY.md#iptf-evaluation-frameworks) evaluation framework definitions ([#100](https://github.com/ethereum/iptf-map/issues/100)) -- docs(readme): [Evaluation Framework](README.md#evaluation-framework) section with CROPS alignment statement ([#100](https://github.com/ethereum/iptf-map/issues/100)) -- feat(patterns): CROPS-aligned 18 patterns with `crops_profile` frontmatter and deployment-context Trade-offs notes ([#104](https://github.com/ethereum/iptf-map/issues/104)) +- feat(template): [crops_profile](patterns/_template.md) frontmatter block added to pattern template for CROPS dimension indexing ([#101](https://github.com/ethsystems/map/issues/101)) +- feat(template): [crops_profile](vendors/_template.md) frontmatter block and CROPS evaluation criteria added to vendor template and README ([#102](https://github.com/ethsystems/map/issues/102)) +- docs(glossary): [CROPS, I2I, I2U](GLOSSARY.md#ethereum-systems-evaluation-frameworks) evaluation framework definitions ([#100](https://github.com/ethsystems/map/issues/100)) +- docs(readme): [Evaluation Framework](README.md#evaluation-framework) section with CROPS alignment statement ([#100](https://github.com/ethsystems/map/issues/100)) +- feat(patterns): CROPS-aligned 18 patterns with `crops_profile` frontmatter and deployment-context Trade-offs notes ([#104](https://github.com/ethsystems/map/issues/104)) - feat(patterns): Add `context` and `crops_profile` CROPS frontmatter to additional patterns #### CI & Quality -- feat(ci): Enhanced AI content quality guardrails ([#58](https://github.com/ethereum/iptf-map/issues/58)) - - Vale prose linter with custom IPTF styles for marketing language, hedging, and terminology +- feat(ci): Enhanced AI content quality guardrails ([#58](https://github.com/ethsystems/map/issues/58)) + - Vale prose linter with custom EthSystems styles for marketing language, hedging, and terminology - GLOSSARY.md term consistency checker (`scripts/check-terminology.js`) - Extended validation to all content types (vendors, use-cases, approaches, jurisdictions) - JSON Schema validation for frontmatter - Husky pre-commit hooks with lint-staged - LLM-based content review tool (`scripts/llm-review.js`) -- feat(ci): Pattern validation workflow ([#40](https://github.com/ethereum/iptf-map/pull/40)) +- feat(ci): Pattern validation workflow ([#40](https://github.com/ethsystems/map/pull/40)) #### Documentation -- docs(glossary): Add PQ cryptography terms (CRQC, HNDL, ML-KEM, ML-DSA, SLH-DSA, Poseidon) ([#121](https://github.com/ethereum/iptf-map/pull/121)) -- docs: Q1 2026 PRD with sprint planning ([#39](https://github.com/ethereum/iptf-map/pull/39)) -- docs: [CHANGELOG.md](CHANGELOG.md) and weekly summary script ([#49](https://github.com/ethereum/iptf-map/pull/49)) -- docs: [weekly-updates](weekly-updates/) directory ([#59](https://github.com/ethereum/iptf-map/pull/59)) +- docs(glossary): Add PQ cryptography terms (CRQC, HNDL, ML-KEM, ML-DSA, SLH-DSA, Poseidon) ([#121](https://github.com/ethsystems/map/pull/121)) +- docs: Q1 2026 PRD with sprint planning ([#39](https://github.com/ethsystems/map/pull/39)) +- docs: [CHANGELOG.md](CHANGELOG.md) and weekly summary script ([#49](https://github.com/ethsystems/map/pull/49)) +- docs: [weekly-updates](weekly-updates/) directory ([#59](https://github.com/ethsystems/map/pull/59)) ### Changed @@ -127,53 +127,53 @@ All notable changes to the IPTF Map are documented here. - feat(use-case): Enriched [Private Oracles](use-cases/private-oracles.md) with data provenance & consent angle - feat(use-case): Broadened [Private Identity](use-cases/private-identity.md) beyond institutional KYC to cover governance and national identity use cases - feat(approach): Restructured [Private Identity Approach](approaches/approach-private-identity.md) with credential-source taxonomy and validated deployment references -- fix(patterns): Add PQ exposure notes to Trade-offs of 16 affected patterns and cross-refs to 4 PQ-aware patterns ([#121](https://github.com/ethereum/iptf-map/pull/121)) +- fix(patterns): Add PQ exposure notes to Trade-offs of 16 affected patterns and cross-refs to 4 PQ-aware patterns ([#121](https://github.com/ethsystems/map/pull/121)) - fix(pattern): Refreshed [TEE-Based Privacy](patterns/pattern-tee-based-privacy.md) — added CPU-encrypted vs hypervisor-isolated platform classification and threat model comparison ### Removed -- refactor(patterns): Deleted 4 redundant patterns ([#104](https://github.com/ethereum/iptf-map/issues/104)): +- refactor(patterns): Deleted 4 redundant patterns ([#104](https://github.com/ethsystems/map/issues/104)): `pattern-zk-derivative-delta.md` (covered by shielding + co-SNARKs), `pattern-zk-htlc.md` (covered by cross-chain privacy bridge + shielding), `pattern-zk-shielded-balances.md` (merged into [Shielding](patterns/pattern-shielding.md)), `pattern-zk-spv.md` (removed from map) -- refactor(patterns): Deleted original `pattern-private-shared-state.md`, replaced by 3 trust-model-specific cards ([#104](https://github.com/ethereum/iptf-map/issues/104)) +- refactor(patterns): Deleted original `pattern-private-shared-state.md`, replaced by 3 trust-model-specific cards ([#104](https://github.com/ethsystems/map/issues/104)) ### Fixed -- fix(pattern): include tradeoff around handling of stock splits in [ERC-3643](patterns/pattern-erc3643-rwa.md) ([#81](https://github.com/ethereum/iptf-map/pull/81)) -- fix(refs): Updated [Private Bonds](use-cases/private-bonds.md) PoC links to ethereum/iptf-pocs -- fix(pattern): Required frontmatter fields across all patterns ([#42](https://github.com/ethereum/iptf-map/pull/42)) +- fix(pattern): include tradeoff around handling of stock splits in [ERC-3643](patterns/pattern-erc3643-rwa.md) ([#81](https://github.com/ethsystems/map/pull/81)) +- fix(refs): Updated [Private Bonds](use-cases/private-bonds.md) PoC links to ethsystems/pocs +- fix(pattern): Required frontmatter fields across all patterns ([#42](https://github.com/ethsystems/map/pull/42)) ## [0.2.0] - 2025-12-19 (End of Year) ### Added -- feat(pattern): [TEE key manager](patterns/pattern-tee-key-manager.md) ([#33](https://github.com/ethereum/iptf-map/pull/33)) -- feat(pattern): [EIL](patterns/pattern-eil.md) - Encrypted Inline Ledger ([#26](https://github.com/ethereum/iptf-map/pull/26)) -- feat(pattern): [FOCIL-EIP7805](patterns/pattern-focil-eip7805.md) ([#26](https://github.com/ethereum/iptf-map/pull/26)) -- feat(pattern): [Lean Ethereum](patterns/pattern-lean-ethereum.md) ([#26](https://github.com/ethereum/iptf-map/pull/26)) -- feat(pattern): [OIF](patterns/pattern-oif.md) - Optimized Integrity Framework ([#26](https://github.com/ethereum/iptf-map/pull/26)) -- feat(pattern): [Noir private contracts](patterns/pattern-noir-private-contracts.md) ([#21](https://github.com/ethereum/iptf-map/pull/21)) -- feat(vendor): [Paladin](vendors/paladin.md) ([#19](https://github.com/ethereum/iptf-map/pull/19)) -- feat(vendor): [State Labs](vendors/tx-shield.md) - Tx Shield, OpenTMP LLM, Collab-Key ([#7](https://github.com/ethereum/iptf-map/pull/7)) +- feat(pattern): [TEE key manager](patterns/pattern-tee-key-manager.md) ([#33](https://github.com/ethsystems/map/pull/33)) +- feat(pattern): [EIL](patterns/pattern-eil.md) - Encrypted Inline Ledger ([#26](https://github.com/ethsystems/map/pull/26)) +- feat(pattern): [FOCIL-EIP7805](patterns/pattern-focil-eip7805.md) ([#26](https://github.com/ethsystems/map/pull/26)) +- feat(pattern): [Lean Ethereum](patterns/pattern-lean-ethereum.md) ([#26](https://github.com/ethsystems/map/pull/26)) +- feat(pattern): [OIF](patterns/pattern-oif.md) - Optimized Integrity Framework ([#26](https://github.com/ethsystems/map/pull/26)) +- feat(pattern): [Noir private contracts](patterns/pattern-noir-private-contracts.md) ([#21](https://github.com/ethsystems/map/pull/21)) +- feat(vendor): [Paladin](vendors/paladin.md) ([#19](https://github.com/ethsystems/map/pull/19)) +- feat(vendor): [State Labs](vendors/tx-shield.md) - Tx Shield, OpenTMP LLM, Collab-Key ([#7](https://github.com/ethsystems/map/pull/7)) - feat(vendor): [Soda Labs](vendors/soda-labs.md) -- feat(vendor): [Miden](vendors/miden.md) docs ([#18](https://github.com/ethereum/iptf-map/pull/18)) -- feat(approach): [Private broadcasting](approaches/approach-private-broadcasting.md) ([#6](https://github.com/ethereum/iptf-map/pull/6)) +- feat(vendor): [Miden](vendors/miden.md) docs ([#18](https://github.com/ethsystems/map/pull/18)) +- feat(approach): [Private broadcasting](approaches/approach-private-broadcasting.md) ([#6](https://github.com/ethsystems/map/pull/6)) - feat(approach): [Private bonds](approaches/approach-private-bonds.md) -- feat(jurisdiction): [EU Data Protection](jurisdictions/eu-data-protection.md) ([#8](https://github.com/ethereum/iptf-map/pull/8)) -- docs: [GLOSSARY.md](GLOSSARY.md) - privacy terminology ([#5](https://github.com/ethereum/iptf-map/pull/5)) +- feat(jurisdiction): [EU Data Protection](jurisdictions/eu-data-protection.md) ([#8](https://github.com/ethsystems/map/pull/8)) +- docs: [GLOSSARY.md](GLOSSARY.md) - privacy terminology ([#5](https://github.com/ethsystems/map/pull/5)) ### Changed -- refactor: Split patterns directory into patterns + approaches ([#2](https://github.com/ethereum/iptf-map/pull/2)) +- refactor: Split patterns directory into patterns + approaches ([#2](https://github.com/ethsystems/map/pull/2)) ### Fixed -- fix(pattern): [DvP ERC-7573](patterns/pattern-dvp-erc7573.md) updates ([#31](https://github.com/ethereum/iptf-map/pull/31)) +- fix(pattern): [DvP ERC-7573](patterns/pattern-dvp-erc7573.md) updates ([#31](https://github.com/ethsystems/map/pull/31)) - fix(use-case): [Private Identity](use-cases/private-identity.md) - revocation, zk-TLS mechanism -- fix(docs): Glossary - clarified core privacy concepts ([#29](https://github.com/ethereum/iptf-map/pull/29)) -- fix(docs): ZKsync naming standardization ([#20](https://github.com/ethereum/iptf-map/pull/20)) +- fix(docs): Glossary - clarified core privacy concepts ([#29](https://github.com/ethsystems/map/pull/29)) +- fix(docs): ZKsync naming standardization ([#20](https://github.com/ethsystems/map/pull/20)) ## [0.1.0] - 2025-10-06 (MVP) @@ -207,7 +207,7 @@ All notable changes to the IPTF Map are documented here. - docs: [GLOSSARY.md](GLOSSARY.md) with standardized terminology - docs: CC0 public domain license -[Unreleased]: https://github.com/ethereum/iptf-map/compare/v0.3.0...HEAD -[0.3.0]: https://github.com/ethereum/iptf-map/compare/v0.2.0...v0.3.0 -[0.2.0]: https://github.com/ethereum/iptf-map/compare/v0.1.0...v0.2.0 -[0.1.0]: https://github.com/ethereum/iptf-map/releases/tag/v0.1.0 +[Unreleased]: https://github.com/ethsystems/map/compare/v0.3.0...HEAD +[0.3.0]: https://github.com/ethsystems/map/compare/v0.2.0...v0.3.0 +[0.2.0]: https://github.com/ethsystems/map/compare/v0.1.0...v0.2.0 +[0.1.0]: https://github.com/ethsystems/map/releases/tag/v0.1.0 diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 2e71350..d70b6ef 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,4 +1,4 @@ -# Contributing to IPTF Map +# Contributing to EthSystems Map ## How to Contribute diff --git a/GLOSSARY.md b/GLOSSARY.md index 178abce..4781c2f 100644 --- a/GLOSSARY.md +++ b/GLOSSARY.md @@ -1,8 +1,8 @@ ## Glossary -### IPTF Evaluation Frameworks +### EthSystems Evaluation Frameworks -**CROPS (Censorship Resistance, Open Source and Free, Privacy, Security)**: Four non-negotiable properties for Ethereum defined by the Ethereum Foundation. The IPTF Map evaluates solutions against all four dimensions independently. See [CONTRIBUTING.md § CROPS Evaluation](CONTRIBUTING.md#crops-evaluation) for full scoring rubrics. +**CROPS (Censorship Resistance, Open Source and Free, Privacy, Security)**: Four non-negotiable properties for Ethereum defined by the Ethereum Foundation. The EthSystems Map evaluates solutions against all four dimensions independently. See [CONTRIBUTING.md § CROPS Evaluation](CONTRIBUTING.md#crops-evaluation) for full scoring rubrics. **I2I (Institution-to-Institution)**: Interaction model where both counterparties are regulated entities (e.g., bank-to-bank settlement). Symmetric power dynamic; both parties have legal teams, vendor choice, and contractual recourse. diff --git a/Makefile b/Makefile index 4b0b0e3..8c76866 100644 --- a/Makefile +++ b/Makefile @@ -1,10 +1,10 @@ -# IPTF Map - Local Validation Commands +# EthSystems Map - Local Validation Commands # Run these before pushing to catch issues early .PHONY: help install validate lint check marketing-check help: - @echo "IPTF Map Validation Commands" + @echo "EthSystems Map Validation Commands" @echo "" @echo " make install - Install dependencies" @echo " make validate - Run pattern validation" diff --git a/QA-AUDIT.md b/QA-AUDIT.md index 3a63d44..9e3f641 100644 --- a/QA-AUDIT.md +++ b/QA-AUDIT.md @@ -1,8 +1,8 @@ -# IPTF Map - Q2 2026 QA Audit +# EthSystems Map - Q2 2026 QA Audit > **Goal:** Every content file in the map read and reviewed by a human. Main targets: slop and incoherences. > **Period:** Q2 2026 (April - June) -> **Where:** All audit work happens on the `feat/audit` branch ([PR #130](https://github.com/ethereum/iptf-map/pull/130)). +> **Where:** All audit work happens on the `feat/audit` branch ([PR #130](https://github.com/ethsystems/map/pull/130)). ## How the audit works (claim and reveal) @@ -55,7 +55,7 @@ The mechanical checks (frontmatter, word limits, link validity) are covered by ` ## CodeRabbit review follow-up (PR #130, 2026-06-29) -Post-audit corrections from the CodeRabbit review pass, content/style only, no new content. See the [PR #130](https://github.com/ethereum/iptf-map/pull/130) conversation for the full triage and the dismissed/deferred comments. +Post-audit corrections from the CodeRabbit review pass, content/style only, no new content. See the [PR #130](https://github.com/ethsystems/map/pull/130) conversation for the full triage and the dismissed/deferred comments. - **approaches/approach-dvp-atomic-settlement.md**, standards line: ERC-3643 is Final (was "both still Draft"); ERC-6123 stays Draft. Cleared a Vale "only" on the constraints line. - **approaches/approach-private-identity.md**, TACEO:OPRF "currently in public beta" to "live in production"; "brought on chain" to "on-chain". @@ -150,7 +150,7 @@ Tooling/config (not content files): reverted `vendors/_template.md` to master (k | # | File | Status | Reviewer | Claimed | Reviewed | Notes | |---|------|--------|----------|---------|----------|-------| -| 1 | [private-bonds.md](use-cases/private-bonds.md) | `ok` | Meyanis95 | 2026-06-19 | 2026-06-19 | Private iptf-pm umbrella link to public iptf-pocs ref; EIP-6123 to ERC-6123 | +| 1 | [private-bonds.md](use-cases/private-bonds.md) | `ok` | Meyanis95 | 2026-06-19 | 2026-06-19 | Private iptf-pm umbrella link to public ethsystems/pocs ref; EIP-6123 to ERC-6123 | | 2 | [private-commodities.md](use-cases/private-commodities.md) | `ok` | Meyanis95 | 2026-06-19 | 2026-06-19 | Reviewed clean | | 3 | [private-corporate-bonds.md](use-cases/private-corporate-bonds.md) | `ok` | Meyanis95 | 2026-06-19 | 2026-06-19 | EIP-6123 to ERC-6123 | | 4 | [private-derivatives.md](use-cases/private-derivatives.md) | `ok` | Meyanis95 | 2026-06-19 | 2026-06-19 | Reviewed clean (ERC-6123 naming already correct) | @@ -257,7 +257,7 @@ These are one-time checks on the overall map integrity: | All internal cross-links resolve | `ok` | Meyanis95 | 2026-06-24 | content links resolve after l2-eval cleanup; intentional non-resolving refs left as-is, template/example placeholders (rfps/_template.md, CONTRIBUTING.md), historical CHANGELOG release links to since-removed content (l2-eval/survey/weekly-updates; past releases are immutable), QA-AUDIT deprecated-row link (tracker bookkeeping) | | No orphan files (unreferenced content) | `ok` | Meyanis95 | 2026-06-24 | reviewed, prose-link "orphans" are mostly frontmatter/README-reachable (taxonomy); approach-white-label-deployment flagged for a use-case backlink (backlog) | | Frontmatter schema validation passes | `ok` | Meyanis95 | 2026-06-24 | `validate-patterns.js` passes (only content word-count warnings) | -| Vale linting passes on all files | `ok` | Meyanis95 | 2026-06-24 | 0 errors; ~196 advisory warnings (IPTF.Marketing / IPTF.Terminology) to prose-sweep backlog | +| Vale linting passes on all files | `ok` | Meyanis95 | 2026-06-24 | 0 errors; ~196 advisory warnings (EthSystems.Marketing / EthSystems.Terminology) to prose-sweep backlog | --- @@ -274,4 +274,4 @@ Questions, uncertainties, or decisions that surface during the audit. Resolve or | 5 | Use-case `status`: the 14 former stubs are now `ready`, but the 9 complete/resilient files carry no `status` and the use-case `_template.md` omits it. Standardize (add `status: ready` to all + document in template) or keep `status` optional? | Meyanis95 | 2026-06-19 | [use-cases/_template.md](use-cases/_template.md) | Resolved 2026-06-19: `status: ready` on all 23 + added to `_template.md`; titles also normalized (unquoted, `(ERC-6123)` dropped from derivatives title) | | 6 | Dropped `## CROPS profile` from the vendor template + removed peer's inline CROPS (per decision), but the vendor [README](vendors/README.md) and [CONTRIBUTING § CROPS Evaluation](CONTRIBUTING.md#crops-evaluation) still present CROPS as the core vendor-evaluation framework. Reconcile the README/CONTRIBUTING, or reintroduce CROPS in another form? | Meyanis95 | 2026-06-19 | [vendors/README.md](vendors/README.md), [CONTRIBUTING.md](CONTRIBUTING.md) | **Resolved 2026-06-24:** keep CROPS as a curation guideline in the vendor docs (vendors/README + CONTRIBUTING left intact). The reconciliation is the already-completed drop of the *per-card* CROPS profile from the vendor template; the docs may reference CROPS as a selection guideline without per-card scoring. | | 7 | Some approaches list `primary_patterns` that no sub-approach `uses_patterns` references, dvp-atomic-settlement (`pattern-commit-and-prove`), private-payments (`pattern-private-iso20022`, `pattern-private-stablecoin-shielded-payments`). The template's subset rule is satisfied, but a *primary* pattern unused by every sub-approach is odd. Demote to supporting, or accept primaries as thematic anchors? | Meyanis95 | 2026-06-24 | [approach-dvp-atomic-settlement.md](approaches/approach-dvp-atomic-settlement.md), [approach-private-payments.md](approaches/approach-private-payments.md) | **Resolved 2026-06-24:** demoted the unused primaries to supporting, dvp (commit-and-prove); payments (private-iso20022, private-stablecoin-shielded-payments). | -| 8 | Throughput figures in co-SNARK / FHE sub-approaches (`~200 TPS` co-SNARK, `500-1000 TPS` FHE in bonds; PoC benchmarks in payments) are stated as fact but trace to IPTF PoCs / vendor claims and were not independently verifiable in this pass. Add explicit sourcing or qualify as PoC-measured? Also: "Trusted setup is not required (UltraHonk)" recurs map-wide but UltraHonk uses a universal KZG SRS, precise wording is "no per-circuit trusted setup". | Meyanis95 | 2026-06-24 | [approach-private-bonds.md](approaches/approach-private-bonds.md), [approach-private-derivatives.md](approaches/approach-private-derivatives.md) | **Resolved 2026-06-24:** qualified co-SNARK ~200 TPS (TACEO-reported) + FHE 500-1000 TPS (vendor-reported) in bonds/derivatives; fixed "trusted setup not required (UltraHonk)" to "no per-circuit trusted setup (universal KZG SRS)" in bonds + payments; corrected the zk-wrappers UltraHonk transparency claim. | +| 8 | Throughput figures in co-SNARK / FHE sub-approaches (`~200 TPS` co-SNARK, `500-1000 TPS` FHE in bonds; PoC benchmarks in payments) are stated as fact but trace to EthSystems PoCs / vendor claims and were not independently verifiable in this pass. Add explicit sourcing or qualify as PoC-measured? Also: "Trusted setup is not required (UltraHonk)" recurs map-wide but UltraHonk uses a universal KZG SRS, precise wording is "no per-circuit trusted setup". | Meyanis95 | 2026-06-24 | [approach-private-bonds.md](approaches/approach-private-bonds.md), [approach-private-derivatives.md](approaches/approach-private-derivatives.md) | **Resolved 2026-06-24:** qualified co-SNARK ~200 TPS (TACEO-reported) + FHE 500-1000 TPS (vendor-reported) in bonds/derivatives; fixed "trusted setup not required (UltraHonk)" to "no per-circuit trusted setup (universal KZG SRS)" in bonds + payments; corrected the zk-wrappers UltraHonk transparency claim. | diff --git a/README.md b/README.md index ab66dd6..160e4b4 100644 --- a/README.md +++ b/README.md @@ -1,8 +1,10 @@ # Public Reference Materials -The Institutional Privacy Task Force (IPTF) helps onboard institutions and enterprises onto Ethereum, with a focus on ensuring their privacy needs are met in a performant, secure, usable, and accessible way. +> This repository was formerly `iptf-map`, published under the Institutional Privacy Task Force (now EthSystems). -This folder contains public-facing documentation for IPTF, including technical patterns, use cases, regulatory frameworks, and vendor evaluations. +EthSystems helps onboard institutions and enterprises onto Ethereum, with a focus on ensuring their privacy needs are met in a performant, secure, usable, and accessible way. + +This folder contains public-facing documentation for EthSystems, including technical patterns, use cases, regulatory frameworks, and vendor evaluations. ## Structure diff --git a/approaches/_template.md b/approaches/_template.md index b9d5d2e..9da1c17 100644 --- a/approaches/_template.md +++ b/approaches/_template.md @@ -13,11 +13,11 @@ related_use_cases: [] # optional list of use-case s primary_patterns: [] # required; list of pattern- supporting_patterns: [] # optional; list of pattern- -# iptf_pocs: optional. IPTF research prototypes only (use open_source_implementations -# for third-party signals). Required when an IPTF-internal prototype exists for the +# pocs: optional. EthSystems research prototypes only (use open_source_implementations +# for third-party signals). Required when an EthSystems-internal prototype exists for the # sub-approach (not inferred from maturity alone). Each pocs[].sub_approach must # match a ### in ## Approaches. -# iptf_pocs: +# pocs: # folder: pocs/ # requirements: pocs//REQUIREMENTS.md # pocs: diff --git a/approaches/approach-dvp-atomic-settlement.md b/approaches/approach-dvp-atomic-settlement.md index e4a9f36..d8271f0 100644 --- a/approaches/approach-dvp-atomic-settlement.md +++ b/approaches/approach-dvp-atomic-settlement.md @@ -16,7 +16,7 @@ supporting_patterns: - pattern-tee-zk-settlement - pattern-shielding -iptf_pocs: +pocs: folder: pocs/private-trade-settlement requirements: pocs/private-trade-settlement/REQUIREMENTS.md pocs: @@ -156,7 +156,7 @@ example_vendors: [] - Trusted oracle is incompatible with the threat model - Conditions cannot be specified precisely enough for unambiguous attestation -**Implementation notes:** PoC at [TEE+ZK Cross-Chain Swap](https://github.com/ethereum/iptf-pocs/tree/master/pocs/private-trade-settlement/tee_swap) implements the oracle-attested variant where a TEE coordinator stands in for the oracle, generates a zero-knowledge proof of correct execution, and reveals stealth keys on success. See [Approach: Private Trade Settlement, TEE+ZK Coordination](approach-private-trade-settlement.md) for the same primitive in cross-network context. Common escrow-condition shapes: +**Implementation notes:** PoC at [TEE+ZK Cross-Chain Swap](https://github.com/ethsystems/pocs/tree/master/pocs/private-trade-settlement/tee_swap) implements the oracle-attested variant where a TEE coordinator stands in for the oracle, generates a zero-knowledge proof of correct execution, and reveals stealth keys on success. See [Approach: Private Trade Settlement, TEE+ZK Coordination](approach-private-trade-settlement.md) for the same primitive in cross-network context. Common escrow-condition shapes: | Class | Example | |---|---| diff --git a/approaches/approach-private-bonds.md b/approaches/approach-private-bonds.md index 8e8fb8a..cead48d 100644 --- a/approaches/approach-private-bonds.md +++ b/approaches/approach-private-bonds.md @@ -19,7 +19,7 @@ supporting_patterns: - pattern-verifiable-attestation - pattern-proof-of-innocence -iptf_pocs: +pocs: folder: pocs/private-bond requirements: pocs/private-bond/REQUIREMENTS.md pocs: @@ -234,7 +234,7 @@ For institutional bond issuance and trading at scale, UTXO Shielded Notes is the ### Technical perspective -Engineering effort scales by approach. UTXO Shielded Notes requires deploying a verifier and shipping a ZK toolchain, but mature vendor implementations remove the circuit-design burden. Privacy L2 trades sequencer dependency for native primitives, removing in-house circuit work but adding bridge integration. co-SNARKs requires running or contracting an MPC committee with operational discipline; throughput is bounded by batch cadence. FHE simplifies the programming model for complex bond logic but inherits shared throughput limits across all FHE applications on the network. PoC results across all three IPTF implementations confirm that selective-disclosure semantics work in each model; the architectural choice is driven by trust topology and bond-logic complexity. +Engineering effort scales by approach. UTXO Shielded Notes requires deploying a verifier and shipping a ZK toolchain, but mature vendor implementations remove the circuit-design burden. Privacy L2 trades sequencer dependency for native primitives, removing in-house circuit work but adding bridge integration. co-SNARKs requires running or contracting an MPC committee with operational discipline; throughput is bounded by batch cadence. FHE simplifies the programming model for complex bond logic but inherits shared throughput limits across all FHE applications on the network. PoC results across all three EthSystems implementations confirm that selective-disclosure semantics work in each model; the architectural choice is driven by trust topology and bond-logic complexity. ### Legal & risk perspective diff --git a/approaches/approach-private-identity.md b/approaches/approach-private-identity.md index 0ba5736..58e53be 100644 --- a/approaches/approach-private-identity.md +++ b/approaches/approach-private-identity.md @@ -41,7 +41,7 @@ open_source_implementations: description: "TLSNotary (zk-TLS transcript proofs)" language: Rust -iptf_pocs: +pocs: folder: pocs/private-identity requirements: pocs/private-identity/REQUIREMENTS.md pocs: @@ -276,7 +276,7 @@ example_vendors: [] - Single-issuer cooperation is reliable and the operational simplicity of the issuer-dependent approaches is preferred - Threshold OPRF network operation cannot meet jurisdictional independence requirements -**Implementation notes:** PoC at [Resilient Private Identity](https://github.com/ethereum/iptf-pocs/tree/master/pocs/private-identity/resilient-private-identity) (Noir / UltraHonk, BN254). Production roadmap: BLS12-381 migration via EIP-2537, private predicate circuits, EIP-4337 paymaster or purpose-built relay infrastructure. This sub-approach exposes the `IResilientIdentity` interface used by [Approach: Private Payments, Resilient Disbursement Rails](approach-private-payments.md) and [Approach: Civic Participation](approach-civic-participation.md). +**Implementation notes:** PoC at [Resilient Private Identity](https://github.com/ethsystems/pocs/tree/master/pocs/private-identity/resilient-private-identity) (Noir / UltraHonk, BN254). Production roadmap: BLS12-381 migration via EIP-2537, private predicate circuits, EIP-4337 paymaster or purpose-built relay infrastructure. This sub-approach exposes the `IResilientIdentity` interface used by [Approach: Private Payments, Resilient Disbursement Rails](approach-private-payments.md) and [Approach: Civic Participation](approach-civic-participation.md). ## Comparison diff --git a/approaches/approach-private-payments.md b/approaches/approach-private-payments.md index 387e732..692b7d9 100644 --- a/approaches/approach-private-payments.md +++ b/approaches/approach-private-payments.md @@ -28,7 +28,7 @@ supporting_patterns: - pattern-proof-of-innocence - pattern-private-information-retrieval -iptf_pocs: +pocs: folder: pocs/private-payment requirements: pocs/private-payment/REQUIREMENTS.md pocs: diff --git a/approaches/approach-private-trade-settlement.md b/approaches/approach-private-trade-settlement.md index 43679de..6087b03 100644 --- a/approaches/approach-private-trade-settlement.md +++ b/approaches/approach-private-trade-settlement.md @@ -16,7 +16,7 @@ supporting_patterns: - pattern-regulatory-disclosure-keys-proofs - pattern-private-pvp-stablecoins-erc7573 -iptf_pocs: +pocs: folder: pocs/private-trade-settlement requirements: pocs/private-trade-settlement/REQUIREMENTS.md pocs: diff --git a/approaches/approach-white-label-deployment.md b/approaches/approach-white-label-deployment.md index 36b4aa1..b6c0f85 100644 --- a/approaches/approach-white-label-deployment.md +++ b/approaches/approach-white-label-deployment.md @@ -19,7 +19,7 @@ supporting_patterns: - pattern-hybrid-public-private-modes - pattern-forced-withdrawal -iptf_pocs: +pocs: folder: pocs/diy-validium requirements: pocs/diy-validium/REQUIREMENTS.md pocs: @@ -132,7 +132,7 @@ example_vendors: [aztec, miden, fhenix] - Time-to-market dominates and engineering capacity is unavailable - Institution does not have the operational maturity to run privacy-critical infrastructure -**Implementation notes:** Reference build at [DIY Validium](https://github.com/ethereum/iptf-pocs/tree/master/pocs/diy-validium), an institution-controlled validium PoC (account-based validium with off-chain state, on-chain roots, ZK validity proofs via RISC Zero) demonstrating the same architecture as ZKsync Prividium with compliance logic expressed as Rust guest programs. Exit strategies must be documented at deployment for each scenario class: +**Implementation notes:** Reference build at [DIY Validium](https://github.com/ethsystems/pocs/tree/master/pocs/diy-validium), an institution-controlled validium PoC (account-based validium with off-chain state, on-chain roots, ZK validity proofs via RISC Zero) demonstrating the same architecture as ZKsync Prividium with compliance logic expressed as Rust guest programs. Exit strategies must be documented at deployment for each scenario class: | Scenario | Approach | |---|---| diff --git a/domains/post-quantum.md b/domains/post-quantum.md index 6c84eed..8730c78 100644 --- a/domains/post-quantum.md +++ b/domains/post-quantum.md @@ -6,7 +6,7 @@ description: "Migrate privacy and authentication to PQ-safe foundations before h ## TLDR -- A Cryptographically Relevant Quantum Computer (CRQC) breaks ECDSA, BLS, ECDH, Groth16, PLONK/KZG — Ethereum consensus, execution, and application privacy layers all affected. +- A Cryptographically Relevant Quantum Computer (CRQC) breaks ECDSA, BLS, ECDH, Groth16, PLONK/KZG; Ethereum consensus, execution, and application privacy layers all affected. - Harvest Now, Decrypt Later (HNDL) means confidentiality-critical applications face urgency now, even though CRQC is years away. - Hash-based and lattice-based primitives provide migration paths; STARKs are already PQ-safe. @@ -52,7 +52,7 @@ Assumptions and schemes with no known quantum speedup. These form the basis for | Assumption Family | Hardness Problem | Representative Schemes | NIST Status | Notes | | --------------------- | ------------------------------------------------------------------ | ---------------------------------- | ---------------------------- | ------------------------------------------------------------------------------------ | | Lattice-based | Learning With Errors (LWE), Ring-LWE, Short Integer Solution (SIS) | ML-KEM (Kyber), ML-DSA (Dilithium) | Standardized (FIPS 203, 204) | Primary PQ replacement for key exchange and signatures | -| Hash-based signatures | One-time signatures + Merkle trees | XMSS, SPHINCS+ (SLH-DSA) | Standardized (FIPS 205) | Stateful (XMSS) or stateless (SPHINCS+); conservative — depends on hash security assumptions | +| Hash-based signatures | One-time signatures + Merkle trees | XMSS, SPHINCS+ (SLH-DSA) | Standardized (FIPS 205) | Stateful (XMSS) or stateless (SPHINCS+); conservative: depends on hash security assumptions | | Hash + FRI (STARKs) | Hash collision resistance | STARK proof systems | N/A | Already deployed in Ethereum L2s; PQ-safe by construction | ## Ethereum Layer Analysis @@ -84,7 +84,7 @@ Ethereum inherits PQ transport encryption for some surfaces (Go 1.24 ships hybri | ------------------------------------ | ------------------------------ | -------------------------------------------------------------------------------------------------- | --------- | ---------------------------------------------------------------------------------------------------------------------- | | Note discovery / viewing keys | EC-based key derivation | ML-KEM (outside ZK circuit) + OMR | Tractable | [Shielding](../patterns/pattern-shielding.md), [Noir Private Contracts](../patterns/pattern-noir-private-contracts.md) | | Proven-correct encryption to auditor | ElGamal (EC scalar mul) | Lattice PKE outside circuit + Poseidon symmetric encryption inside circuit (detect-and-flag model) | Partial | [Regulatory Disclosure](../patterns/pattern-regulatory-disclosure-keys-proofs.md) | -| Protocol-enforced decryptability | Proving lattice PKE in-circuit | Field mismatch (q=3,329 vs BN254); simpler than full ML-KEM but still expensive | Unsolved | — | +| Protocol-enforced decryptability | Proving lattice PKE in-circuit | Field mismatch (q=3,329 vs BN254); simpler than full ML-KEM but still expensive | Unsolved | N/A | ### Dependencies @@ -114,16 +114,16 @@ Ethereum inherits PQ transport encryption for some surfaces (Go 1.24 ships hybri | [Safe Proof Delegation](../patterns/pattern-safe-proof-delegation.md) | Recursive ZK (if EC-based) | Medium | STARK-based recursion | **PQ-safe patterns** (no mitigation needed): -- [Private Shared State (FHE)](../patterns/pattern-private-shared-state-fhe.md) — lattice-based -- [Private MTP Auth](../patterns/pattern-private-mtp-auth.md) — Merkle trees, hash-based -- [Plasma Stateless Privacy](../patterns/pattern-plasma-stateless-privacy.md) — hash-based ZK +- [Private Shared State (FHE)](../patterns/pattern-private-shared-state-fhe.md): lattice-based +- [Private MTP Auth](../patterns/pattern-private-mtp-auth.md): Merkle trees, hash-based +- [Plasma Stateless Privacy](../patterns/pattern-plasma-stateless-privacy.md): hash-based ZK ## See also -- [Lean Ethereum](../patterns/pattern-lean-ethereum.md) — consensus-layer PQ migration -- [Native Account Abstraction](../patterns/pattern-native-account-abstraction.md) — execution-layer PQ auth agility -- [ZK Proof Systems](../patterns/pattern-zk-proof-systems.md) — STARK vs SNARK PQ comparison -- [Permissionless Spend Auth](../patterns/pattern-permissionless-spend-auth.md) — application-layer auth agility +- [Lean Ethereum](../patterns/pattern-lean-ethereum.md): consensus-layer PQ migration +- [Native Account Abstraction](../patterns/pattern-native-account-abstraction.md): execution-layer PQ auth agility +- [ZK Proof Systems](../patterns/pattern-zk-proof-systems.md): STARK vs SNARK PQ comparison +- [Permissionless Spend Auth](../patterns/pattern-permissionless-spend-auth.md): application-layer auth agility - [NIST PQC standards](https://csrc.nist.gov/projects/post-quantum-cryptography) - [Ethereum PQ tasklist (ethresear.ch)](https://ethresear.ch/t/tasklist-for-post-quantum-eth/21296) - [How to hard-fork to save most users' funds in a quantum emergency](https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901) diff --git a/package.json b/package.json index 73d3ff9..bd1bd64 100644 --- a/package.json +++ b/package.json @@ -1,7 +1,7 @@ { - "name": "iptf-map", + "name": "map", "version": "0.4.0", - "description": "Institutional Privacy Task Force Map - Privacy-preserving solutions for enterprise Ethereum", + "description": "EthSystems Map - Privacy-preserving solutions for enterprise Ethereum", "private": true, "scripts": { "validate": "node scripts/validate-patterns.js", @@ -30,6 +30,6 @@ "license": "CC0-1.0", "repository": { "type": "git", - "url": "https://github.com/ethereum/iptf-map.git" + "url": "https://github.com/ethsystems/map.git" } } diff --git a/patterns/README.md b/patterns/README.md index faf50c0..adb3b23 100644 --- a/patterns/README.md +++ b/patterns/README.md @@ -4,7 +4,7 @@ **TODO: This folder needs to be refactored, deduped and populated more** -**How to use.** When a design is repeatable, add `pattern-*.md` using the template below. Keep it concise: intent → protocol → guarantees → trade-offs. Cross-link related patterns and any live PoCs. Each pattern includes a CROPS score — see [CONTRIBUTING.md § CROPS Evaluation](../CONTRIBUTING.md#crops-evaluation) for scoring rubrics. +**How to use.** When a design is repeatable, add `pattern-*.md` using the template below. Keep it concise: intent → protocol → guarantees → trade-offs. Cross-link related patterns and any live PoCs. Each pattern includes a CROPS score: see [CONTRIBUTING.md § CROPS Evaluation](../CONTRIBUTING.md#crops-evaluation) for scoring rubrics. - Template: [`_template.md`](./_template.md) - Naming: `pattern-.md` (kebab-case) - Status flow: `draft` → `ready` (update `maturity` as you pilot/ship) @@ -13,21 +13,21 @@ ## Patterns to consider (stubs) (Add later; 1–2 screens each.) -- `pattern-secondary-market-rfq-batched-settlement.md` — Private RFQ + **batch settle** (cost/leakage win). -- `pattern-key-management-threshold-kms.md` — **Threshold keys**, rotation, escrow, emergency revoke. -- `pattern-cash-leg-eur-stablecoin-vs-mmf.md` — **EURC vs tokenized MMF/deposit tokens** for cash leg. -- `pattern-derivative-daily-settlement-erc6123.md` — Daily accrual/settlement semantics. -- `pattern-performance-batching-blob-costing.md` — Batching, blobs, proof cadence, SLOs. -- `pattern-eligibility-attestations-eas-erc3643.md` — EAS + ERC-3643 eligibility/KYC flows. -- `pattern-policy-data-classification.md` — Map ICMA BDT fields → **Public / Confidential / Reg-only**. +- `pattern-secondary-market-rfq-batched-settlement.md`: Private RFQ + **batch settle** (cost/leakage win). +- `pattern-key-management-threshold-kms.md`: **Threshold keys**, rotation, escrow, emergency revoke. +- `pattern-cash-leg-eur-stablecoin-vs-mmf.md`: **EURC vs tokenized MMF/deposit tokens** for cash leg. +- `pattern-derivative-daily-settlement-erc6123.md`: Daily accrual/settlement semantics. +- `pattern-performance-batching-blob-costing.md`: Batching, blobs, proof cadence, SLOs. +- `pattern-eligibility-attestations-eas-erc3643.md`: EAS + ERC-3643 eligibility/KYC flows. +- `pattern-policy-data-classification.md`: Map ICMA BDT fields → **Public / Confidential / Reg-only**. --- ## Adjacency patterns (useful, but not sufficient alone) Neutral notes on approaches folks often suggest; pair them with core patterns as needed. -- `pattern-adj-railgun-shielded-transactions.md` — Shielded DeFi; lacks issuer lifecycle, enforced regulator access, DvP. -- `pattern-adj-private-consortium-ledger.md` — Strong closed-network privacy; trade-offs vs public settlement/composability. -- `pattern-adj-htlc-cross-domain-swap.md` — Simple atomic swaps; brittle for regulated cross-domain DvP. -- `pattern-adj-delayed-post-trade-reporting.md` — Batch reports; needs on-demand audit & anchors to fit bonds. +- `pattern-adj-railgun-shielded-transactions.md`: Shielded DeFi; lacks issuer lifecycle, enforced regulator access, DvP. +- `pattern-adj-private-consortium-ledger.md`: Strong closed-network privacy; trade-offs vs public settlement/composability. +- `pattern-adj-htlc-cross-domain-swap.md`: Simple atomic swaps; brittle for regulated cross-domain DvP. +- `pattern-adj-delayed-post-trade-reporting.md`: Batch reports; needs on-demand audit & anchors to fit bonds. > For vendors that complement patterns (compliance orchestration, enterprise privacy stacks, etc.), see **`/vendors/README.md`**. Keep vendor notes neutral and link *back* to patterns (not vice-versa). diff --git a/patterns/_template.md b/patterns/_template.md index b0b6ff1..f9109cb 100644 --- a/patterns/_template.md +++ b/patterns/_template.md @@ -35,7 +35,7 @@ crops_profile: p: full | partial | none # Privacy (who sees what) s: high | medium | low # Security (trust model, assumptions) -# Narrative context for each CROPS dimension — where the badges drift up or +# Narrative context for each CROPS dimension: where the badges drift up or # down in practice. Replaces the ad-hoc "CROPS context" bullet in Trade-offs. crops_context: cr: "Reaches `high` on L1 permissionless pools. Drops to `low` on permissioned L2s with operator-controlled exit." @@ -66,16 +66,16 @@ standards: [ERC-20, ERC-5564, EIP-7573] # Cross-references to other patterns. Replaces the old `dependencies` field # and the pattern-to-pattern links that used to live in `## See also`. -# Each entry is a slug matching patterns/pattern-.md — no paths, just +# Each entry is a slug matching patterns/pattern-.md: no paths, just # the slug. The validator resolves and checks the file exists. related_patterns: - requires: [pattern-shielding] # hard dependency — can't implement this without it + requires: [pattern-shielding] # hard dependency: can't implement this without it composes_with: [pattern-stealth-addresses] # works well together, optional alternative_to: [pattern-tee-based-privacy] # competing approach to the same problem see_also: [pattern-forced-withdrawal] # related for context # Known implementations (plural, neutral). Renamed from "reference -# implementation" — that phrase has a specific meaning in standards contexts. +# implementation"; that phrase has a specific meaning in standards contexts. open_source_implementations: - url: https://github.com/Railgun-Privacy/contract description: "Railgun shielded pool (L1, production)" @@ -107,8 +107,8 @@ One short paragraph: the job this pattern does. What makes up this pattern. Primitives, on-chain code, and off-chain services all belong here. Each item gets a short note on its role. -- — -- — +- : +- : If a component is also a standalone pattern in this map, link it via `related_patterns` rather than describing it in depth here. @@ -147,7 +147,7 @@ not here. ## Example -"Bank A sells €5m zero-coupon to Bank B…" — 3-5 bullets showing flow. +"Bank A sells €5m zero-coupon to Bank B…": 3-5 bullets showing flow. Optional for `type: meta` patterns. ## See also diff --git a/patterns/pattern-plasma-stateless-privacy.md b/patterns/pattern-plasma-stateless-privacy.md index 30d4354..213764f 100644 --- a/patterns/pattern-plasma-stateless-privacy.md +++ b/patterns/pattern-plasma-stateless-privacy.md @@ -52,8 +52,8 @@ related_patterns: see_also: [pattern-forced-withdrawal, pattern-l2-encrypted-offchain-audit] open_source_implementations: - - url: https://github.com/ethereum/iptf-pocs/tree/master/pocs/private-payment/plasma - description: "IPTF PoC scaffolding an Intmax2-style stateless Plasma private-payment stack" + - url: https://github.com/ethsystems/pocs/tree/master/pocs/private-payment/plasma + description: "EthSystems PoC scaffolding an Intmax2-style stateless Plasma private-payment stack" language: "Rust, Solidity" --- diff --git a/patterns/pattern-privacy-l2s.md b/patterns/pattern-privacy-l2s.md index 9f0a3db..4bd7340 100644 --- a/patterns/pattern-privacy-l2s.md +++ b/patterns/pattern-privacy-l2s.md @@ -56,8 +56,8 @@ open_source_implementations: - url: https://github.com/0xMiden/miden-node description: "Miden zkVM client-side proving rollup" language: "Rust" - - url: https://github.com/ethereum/iptf-pocs/tree/master/pocs/private-bond/privacy-l2 - description: "IPTF PoC: private institutional bond on a privacy L2" + - url: https://github.com/ethsystems/pocs/tree/master/pocs/private-bond/privacy-l2 + description: "EthSystems PoC: private institutional bond on a privacy L2" language: "Noir, Solidity" --- diff --git a/patterns/pattern-shielding.md b/patterns/pattern-shielding.md index 66ee8dc..e04fd35 100644 --- a/patterns/pattern-shielding.md +++ b/patterns/pattern-shielding.md @@ -44,8 +44,8 @@ open_source_implementations: - url: https://github.com/Railgun-Privacy/contract description: "Railgun shielded pool (L1, production)" language: "Solidity, Circom" - - url: https://github.com/ethereum/iptf-pocs/tree/master/pocs/private-payment - description: "IPTF PoC (UltraHonk/Noir, research)" + - url: https://github.com/ethsystems/pocs/tree/master/pocs/private-payment + description: "EthSystems PoC (UltraHonk/Noir, research)" language: "Noir, Solidity" - url: https://github.com/AztecProtocol/aztec-packages description: "Aztec Network, privacy L2 with native shielding (production)" @@ -108,5 +108,5 @@ Threat model: - [Railgun](../vendors/railgun.md) - [Hinkal](../vendors/hinkal.md) - [Aztec](../vendors/aztec.md) -- [Exploring hardened shielded pools](https://iptf.ethereum.org/blog/exploring-hardened-shielded-pools/) -- [Shielded-pool extension PoC](https://github.com/ethereum/iptf-pocs/tree/master/pocs/private-payment/shielded-pool-extension) +- [Exploring hardened shielded pools](https://ethsystems.org/blog/exploring-hardened-shielded-pools/) +- [Shielded-pool extension PoC](https://github.com/ethsystems/pocs/tree/master/pocs/private-payment/shielded-pool-extension) diff --git a/rfps/README.md b/rfps/README.md index 1a76f36..ef4a926 100644 --- a/rfps/README.md +++ b/rfps/README.md @@ -2,15 +2,15 @@ Preliminary research proposals for PSE (Privacy & Scaling Explorations) researchers and external grants. These are **non-critical-path** work items that strengthen the broader privacy ecosystem. -## Relationship to IPTF Core Work +## Relationship to EthSystems Core Work -| | IPTF Core Team | RFPs | +| | EthSystems Core Team | RFPs | |---|----------------|------| | **Focus** | Institutional PoCs (private bonds, stablecoins, DvP) | Research, tooling, benchmarks | | **Dependency** | Self-contained | No dependency on core team | | **Goal** | Prove it works for specific use cases | Make ecosystem better for everyone | -RFPs are **accelerators, not blockers**. They feed back into the public iptf-map repo but don't gate current PoC work. +RFPs are **accelerators, not blockers**. They feed back into the public EthSystems Map repo but don't gate current PoC work. ## Categories diff --git a/rfps/rfp-benchmark-dashboard.md b/rfps/rfp-benchmark-dashboard.md index 1eb0fc8..e88a5d5 100644 --- a/rfps/rfp-benchmark-dashboard.md +++ b/rfps/rfp-benchmark-dashboard.md @@ -54,24 +54,24 @@ Privacy L2 vendors claim 25k+ TPS, but institutions have no way to verify these - [ ] Benchmark harness repo (open source, Docker-based) - [ ] CI pipeline that runs weekly and publishes results -- [ ] Comparison dashboard (static site or markdown in iptf-map) +- [ ] Comparison dashboard (static site or markdown in EthSystems Map) - [ ] Methodology document (how to interpret results, caveats) -- [ ] Integration with iptf-map vendor pages (automated updates) +- [ ] Integration with EthSystems Map vendor pages (automated updates) ## Dependencies **Requires:** - Public testnet access for target systems -- Clear workload definitions (coordinate with IPTF team) +- Clear workload definitions (coordinate with EthSystems team) - Trust schema from [Trust Assurance](rfp-trust-assurance.md) for complete picture **Enables:** - Data-driven vendor comparisons -- Input to [L2 Privacy Comparison Matrix](https://github.com/ethereum/iptf-map/issues/27) +- Input to [L2 Privacy Comparison Matrix](https://github.com/ethsystems/map/issues/27) - Credible "reality check" for institutional presentations ## See Also -- [GitHub Issue #27](https://github.com/ethereum/iptf-map/issues/27) — Performance and trust assumptions mapping +- [GitHub Issue #27](https://github.com/ethsystems/map/issues/27) — Performance and trust assumptions mapping - [Vendors](../vendors/) — Systems to benchmark - [Pattern: DvP Settlement](../patterns/pattern-dvp-erc7573.md) — Example workload diff --git a/rfps/rfp-trust-assurance.md b/rfps/rfp-trust-assurance.md index 6ba8aeb..14267b9 100644 --- a/rfps/rfp-trust-assurance.md +++ b/rfps/rfp-trust-assurance.md @@ -43,7 +43,7 @@ Institutions evaluating privacy solutions ask "what am I trusting?" before "how ## Deliverables -- [ ] Assurance card template (markdown format, compatible with iptf-map patterns) +- [ ] Assurance card template (markdown format, compatible with EthSystems Map patterns) - [ ] 4-6 completed assurance cards for major privacy system types - [ ] "Red team scenarios" document (3-5 attack scenarios per system type) - [ ] Controls mapping guide for institutional risk teams @@ -64,4 +64,4 @@ Institutions evaluating privacy solutions ask "what am I trusting?" before "how - [Pattern: TEE-Based Privacy](../patterns/pattern-tee-based-privacy.md) - [Pattern: Threshold Encrypted Mempool](../patterns/pattern-threshold-encrypted-mempool.md) - [Vendors](../vendors/) — Systems to analyze -- [GitHub Issue #27](https://github.com/ethereum/iptf-map/issues/27) — Performance and trust assumptions mapping +- [GitHub Issue #27](https://github.com/ethsystems/map/issues/27) — Performance and trust assumptions mapping diff --git a/scripts/check-terminology.js b/scripts/check-terminology.js index 4e56b0e..c06ed96 100644 --- a/scripts/check-terminology.js +++ b/scripts/check-terminology.js @@ -1,6 +1,6 @@ #!/usr/bin/env node /** - * GLOSSARY.md Term Consistency Checker for IPTF Map + * GLOSSARY.md Term Consistency Checker for EthSystems Map * Parses GLOSSARY.md and checks all files for canonical term usage * * Usage: diff --git a/scripts/llm-review.js b/scripts/llm-review.js index 3ecad64..2a760e7 100644 --- a/scripts/llm-review.js +++ b/scripts/llm-review.js @@ -1,6 +1,6 @@ #!/usr/bin/env node /** - * LLM-Based Content Review Tool for IPTF Map + * LLM-Based Content Review Tool for EthSystems Map * * On-demand review of markdown files using Claude API to: * - Verify ERC/EIP numbers against ethereum.org @@ -133,7 +133,7 @@ async function reviewFile(filePath) { console.log(`${colors.cyan}Reviewing: ${fileName}${colors.reset}`); console.log(` Found ${standardRefs.length} standard references: ${standardRefs.join(', ') || 'none'}`); - const systemPrompt = `You are a technical documentation reviewer for the Institutional Privacy Task Force (IPTF) Map, a public reference repository for privacy-preserving solutions in enterprise Ethereum. + const systemPrompt = `You are a technical documentation reviewer for the EthSystems Map, a public reference repository for privacy-preserving solutions in enterprise Ethereum. Your task is to review documentation for: 1. Technical accuracy and consistency @@ -163,7 +163,7 @@ Concrete improvements to make the content more accurate and trustworthy. Be direct and specific. Only flag actual issues, not stylistic preferences.`; - const prompt = `Please review this documentation file for the IPTF Map repository: + const prompt = `Please review this documentation file for the EthSystems Map repository: File: ${fileName} @@ -209,7 +209,7 @@ async function main() { if (args.length === 0 || args.includes('--help') || args.includes('-h')) { console.log(` -${colors.bold}LLM Content Review Tool for IPTF Map${colors.reset} +${colors.bold}LLM Content Review Tool for EthSystems Map${colors.reset} Usage: ANTHROPIC_API_KEY=sk-... node scripts/llm-review.js [file2.md ...] @@ -255,7 +255,7 @@ This tool uses Claude to review documentation for: process.exit(1); } - console.log(`${colors.bold}IPTF Map LLM Content Review${colors.reset}`); + console.log(`${colors.bold}EthSystems Map LLM Content Review${colors.reset}`); console.log(`Reviewing ${files.length} file(s)...`); console.log(''); diff --git a/scripts/package.json b/scripts/package.json index 1c6eb51..c2a8f26 100644 --- a/scripts/package.json +++ b/scripts/package.json @@ -1,7 +1,7 @@ { - "name": "iptf-map-validation", + "name": "map-validation", "version": "1.0.0", - "description": "Validation scripts for IPTF Map documentation", + "description": "Validation scripts for EthSystems Map documentation", "main": "validate-patterns.js", "scripts": { "validate": "node validate-patterns.js", diff --git a/scripts/schemas/jurisdiction.json b/scripts/schemas/jurisdiction.json index b82a45c..a6ba7b4 100644 --- a/scripts/schemas/jurisdiction.json +++ b/scripts/schemas/jurisdiction.json @@ -1,8 +1,8 @@ { "$schema": "http://json-schema.org/draft-07/schema#", - "$id": "https://iptf-map.ethereum.org/schemas/jurisdiction.json", - "title": "IPTF Jurisdiction Frontmatter", - "description": "Schema for jurisdiction document frontmatter in IPTF Map", + "$id": "https://ethsystems.org/schemas/jurisdiction.json", + "title": "EthSystems Jurisdiction Frontmatter", + "description": "Schema for jurisdiction document frontmatter in EthSystems Map", "type": "object", "required": ["title", "status", "region"], "properties": { diff --git a/scripts/schemas/pattern.json b/scripts/schemas/pattern.json index e30b419..1977fe0 100644 --- a/scripts/schemas/pattern.json +++ b/scripts/schemas/pattern.json @@ -1,8 +1,8 @@ { "$schema": "http://json-schema.org/draft-07/schema#", - "$id": "https://iptf-map.ethereum.org/schemas/pattern.json", - "title": "IPTF Pattern Frontmatter (v2)", - "description": "Schema for pattern document frontmatter in IPTF Map. All v1 aliases have been removed. Structured context_differentiation, crops_context, post_quantum, related_patterns, open_source_implementations, and meta-pattern support are the canonical shape.", + "$id": "https://ethsystems.org/schemas/pattern.json", + "title": "EthSystems Pattern Frontmatter (v2)", + "description": "Schema for pattern document frontmatter in EthSystems Map. All v1 aliases have been removed. Structured context_differentiation, crops_context, post_quantum, related_patterns, open_source_implementations, and meta-pattern support are the canonical shape.", "type": "object", "required": ["title", "status", "maturity", "crops_profile"], "properties": { diff --git a/scripts/schemas/use-case.json b/scripts/schemas/use-case.json index 2443b95..5ff3962 100644 --- a/scripts/schemas/use-case.json +++ b/scripts/schemas/use-case.json @@ -1,8 +1,8 @@ { "$schema": "http://json-schema.org/draft-07/schema#", - "$id": "https://iptf-map.ethereum.org/schemas/use-case.json", - "title": "IPTF Use Case Frontmatter", - "description": "Schema for use case document frontmatter in IPTF Map", + "$id": "https://ethsystems.org/schemas/use-case.json", + "title": "EthSystems Use Case Frontmatter", + "description": "Schema for use case document frontmatter in EthSystems Map", "type": "object", "required": ["title"], "properties": { diff --git a/scripts/schemas/vendor.json b/scripts/schemas/vendor.json index 4622e72..55955c5 100644 --- a/scripts/schemas/vendor.json +++ b/scripts/schemas/vendor.json @@ -1,8 +1,8 @@ { "$schema": "http://json-schema.org/draft-07/schema#", - "$id": "https://iptf-map.ethereum.org/schemas/vendor.json", - "title": "IPTF Vendor Frontmatter", - "description": "Schema for vendor document frontmatter in IPTF Map", + "$id": "https://ethsystems.org/schemas/vendor.json", + "title": "EthSystems Vendor Frontmatter", + "description": "Schema for vendor document frontmatter in EthSystems Map", "type": "object", "required": ["title", "status"], "properties": { diff --git a/scripts/validate-patterns.js b/scripts/validate-patterns.js index e9e182a..fc3c6a7 100644 --- a/scripts/validate-patterns.js +++ b/scripts/validate-patterns.js @@ -1,6 +1,6 @@ #!/usr/bin/env node /** - * Pattern Validation Script for IPTF Map + * Pattern Validation Script for EthSystems Map * Validates pattern and vendor documents against PRD requirements */ diff --git a/use-cases/README.md b/use-cases/README.md index d22f66f..755f957 100644 --- a/use-cases/README.md +++ b/use-cases/README.md @@ -1,6 +1,6 @@ # Use Cases -**What this is.** One-page briefs that define a business problem, evidence, requirements, and acceptance criteria—then point to recommended approaches. Use cases drive decisions; patterns and approaches explain *how*. +**What this is.** One-page briefs that define a business problem, evidence, requirements, and acceptance criteria, then point to recommended approaches. Use cases drive decisions; patterns and approaches explain *how*. **How to use.** Create a new file per scenario using the template below. Be clear on what must be private, regulator access, and DvP/finality needs. Link only the most relevant patterns and approaches; capture the decision and next steps. diff --git a/use-cases/private-bonds.md b/use-cases/private-bonds.md index 5e8b602..783c950 100644 --- a/use-cases/private-bonds.md +++ b/use-cases/private-bonds.md @@ -40,7 +40,7 @@ Public chains expose volumes, prices, and positions by default, enabling front-r See detailed solution architecture and trade-offs in [**Approach: Private Bonds**](../approaches/approach-private-bonds.md). -**PoC Implementation:** [Private Bond PoC](https://github.com/ethereum/iptf-pocs/tree/master/pocs/private-bond) — Two approaches: Custom UTXO (EVM) and Privacy L2 (Aztec). +**PoC Implementation:** [Private Bond PoC](https://github.com/ethsystems/pocs/tree/master/pocs/private-bond); two approaches: Custom UTXO (EVM) and Privacy L2 (Aztec). ## 6) Open Questions @@ -54,6 +54,6 @@ _Notes below reference the PoC implementation._ ## 7) Notes And Links -- **Tracking:** Public workstream in [iptf-pocs / private-bond](https://github.com/ethereum/iptf-pocs/tree/master/pocs/private-bond) +- **Tracking:** Public workstream in [ethsystems/pocs / private-bond](https://github.com/ethsystems/pocs/tree/master/pocs/private-bond) - **Standards:** ERC-6123 (derivative/bond lifecycle), ERC-7573 (atomic cross-domain DvP), ICMA Bond Data Taxonomy (BDT) - **Current standards:** ERC-20 tokens; HTLC sequences for DvP (to be replaced by ERC-7573) diff --git a/use-cases/private-derivatives.md b/use-cases/private-derivatives.md index fb4d9ec..27bc9fd 100644 --- a/use-cases/private-derivatives.md +++ b/use-cases/private-derivatives.md @@ -51,5 +51,5 @@ See detailed solution architecture and trade-offs in [**Approach: Private Deriva ## 7) Notes And Links - **Standards:** [ERC-6123](https://eips.ethereum.org/EIPS/eip-6123), [ERC-7573](https://eips.ethereum.org/EIPS/eip-7573) (optional), confidential token patterns -- **Related use cases:** [Private Bonds](./private-bonds.md) — key difference is **daily cadence** and **oracle dependency** +- **Related use cases:** [Private Bonds](./private-bonds.md): key difference is **daily cadence** and **oracle dependency** - **Diff vs Private Bonds:** bonds = static, slow cadence; derivatives = dynamic, daily, oracle-driven diff --git a/use-cases/private-government-debt.md b/use-cases/private-government-debt.md index 5dddd0e..a9851c0 100644 --- a/use-cases/private-government-debt.md +++ b/use-cases/private-government-debt.md @@ -88,4 +88,4 @@ See [approach-private-bonds.md](../approaches/approach-private-bonds.md) for gen - Related: [private-bonds.md](private-bonds.md) (general bond pattern) - Related: [private-corporate-bonds.md](private-corporate-bonds.md) (higher privacy requirements) - Emerging market: Municipal debt tokenization gaining traction in Asia -- See also: [EPIC map](https://epic-webapp.vercel.app/) (GovTech & EPIC team) — treasury transparency, audit trails +- See also: [EPIC map](https://epic-webapp.vercel.app/) (GovTech & EPIC team): treasury transparency, audit trails diff --git a/use-cases/private-identity.md b/use-cases/private-identity.md index a522468..de44f87 100644 --- a/use-cases/private-identity.md +++ b/use-cases/private-identity.md @@ -7,7 +7,7 @@ secondary_domain: Civic Coordination & Governance ## 1) Use Case -Prove identity claims, membership, eligibility, or attribute possession on-chain without revealing the underlying identity or creating linkable activity. Authentication is one key application — others include credential portability, sybil resistance, and selective disclosure. Applies to financial compliance (KYC registry membership), governance (anonymous voting), national identity (selective disclosure from government documents), and community membership (sybil-resistant access). +Prove identity claims, membership, eligibility, or attribute possession on-chain without revealing the underlying identity or creating linkable activity. Authentication is one key application; others include credential portability, sybil resistance, and selective disclosure. Applies to financial compliance (KYC registry membership), governance (anonymous voting), national identity (selective disclosure from government documents), and community membership (sybil-resistant access). ## 2) Additional Context @@ -107,5 +107,5 @@ See detailed architecture and trade-offs in [**Approach: Private Identity**](../ - **ZK Frameworks:** [Semaphore](https://semaphore.pse.dev/), [Noir/Barretenberg](https://docs.aztec.network/), [Circom/Groth16](https://docs.circom.io/) - **Credential Systems:** [ZKPassport](https://zkpassport.id/), [Self](https://self.xyz/), [Rarimo](https://rarimo.com/), [Anon Aadhaar](https://github.com/anon-aadhaar), [zkEmail](https://prove.email/), [TLSNotary](https://tlsnotary.org/), [POD2](https://github.com/0xPARC/pod2), [OpenAC](https://eprint.iacr.org/2026/251) - **Validated Deployments:** [WFP Building Blocks](https://www.wfp.org/building-blocks), [OpenCerts](https://www.opencerts.io/) -- See also: [EPIC map](https://epic-webapp.vercel.app/) (GovTech & EPIC team, demo data) — verifiable credentials, KYC/KYB, licensing, selective disclosure +- See also: [EPIC map](https://epic-webapp.vercel.app/) (GovTech & EPIC team, demo data): verifiable credentials, KYC/KYB, licensing, selective disclosure - **Related Patterns:** [Private MTP Auth](../patterns/pattern-private-mtp-auth.md), [zk-TLS](../patterns/pattern-zk-tls.md), [Verifiable Attestation](../patterns/pattern-verifiable-attestation.md), [vOPRF Nullifiers](../patterns/pattern-voprf-nullifiers.md), [Selective Disclosure](../patterns/pattern-regulatory-disclosure-keys-proofs.md), [co-SNARK](../patterns/pattern-co-snark.md) diff --git a/use-cases/private-oracles.md b/use-cases/private-oracles.md index 9665acf..2a65618 100644 --- a/use-cases/private-oracles.md +++ b/use-cases/private-oracles.md @@ -51,7 +51,7 @@ Some institutions (particularly banks) are data providers/originators. Privacy r ### Problem 3: Data Provenance & Consent in Oracle Feeds -When oracles aggregate data from multiple institutional sources, data providers need assurance their contributions are used only as agreed. Consumers need provenance guarantees — knowing that the data originates from authorized sources, has not been tampered with, and was aggregated according to a verifiable methodology. Consent receipts (tamper-evident records of data-use agreements) can be anchored on-chain. +When oracles aggregate data from multiple institutional sources, data providers need assurance their contributions are used only as agreed. Consumers need provenance guarantees: knowing that the data originates from authorized sources, has not been tampered with, and was aggregated according to a verifiable methodology. Consent receipts (tamper-evident records of data-use agreements) can be anchored on-chain. **Requirements:** @@ -87,4 +87,4 @@ Consider: - Cross-cutting concern: affects all use cases requiring external data - Related: [private-read.md](private-read.md) (query privacy for blockchain state) - Related: [private-derivatives.md](private-derivatives.md) (oracle-dependent pricing) -- See also: [EPIC map](https://epic-webapp.vercel.app/) (GovTech & EPIC team) — consent, data sharing, audit trails +- See also: [EPIC map](https://epic-webapp.vercel.app/) (GovTech & EPIC team): consent, data sharing, audit trails diff --git a/use-cases/private-payments.md b/use-cases/private-payments.md index c90b65a..5cd00ce 100644 --- a/use-cases/private-payments.md +++ b/use-cases/private-payments.md @@ -91,7 +91,7 @@ See also [private-stablecoins.md](private-stablecoins.md) for stablecoin-specifi - Related: [private-stablecoins.md](private-stablecoins.md) (stablecoin-specific privacy) - Related: [private-fx.md](private-fx.md) (cross-currency payments) - Related: [private-treasuries.md](private-treasuries.md) (corporate payment context) -- Reference: [Private Payment PoC](https://github.com/ethereum/iptf-pocs/tree/master/pocs/private-payment) +- Reference: [Private Payment PoC](https://github.com/ethsystems/pocs/tree/master/pocs/private-payment) - Market context: Governments building digital currency infrastructure; cross-border payment networks exploring blockchain alternatives to SWIFT - Note: Transaction patterns are highly revealing of business and personal activity -- See also: [EPIC map](https://epic-webapp.vercel.app/) (GovTech & EPIC team) — G2P payments, aid disbursement +- See also: [EPIC map](https://epic-webapp.vercel.app/) (GovTech & EPIC team): G2P payments, aid disbursement diff --git a/use-cases/private-procurement.md b/use-cases/private-procurement.md index bcca450..83ee5f5 100644 --- a/use-cases/private-procurement.md +++ b/use-cases/private-procurement.md @@ -84,4 +84,4 @@ Approach TBD. Key architectural considerations: - Related patterns: [Commit and Prove](../patterns/pattern-commit-and-prove.md), [L2 Encrypted Offchain Audit](../patterns/pattern-l2-encrypted-offchain-audit.md), [Verifiable Attestation](../patterns/pattern-verifiable-attestation.md) - Related use cases: [private-payments.md](private-payments.md) (payment privacy), [private-government-debt.md](private-government-debt.md) (sealed auction parallels) -- See also: [EPIC map](https://epic-webapp.vercel.app/) (GovTech & EPIC team) — procurement & invoicing, audit trails, grants tracking +- See also: [EPIC map](https://epic-webapp.vercel.app/) (GovTech & EPIC team): procurement & invoicing, audit trails, grants tracking diff --git a/use-cases/private-registry.md b/use-cases/private-registry.md index 80f3d73..af36fdd 100644 --- a/use-cases/private-registry.md +++ b/use-cases/private-registry.md @@ -7,7 +7,7 @@ secondary_domain: Funds & Assets ## 1) Use Case -Operating authoritative registries (securities holders, business entities, licenses, environmental permits) on-chain where registry entries must be verifiable by authorized parties but the full registry state must not be publicly exposed. Distinct from authentication (which proves membership in a registry) — this use case is about institutions that *run* registries: maintaining records, processing updates, and enabling cross-border lookups, all with privacy. +Operating authoritative registries (securities holders, business entities, licenses, environmental permits) on-chain where registry entries must be verifiable by authorized parties but the full registry state must not be publicly exposed. Distinct from authentication (which proves membership in a registry); this use case is about institutions that *run* registries: maintaining records, processing updates, and enabling cross-border lookups, all with privacy. ## 2) Additional Context @@ -84,5 +84,5 @@ Approach TBD. Key architectural considerations: ## 7) Notes And Links - Related patterns: [Crypto-Registry Bridge (eWpG/EAS)](../patterns/pattern-crypto-registry-bridge-ewpg-eas.md), [Verifiable Attestation](../patterns/pattern-verifiable-attestation.md), [Private MTP Auth](../patterns/pattern-private-mtp-auth.md) -- Related use cases: [private-identity.md](private-identity.md) (consuming registries for authentication — this use case is about operating them) -- See also: [EPIC map](https://epic-webapp.vercel.app/) (GovTech & EPIC team, demo data) — business registry, land registry, environmental registries, licensing +- Related use cases: [private-identity.md](private-identity.md) (consuming registries for authentication; this use case is about operating them) +- See also: [EPIC map](https://epic-webapp.vercel.app/) (GovTech & EPIC team, demo data): business registry, land registry, environmental registries, licensing diff --git a/use-cases/private-stablecoins.md b/use-cases/private-stablecoins.md index d918faf..26aef48 100644 --- a/use-cases/private-stablecoins.md +++ b/use-cases/private-stablecoins.md @@ -53,11 +53,11 @@ See detailed solution architecture and trade-offs in [**Approach: Private Paymen ### Non‑Solutions -- **Public ledger without privacy** — transaction details exposed to all observers; fails institutional confidentiality requirements -- **Simple payload encryption** — breaks on-chain verifiability, atomic settlement, and composability with other protocols -- **HTLC-only atomicity** — incentive misalignment and timeout brittleness compared to conditional settlement standards like ERC‑7573 ([analysis](https://www.ndss-symposium.org/wp-content/uploads/2023-775-paper.pdf)) -- **Fully private infrastructure** — conflicts with regulatory transparency requirements and limits interoperability -- **FHE alone for unlinkability** — provides confidentiality but does not hide address linkage; requires additional privacy layer (stealth addresses or similar) +- **Public ledger without privacy**: transaction details exposed to all observers; fails institutional confidentiality requirements +- **Simple payload encryption**: breaks on-chain verifiability, atomic settlement, and composability with other protocols +- **HTLC-only atomicity**: incentive misalignment and timeout brittleness compared to conditional settlement standards like ERC‑7573 ([analysis](https://www.ndss-symposium.org/wp-content/uploads/2023-775-paper.pdf)) +- **Fully private infrastructure**: conflicts with regulatory transparency requirements and limits interoperability +- **FHE alone for unlinkability**: provides confidentiality but does not hide address linkage; requires additional privacy layer (stealth addresses or similar) ## 6) Open Questions @@ -74,8 +74,8 @@ See detailed solution architecture and trade-offs in [**Approach: Private Paymen ### Related patterns -- [Stateless Plasma Privacy](../patterns/pattern-plasma-stateless-privacy.md) — Onboarding privacy via client-side proving -- [TEE-Based Privacy](../patterns/pattern-tee-based-privacy.md) — Issuer-side private minting +- [Stateless Plasma Privacy](../patterns/pattern-plasma-stateless-privacy.md): Onboarding privacy via client-side proving +- [TEE-Based Privacy](../patterns/pattern-tee-based-privacy.md): Issuer-side private minting - [Private Stablecoin Shielded Payments](../patterns/pattern-private-stablecoin-shielded-payments.md) - [Private PvP Settlement](../patterns/pattern-private-pvp-stablecoins-erc7573.md) - [DvP via ERC-7573](../patterns/pattern-dvp-erc7573.md) diff --git a/use-cases/private-supply-chain.md b/use-cases/private-supply-chain.md index 04a7889..8815cbc 100644 --- a/use-cases/private-supply-chain.md +++ b/use-cases/private-supply-chain.md @@ -85,4 +85,4 @@ Approach TBD. Key architectural considerations: - Related patterns: [Verifiable Attestation](../patterns/pattern-verifiable-attestation.md), [L2 Encrypted Offchain Audit](../patterns/pattern-l2-encrypted-offchain-audit.md), [Commit and Prove](../patterns/pattern-commit-and-prove.md) - Regulatory drivers: EU Falsified Medicines Directive (FMD), US Drug Supply Chain Security Act (DSCSA) -- See also: [EPIC map](https://epic-webapp.vercel.app/) (GovTech & EPIC team) — pharmaceuticals, food aid, supply integrity, customs +- See also: [EPIC map](https://epic-webapp.vercel.app/) (GovTech & EPIC team): pharmaceuticals, food aid, supply integrity, customs diff --git a/use-cases/resilient-disbursement-rails.md b/use-cases/resilient-disbursement-rails.md index 49bb71b..4854afa 100644 --- a/use-cases/resilient-disbursement-rails.md +++ b/use-cases/resilient-disbursement-rails.md @@ -101,8 +101,8 @@ See the [Resilient Disbursement Rails approach](../approaches/approach-private-p ## 7) Notes And Links -- **Spec:** [Resilient Disbursement Rails Protocol Specification](https://github.com/ethereum/iptf-pocs/blob/master/pocs/private-payment/resilient-disbursement-rails/SPEC.md) -- **PoC:** [Resilient Disbursement Rails](https://github.com/ethereum/iptf-pocs/tree/master/pocs/private-payment/resilient-disbursement-rails) +- **Spec:** [Resilient Disbursement Rails Protocol Specification](https://github.com/ethsystems/pocs/blob/master/pocs/private-payment/resilient-disbursement-rails/SPEC.md) +- **PoC:** [Resilient Disbursement Rails](https://github.com/ethsystems/pocs/tree/master/pocs/private-payment/resilient-disbursement-rails) - **Sibling Use Case:** [Resilient Identity Continuity](resilient-identity-continuity.md) - **Approach:** [Private Payments: Resilient Disbursement Rails](../approaches/approach-private-payments.md#resilient-disbursement-rails); identity-layer dependency: [Private Identity: Issuer-Independent Enrollment](../approaches/approach-private-identity.md#issuer-independent-enrollment-via-distributed-oprf) - **Standards:** [RFC 6979](https://www.rfc-editor.org/rfc/rfc6979) (deterministic ECDSA), [EIP-2](https://eips.ethereum.org/EIPS/eip-2) (canonical-s), [NIST SP 800-88](https://csrc.nist.gov/publications/detail/sp/800-88/rev-1/final) (media sanitization), [BSI-CC-PP-0084](https://www.bsi.bund.de/dok/CC-PP-0084) (smartcard SE protection profile) diff --git a/use-cases/resilient-identity-continuity.md b/use-cases/resilient-identity-continuity.md index c70a3da..00d9ec3 100644 --- a/use-cases/resilient-identity-continuity.md +++ b/use-cases/resilient-identity-continuity.md @@ -98,7 +98,7 @@ See the [**Issuer-Independent Enrollment approach**](../approaches/approach-priv ## 7) Notes And Links - **Extends:** [Private Identity](private-identity.md) (drops the cooperative-issuer assumption) -- **PoC:** [Resilient Private Identity](https://github.com/ethereum/iptf-pocs/tree/master/pocs/private-identity/resilient-private-identity) +- **PoC:** [Resilient Private Identity](https://github.com/ethsystems/pocs/tree/master/pocs/private-identity/resilient-private-identity) - **Standards:** [RFC 9497 (OPRF)](https://www.rfc-editor.org/rfc/rfc9497) + [Jarecki threshold extension](https://eprint.iacr.org/2017/363), [RFC 9380 (hashToCurve)](https://www.rfc-editor.org/rfc/rfc9380), [W3C VC Data Model v2.0](https://www.w3.org/TR/vc-data-model-2.0/) - **Credential Systems:** [ZKPassport](https://zkpassport.id/), [Self](https://self.xyz/), [Anon Aadhaar](https://github.com/anon-aadhaar), [World ID](https://worldcoin.org/world-id), [zkEmail](https://prove.email/), [TLSNotary](https://tlsnotary.org/), [Semaphore](https://semaphore.pse.dev/), [Human Passport](https://passport.human.tech/), [Holonym](https://holonym.id/) - **Related Patterns:** [Private MTP Auth](../patterns/pattern-private-mtp-auth.md), [vOPRF Nullifiers](../patterns/pattern-voprf-nullifiers.md), [Selective Disclosure](../patterns/pattern-regulatory-disclosure-keys-proofs.md), [zk-TLS](../patterns/pattern-zk-tls.md), [Verifiable Attestation](../patterns/pattern-verifiable-attestation.md) diff --git a/vendors/README.md b/vendors/README.md index 8db4311..d384487 100644 --- a/vendors/README.md +++ b/vendors/README.md @@ -2,9 +2,9 @@ **Purpose.** Neutral documentation on products that can **complement** patterns (e.g., compliance orchestration, enterprise privacy groups). These are _not_ patterns; they point to the patterns they fit with. -**Vendor scope (CROPS-aligned):** IPTF lists vendors whose products are Ethereum-aligned and evaluated against the four CROPS dimensions. This includes products built for or deployed on Ethereum mainnet or production L2s, as well as multichain solutions that benefit the Ethereum ecosystem—e.g., by supporting Ethereum standards (EIPs/ERCs), advancing shared privacy patterns, or bringing institutional adoption that strengthens Ethereum's position. We exclude offerings that primarily serve non-Ethereum L1s without meaningful Ethereum integration or benefit. Borderline cases are marked "Maybe" with a one-line rationale. +**Vendor scope (CROPS-aligned):** EthSystems lists vendors whose products are Ethereum-aligned and evaluated against the four CROPS dimensions. This includes products built for or deployed on Ethereum mainnet or production L2s, as well as multichain solutions that benefit the Ethereum ecosystem, e.g., by supporting Ethereum standards (EIPs/ERCs), advancing shared privacy patterns, or bringing institutional adoption that strengthens Ethereum's position. We exclude offerings that primarily serve non-Ethereum L1s without meaningful Ethereum integration or benefit. Borderline cases are marked "Maybe" with a one-line rationale. -**CROPS evaluation criteria.** CROPS is assessed per product, not per vendor — a single vendor may offer products with different profiles. Each product is evaluated across the four dimensions. +**CROPS evaluation criteria.** CROPS is assessed per product, not per vendor; a single vendor may offer products with different profiles. Each product is evaluated across the four dimensions. See [CONTRIBUTING.md § CROPS Evaluation](../CONTRIBUTING.md#crops-evaluation) for full scoring rubrics. diff --git a/vendors/fairblock.md b/vendors/fairblock.md index aea3176..4d2f3a6 100644 --- a/vendors/fairblock.md +++ b/vendors/fairblock.md @@ -4,7 +4,7 @@ status: ready maturity: testnet --- -# Fairblock — Cross-chain Confidential Transfers (lightweight homomorphic ops + ZK) +# Fairblock: Cross-chain Confidential Transfers (lightweight homomorphic ops + ZK) ## What it is diff --git a/vendors/fhenix.md b/vendors/fhenix.md index 7f9b89c..2a502df 100644 --- a/vendors/fhenix.md +++ b/vendors/fhenix.md @@ -12,11 +12,11 @@ Fhenix builds a CoProcessor that brings Fully Homomorphic Encryption (FHE) to EV ## Fits with patterns -- [Private Stablecoin Shielded Payments](https://github.com/ethereum/iptf-map/blob/master/patterns/pattern-private-stablecoin-shielded-payments.md) - FHE enables encrypted balances and amounts, supporting fully confidential stablecoin transfers. -- [Private Intent-Based Vaults](https://github.com/ethereum/iptf-map/blob/master/patterns/pattern-private-vaults.md) - FHE-powered execution allows vault strategies to run privately while preserving on-chain auditability of assets. -- [Shielded ERC-20 Transfers](https://github.com/ethereum/iptf-map/blob/master/patterns/pattern-shielding.md) - Native FHE support provides encrypted ERC-20 transfer flows for end-to-end confidentiality. -- [Confidential ERC3643](https://github.com/ethereum/iptf-map/blob/master/patterns/pattern-erc3643-rwa.md) - FHE makes it possible to extend ERC3643 into a confidential standard with private, enforceable compliance logic. -- [Private L2s](https://github.com/ethereum/iptf-map/blob/master/patterns/pattern-privacy-l2s.md) - Fhenix’s CoFHE serves as an FHE coprocessor enabling privacy-preserving rollups and encrypted execution environments. +- [Private Stablecoin Shielded Payments](https://github.com/ethsystems/map/blob/master/patterns/pattern-private-stablecoin-shielded-payments.md) - FHE enables encrypted balances and amounts, supporting fully confidential stablecoin transfers. +- [Private Intent-Based Vaults](https://github.com/ethsystems/map/blob/master/patterns/pattern-private-vaults.md) - FHE-powered execution allows vault strategies to run privately while preserving on-chain auditability of assets. +- [Shielded ERC-20 Transfers](https://github.com/ethsystems/map/blob/master/patterns/pattern-shielding.md) - Native FHE support provides encrypted ERC-20 transfer flows for end-to-end confidentiality. +- [Confidential ERC3643](https://github.com/ethsystems/map/blob/master/patterns/pattern-erc3643-rwa.md) - FHE makes it possible to extend ERC3643 into a confidential standard with private, enforceable compliance logic. +- [Private L2s](https://github.com/ethsystems/map/blob/master/patterns/pattern-privacy-l2s.md) - Fhenix’s CoFHE serves as an FHE coprocessor enabling privacy-preserving rollups and encrypted execution environments. ## Not a substitute for @@ -34,7 +34,7 @@ CoFHE, Fhenix’s encrypted-computation coprocessor, enables smart contracts to ## Enterprise demand and use cases -- Financial institutions: [private stablecoin](https://github.com/ethereum/iptf-map/blob/master/use-cases/private-stablecoins.md) transfers, on-chain strategies management and [RWA tokenization](https://github.com/ethereum/iptf-map/blob/master/use-cases/private-rwa-tokenization.md). +- Financial institutions: [private stablecoin](https://github.com/ethsystems/map/blob/master/use-cases/private-stablecoins.md) transfers, on-chain strategies management and [RWA tokenization](https://github.com/ethsystems/map/blob/master/use-cases/private-rwa-tokenization.md). - Treasury managers: confidential DeFi strategies, conditional orders and portfolio management. - Private or dual-mode stablecoins, on-chain private intents, confidential lending markets and privacy-preserving yield strategies. diff --git a/vendors/miden.md b/vendors/miden.md index f0fe8e6..dc0beaf 100644 --- a/vendors/miden.md +++ b/vendors/miden.md @@ -53,7 +53,7 @@ Unlike Ethereum (where the network executes everything), Miden pushes execution - A high-performance STARK prover (Winterfell) used to generate proofs for the Miden VM. - L1/L2 communication bridging still to be defined. - Native account abstraction at the protocol level; accounts are smart contracts with updatable code. -- Because users generate the proofs, the Sequencer is lightweight—it only aggregates proofs and builds blocks, preventing the "bottleneck" seen in EVM rollups. +- Because users generate the proofs, the Sequencer is lightweight: it only aggregates proofs and builds blocks, preventing the "bottleneck" seen in EVM rollups. ## Strengths diff --git a/vendors/peer.md b/vendors/peer.md index 34ba179..587f50c 100644 --- a/vendors/peer.md +++ b/vendors/peer.md @@ -37,7 +37,7 @@ Peer (ex-ZKP2P) is an open-source protocol that enables peer-to-peer fiat-to-cry ## Technical details -- **Proof system**: Vendor-agnostic — supports TLSNotary, Primus, and ZKEmail as proof backends. TEE attestation service validates proofs and produces EIP-712 attestations. +- **Proof system**: Vendor-agnostic; supports TLSNotary, Primus, and ZKEmail as proof backends. TEE attestation service validates proofs and produces EIP-712 attestations. - **Supported rails**: Venmo, Revolut, and additional payment providers supported via the V3 unified verification architecture. - **Settlement chain**: Ethereum and L2s. - **Client-side**: Browser extension handles TLS session co-signing and proof generation. @@ -46,15 +46,15 @@ Peer (ex-ZKP2P) is an open-source protocol that enables peer-to-peer fiat-to-cry ## Strengths - Fully open-source protocol and client tooling -- No custodial intermediary — settlement is peer-to-peer with onchain escrow -- Payment privacy preserved — zero-knowledge proofs reveal necessary payment attributes without exposing full account details +- No custodial intermediary; settlement is peer-to-peer with onchain escrow +- Payment privacy preserved; zero-knowledge proofs reveal necessary payment attributes without exposing full account details - Extensible to payment rails with TLS-accessible confirmation endpoints - Permissionless participation for both liquidity providers and takers ## Risks and open questions - **TEE trust**: V3 relies on TEE attestation services for offchain proof verification. TEE hardware vulnerabilities (side-channel attacks, firmware exploits) could compromise attestation integrity. -- **Attestor centralization**: Although rotating attestors distribute trust, the attestor set must be managed — a compromised or colluding majority could produce false attestations. +- **Attestor centralization**: Although rotating attestors distribute trust, the attestor set must be managed: a compromised or colluding majority could produce false attestations. - **Notary trust**: Underlying zk-TLS still requires a trusted Notary to co-sign TLS sessions. Malicious or compromised Notary can forge proofs or deny service. - **Payment rail stability**: Changes to payment provider APIs or TLS configurations can break proof generation. - **Regulatory uncertainty**: P2P fiat-to-crypto onramps may face regulatory scrutiny depending on jurisdiction. diff --git a/vendors/space-and-time.md b/vendors/space-and-time.md index 6205887..89a4077 100644 --- a/vendors/space-and-time.md +++ b/vendors/space-and-time.md @@ -75,7 +75,7 @@ The proof can be verified by an EVM-compatible verifier contract, enabling downs - **Data freshness / ingestion guarantees:** “Tamperproof” depends on how data is inserted, permissioned, and fingerprinted. All data queried from onchain EVM sources is attested, but offchain data can be tampered by the source. - **Privacy is not automatic:** Predicate-style privacy is possible, but outputs can still leak if the query is misrepresented. Sensitive workloads require careful query/result design and access controls. -- **Contract/security surface:** Verifier + relayer contracts become critical infrastructure—audits, upgrade policies, and chain-by-chain deployments matter. +- **Contract/security surface:** Verifier + relayer contracts become critical infrastructure: audits, upgrade policies, and chain-by-chain deployments matter. ## Links diff --git a/vendors/tx-shield.md b/vendors/tx-shield.md index 5a92418..3bb45eb 100644 --- a/vendors/tx-shield.md +++ b/vendors/tx-shield.md @@ -6,19 +6,19 @@ status: ready # TX-SHIELD – Institutional Privacy Infrastructure TX-SHIELD develops regulated privacy-preserving infrastructure for institutional payments (TX-SHIELD), private AI collaboration (OpenTMP LLM), and MPC-TSS key management (Collab-Key). -TX-SHIELD’s three core solutions — **TX-SHIELD**, **OpenTMP LLM**, and **Collab-Key** — address compliance, compute, and custody privacy challenges faced by regulated institutions. +TX-SHIELD’s three core solutions, **TX-SHIELD**, **OpenTMP LLM**, and **Collab-Key**, address compliance, compute, and custody privacy challenges faced by regulated institutions. --- ## What it is TX-SHIELD builds modular privacy layers/solutions for institutional finance and AI systems: -- **TX-SHIELD** — a regulated private payment layer/solution built on MPC-based encryption and threshold key control. +- **TX-SHIELD**: a regulated private payment layer/solution built on MPC-based encryption and threshold key control. It enables confidential settlement for stablecoins, RWAs, and bonds while ensuring regulator-auditable transparency. Transactions are visible only to stakeholders, while regulators can access details through granted audit keys. -- **OpenTMP LLM** — is a distributed edge AI training and inference framework designed for privacy-preserving large-language model collaboration. It combines federated learning and multi-party computation (MPC-FL) to keep data local while enabling encrypted aggregation and joint model updates. It powers collaborative, effcient, secure, and governable AI training across distributed environments. +- **OpenTMP LLM**: a distributed edge AI training and inference framework designed for privacy-preserving large-language model collaboration. It combines federated learning and multi-party computation (MPC-FL) to keep data local while enabling encrypted aggregation and joint model updates. It powers collaborative, effcient, secure, and governable AI training across distributed environments. -- **Collab-Key** — is a high-performance MPC-TSS framework integrated with CrossBar’s EMPC + ReRAM hardware to provide a unified, privacy-preserving stack for institutional custody and payments. By executing multi-party ECDSA signing within a ReRAM-backed secure element, the solution ensures that full private keys are never reconstructed, eliminating single points of failure at both algorithmic and physical layers. Featuring an offline-by-default architecture and FIDO2 authentication, this integration provides high-assurance protection and regulator-auditable transparency for stablecoins, RWAs, and digital bonds. +- **Collab-Key**: a high-performance MPC-TSS framework integrated with CrossBar’s EMPC + ReRAM hardware to provide a unified, privacy-preserving stack for institutional custody and payments. By executing multi-party ECDSA signing within a ReRAM-backed secure element, the solution ensures that full private keys are never reconstructed, eliminating single points of failure at both algorithmic and physical layers. Featuring an offline-by-default architecture and FIDO2 authentication, this integration provides high-assurance protection and regulator-auditable transparency for stablecoins, RWAs, and digital bonds. Each module can operate independently or as part of a unified privacy-preserving stack across payments, compute, and custody.