oskarth · Jan 14, 2026 · Jan 14, 2026 · Jan 14, 2026
@@ -108,21 +108,21 @@ Each deliverable scored on:
 
 ### Sprint 0: Infrastructure [Week 1, Days 1-2]
 
-**PR-001: CI Quality Gates**
+**PR-001: CI Quality Gates** ✅ DONE ([PR #40](https://github.com/ethereum/iptf-map/pull/40))
 ```
 Files: .github/workflows/ci.yml, scripts/validate-patterns.js
 DoD: Runs on every PR, blocks merge if checks fail
 Size: ~200 lines
 ```
 
-**PR-002: Pattern Validation Script**
+**PR-002: Pattern Validation Script** ✅ DONE ([PR #40](https://github.com/ethereum/iptf-map/pull/40))
 ```
 Files: scripts/check-frontmatter.py, scripts/check-sections.py
 DoD: Validates all required fields and sections
 Size: ~150 lines
 ```
 
-**PR-002b: Remediate Existing Pattern Warnings**
+**PR-002b: Remediate Existing Pattern Warnings** ✅ DONE ([PR #42](https://github.com/ethereum/iptf-map/pull/42))
 ```
 Files: 34 pattern files with CI warnings (see GitHub Issue #41)
 DoD: All patterns have required frontmatter fields, missing sections added, maturity values standardized

@@ -2,6 +2,10 @@
 title: "Pattern: co-SNARKs (Collaborative Proving)"
 status: draft
 maturity: PoC
+layer: hybrid
+privacy_goal: Enable multi-party ZK proving over distributed private inputs without disclosure
+assumptions: co-SNARK protocol infrastructure, MPC network coordination, honest majority among proving parties
+last_reviewed: 2026-01-14
 works-best-when:
   - Multiple parties each hold sensitive data or models, and need to jointly prove compliance, settlement, or state updates without revealing inputs.
 avoid-when:

@@ -2,6 +2,10 @@
 title: "Pattern: Commit-and-Prove Fallback"
 status: draft
 maturity: pilot
+layer: hybrid
+privacy_goal: Achieve conditional atomicity via shared commitments across chains
+assumptions: On-chain commitment contracts, coordination runbook, both parties accept coordination overhead
+last_reviewed: 2026-01-14
 works-best-when:
   - Both parties accept extra coordination overhead.
   - Circuit complexity or infra constraints block other patterns.

@@ -2,6 +2,10 @@
 title: "Pattern: Crypto-register bridge (eWpG) with EAS mirroring"
 status: ready
 maturity: pilot
+layer: hybrid
+privacy_goal: Mirror licensed crypto-register facts on-chain as attestations without exposing PII
+assumptions: Licensed crypto-register (eWpG), EAS infrastructure, registrar API access
+last_reviewed: 2026-01-14
 works-best-when:
   - Germany/eWpG applies and a licensed crypto-register is required.
 avoid-when:

@@ -2,6 +2,10 @@
 title: "Pattern: Atomic DvP via ERC-7573 (cross-network)"
 status: ready
 maturity: pilot
+layer: hybrid
+privacy_goal: Enable atomic cross-network DvP with optional privacy extensions
+assumptions: ERC-7573 contracts on both networks, stateless decryption oracle, trade negotiation system
+last_reviewed: 2026-01-14
 works-best-when:
   - Asset and cash legs live on different networks (L1/L2).
 avoid-when:

@@ -1,7 +1,11 @@
 ---
 title: "Pattern: EIL (Ethereum Interoperability Layer)"
 status: draft
-maturity: ready
+maturity: pilot
+layer: hybrid
+privacy_goal: No privacy improvements; provides censorship-resistant cross-L2 execution
+assumptions: ERC-4337 accounts, XLP infrastructure with L1 staking, L1 canonical bridge for disputes
+last_reviewed: 2026-01-14
 rollout-plan: ready to be integrated in wallets
 works-best-when:
   - User needs to execute calls on multiple L2s with one signature

@@ -1,7 +1,11 @@
 ---
 title: "Pattern: ERC-3643 Tokenized RWAs"
 status: ready
-maturity: prod
+maturity: production
+layer: L1
+privacy_goal: Enforce compliant token transfers with identity verification at contract level
+assumptions: ONCHAINID infrastructure, trusted claim issuers, ERC-734/735 key management
+last_reviewed: 2026-01-14
 works-best-when:
   - Regulatory compliance is mandatory
   - Need permissioned transfers with identity verification

@@ -1,7 +1,11 @@
 ---
 title: "Pattern: FOCIL - Fork-Choice Enforced Inclusion Lists"
 status: draft
-maturity: not yet recommended
+maturity: experimental
+layer: L1
+privacy_goal: No privacy; provides censorship resistance via forced transaction inclusion
+assumptions: EIP-7805 adoption, 1-of-16 honest IL committee member, consensus layer changes
+last_reviewed: 2026-01-14
 rollout-plan: glamsterdam or later forks
 works-best-when:
   - Censorship resistance is critical
@@ -16,6 +20,12 @@ dependencies: [EIP-7805]
 
 FOCIL (Fork-Choice Enforced Inclusion Lists) is an EIP that enables a committee of 16 validators to force-include transactions in blocks, preventing censorship by sophisticated block builders. FOCIL itself does not provide privacy, transactions remain fully visible in the public mempool and on-chain. It only guarantees that transactions cannot be censored once submitted to the mempool.
 
+## Ingredients
+
+- **Standards**: EIP-7805 (FOCIL specification)
+- **Infra**: Ethereum consensus layer with fork-choice enforcement, P2P gossip network for IL propagation
+- **Off-chain**: IL committee selection mechanism, equivocation detection
+
 ## Protocol (concise)
 
 1. Committee Selection (Slot N), a committee of 16 validators is selected for slot N to build ILs for slot N+1

@@ -1,7 +1,11 @@
 ---
 title: "Pattern: ICMA Bond Data Taxonomy (canonical terms/events)"
 status: ready
-maturity: prod
+maturity: production
+layer: offchain
+privacy_goal: Standardize bond data for clean attestations without exposing raw data
+assumptions: ICMA BDT schema adoption, schema validator tooling, registrar integration
+last_reviewed: 2026-01-14
 works-best-when:
   - You want machine-readable bond terms/events across tools.
 avoid-when:

@@ -2,6 +2,10 @@
 title: "Pattern: L1 ZK commitment pool (low volume)"
 status: ready
 maturity: pilot
+layer: L1
+privacy_goal: Hide amounts and positions on L1 via shielded pool with commitments and nullifiers
+assumptions: ZK proof system, prover infrastructure, ERC-3643/ERC-7573 integration
+last_reviewed: 2026-01-14
 works-best-when:
   - Low trade frequency; L2 not available or desirable.
 avoid-when:

@@ -2,6 +2,10 @@
 title: "Pattern: Low-cost L2 + Off-chain Encrypted Audit Log"
 status: ready
 maturity: pilot
+layer: hybrid
+privacy_goal: Hide amounts and positions with only commitments on-chain; encrypted audit log off-chain
+assumptions: L2 infrastructure, threshold KMS for scoped keys, EAS for access logging
+last_reviewed: 2026-01-14
 works-best-when:
   - Need hidden amounts/positions with minimal on-chain footprint.
   - Prefer cheap daily settlement over full on-chain private compute.

@@ -1,7 +1,11 @@
 ---
 title: Lean Ethereum
 status: draft
-maturity: research
+maturity: experimental
+layer: L1
+privacy_goal: No direct privacy; consensus redesign enabling light client verification
+assumptions: Post-quantum signatures, minimal zkVMs, 4-5 year research timeline, ~15 client teams
+last_reviewed: 2026-01-14
 works-best-when:
   - Long-term Ethereum consensus redesign needed
   - Solo validation accessibility matters

@@ -1,7 +1,11 @@
 ---
 title: "Pattern: MPC Custody and Transaction Control"
 status: draft
-maturity: prod
+maturity: production
+layer: offchain
+privacy_goal: Protect private keys via threshold distribution; no on-chain privacy of transactions
+assumptions: Threshold ECDSA/EdDSA infrastructure, MPC nodes in TEE/HSM, policy engine
+last_reviewed: 2026-01-14
 works-best-when:
   - Institutions require regulated-grade custody for digital assets
   - Key material must never exist in one place, but transactions must be orchestrated quickly

@@ -2,6 +2,10 @@
 title: "Pattern: Aztec Noir Private Contracts"
 status: ready
 maturity: pilot
+layer: L2
+privacy_goal: Enable composable private and public state in single contracts via ZK proofs
+assumptions: Aztec rollup infrastructure, client-side proving capability (8GB RAM), Barretenberg prover
+last_reviewed: 2026-01-14
 works-best-when:
   - Applications need composable private and public state in a single contract
   - Developers want privacy without abandoning familiar programming paradigms

@@ -1,7 +1,11 @@
 ---
 title: "Pattern: Open Intent Framework (OIF)"
 status: draft
-maturity: ready
+maturity: pilot
+layer: hybrid
+privacy_goal: No transaction privacy; intents visible to solvers during discovery
+assumptions: Active solver network, cross-chain messaging layer, price oracles
+last_reviewed: 2026-01-14
 rollout-plan: ready to build solvers
 works-best-when:
   - Cross-chain settlement needed

@@ -2,6 +2,10 @@
 title: "Pattern: Permissioned Ledger Interoperability"
 status: draft
 maturity: pilot
+layer: offchain
+privacy_goal: Cross-ledger atomicity with counterparty-only visibility of transaction state
+assumptions: Canton/DAML or similar sync protocol, harmonized governance, selective disclosure for regulators
+last_reviewed: 2026-01-14
 works-best-when:
   - Multiple financial institutions each operate their own permissioned ledger but require atomic cross-ledger settlement
   - Regulatory constraints prevent moving all participants onto a single shared chain

@@ -2,6 +2,10 @@
 title: "Pattern: Pre-trade privacy (Shutter/SUAVE/private RFQ)"
 status: ready
 maturity: pilot
+layer: hybrid
+privacy_goal: Prevent front-running and information leakage via encrypted order submission
+assumptions: Encrypted mempool (Shutter) or private builders (SUAVE), allow-listed counterparties
+last_reviewed: 2026-01-14
 works-best-when:
   - RFQ/secondary trading must not leak intent, size, or price pre-inclusion.
 avoid-when:

@@ -2,6 +2,10 @@
 title: "Pattern: Private L2s"
 status: draft
 maturity: PoC
+layer: L2
+privacy_goal: Execute financial logic with private state enabling confidential value and unlinkable identity
+assumptions: Privacy-native rollup (ZK or FHE), L1 bridge contracts, viewing key infrastructure
+last_reviewed: 2026-01-14
 works-best-when:
   - Strong privacy is required beyond value-hiding: identity unlinkability, programmable access.
   - Institutions want to embed compliance hooks (view keys, audit proofs).
@@ -25,6 +29,16 @@ Use a **privacy-native rollup** (ZK or FHE-based) to execute financial logic wit
   - FHE rollups: Zama/fhEVM, Inco
 - **Off-chain**: Key management, regulator view proofs
 
+## Protocol (concise)
+
+1. Bridge assets from L1 to privacy L2 via deposit contract.
+2. Assets converted to private notes/commitments on the L2.
+3. Execute transactions privately within L2 (amounts, senders, receivers shielded).
+4. Generate ZK proofs (or FHE computations) for state transitions.
+5. Optionally couple with ERC-7573 for atomic DvP/PvP settlement.
+6. Provide viewing keys or disclosure proofs to regulators as needed.
+7. Exit to L1 via withdrawal with proof of valid state.
+
 ## Guarantees
 
 - **Private transactions**: Transaction details (amounts, senders, receivers) are shielded within the L2.

@@ -1,7 +1,11 @@
 ---
 title: "Pattern: Private ISO 20022 Messaging & Settlement"
 status: draft
-maturity: research
+maturity: experimental
+layer: hybrid
+privacy_goal: Private ERC-20 settlements linked to ISO 20022 instructions with regulator-only visibility
+assumptions: ISO 20022 schema, shielded pool or confidential token infrastructure, threshold KMS
+last_reviewed: 2026-01-14
 works-best-when:
   - Institutions already exchange ISO 20022 messages (pacs.008/009/002, camt.\*).
   - On-chain settlement (ERC-20, tokenized deposits) must link to SWIFT/ISO workflows.

@@ -2,6 +2,10 @@
 title: "Pattern: Private Client Authentication for Institutional EOAs"
 status: draft
 maturity: pilot
+layer: hybrid
+privacy_goal: Authenticate client EOAs via Merkle proofs without revealing identity or linking addresses
+assumptions: ZK circuits for Merkle membership, on-chain Merkle root registry, Semaphore or similar
+last_reviewed: 2026-01-14
 works-best-when:
   - Institutions must comply with KYC/AML but want to protect client privacy onchain.
   - Clients need to prove control of EOAs without revealing identity.

@@ -2,6 +2,10 @@
 title: "Pattern: Private PvP (cash↔cash) Settlement via ERC‑7573"
 status: draft
 maturity: PoC
+layer: hybrid
+privacy_goal: Atomic PvP between stablecoins with amount privacy and stakeholder-only visibility
+assumptions: ERC-7573 escrows, FX/price oracles, shielded transfer infrastructure on both legs
+last_reviewed: 2026-01-14
 works-best-when:
   - Two permissioned/regulated stablecoins (same L2 or cross‑L2) must settle **atomically** with **amount privacy**.
   - FX or cross‑issuer settlement requires on‑chain finality sensing and pricing.

@@ -2,6 +2,10 @@
 title: "Pattern: Private Stablecoin Shielded Payments"
 status: ready
 maturity: pilot
+layer: L2
+privacy_goal: Stakeholder-only stablecoin transfers with view-key/proof-based disclosure for regulators
+assumptions: Privacy L2 (Aztec/Zama/Fhenix), wallet/KMS integration, optional L1 anchoring
+last_reviewed: 2026-01-14
 works-best-when:
   - Cash leg must be private (amounts + counterparties) with selective disclosure.
   - You need Ethereum‑native tooling (L2/app‑chain) and interop with PvP or DvP.

@@ -2,6 +2,10 @@
 title: "Pattern: Private Intent-Based Vaults"
 status: draft
 maturity: PoC
+layer: hybrid
+privacy_goal: Hide strategy parameters and order flow while keeping deposited assets auditable
+assumptions: FHE-enabled chain or privacy L2, intent relayers/solvers, compliance oracles
+last_reviewed: 2026-01-14
 works-best-when:
   - Institutions or funds need private strategy execution while assets remain transparently custodied.
   - Strategies are automated or intent-driven and should not leak parameters to competitors.

@@ -2,6 +2,10 @@
 title: "Pattern: Selective disclosure (viewing keys + ZK proofs)"
 status: ready
 maturity: pilot
+layer: hybrid
+privacy_goal: Provide on-demand scoped visibility into confidential trades via threshold keys or ZK proofs
+assumptions: Threshold KMS, EAS for access logging, ZK predicate circuits
+last_reviewed: 2026-01-14
 works-best-when:
   - Regulator needs targeted visibility without blanket transparency.
 avoid-when:

@@ -2,6 +2,10 @@
 title: "Pattern: Shielded ERC-20 Transfers"
 status: draft
 maturity: PoC
+layer: hybrid
+privacy_goal: Confidential ERC-20 transfers hiding balances and metadata with selective disclosure
+assumptions: Shielded pool contracts or privacy L2, wallet support for shielded keys
+last_reviewed: 2026-01-14
 works-best-when:
   - You need confidential transfer amounts/counterparties.
   - Selective disclosure/auditing is required.
@@ -24,6 +28,16 @@ Enable **confidential ERC-20 transfers** by shielding balances and transfer meta
   - **Privacy L2/app-chains** (e.g., Aztec, Zama fhEVM, Fhenix) with native shielding.
 - **Wallet/KMS**: Management of shielded keys and optional viewing keys.
 
+## Protocol (concise)
+
+1. Deposit ERC-20 tokens into shielded pool contract.
+2. Receive private notes/commitments representing the deposit.
+3. Execute shielded transfers by spending notes and creating new ones.
+4. Generate ZK proof for each transfer (balance validity, no double-spend).
+5. Optionally use stealth addresses (ERC-5564) for recipient unlinkability.
+6. Provide viewing keys to auditors for selective disclosure.
+7. Withdraw by proving ownership of notes and burning them.
+
 ## Guarantees
 
 - Hides amounts + counterparties from non-participants.

@@ -2,6 +2,10 @@
 title: "Pattern: Stealth Addresses"
 status: draft
 maturity: PoC
+layer: L1
+privacy_goal: Hide address linkages via one-time destination addresses; amounts remain visible
+assumptions: EIP-5564 support, wallet view/spend key management, optional registry for public view keys
+last_reviewed: 2026-01-14
 works-best-when:
   - Sender and receiver want to hide address linkages on a public chain.
   - Amount privacy is less critical than unlinkability of counterparties.

@@ -2,6 +2,10 @@
 title: "Pattern: TEE key manager"
 status: draft
 maturity: pilot
+layer: offchain
+privacy_goal: Isolate private keys in TEE with policy-bound signing; no on-chain transaction privacy
+assumptions: Attested TEE hardware (SGX/SEV), attestation verification service, KMS for bootstrapping
+last_reviewed: 2026-01-14
 works-best-when:
   - Institutions need hot or warm keys with stronger isolation than software-only wallets.
   - TEE operator and hardware vendor are known and contractually bound.

@@ -2,6 +2,10 @@
 title: "Pattern: Hybrid TEE + ZK Settlement"
 status: draft
 maturity: pilot
+layer: hybrid
+privacy_goal: Private cross-chain settlement in TEEs with ZK proofs attesting correct execution
+assumptions: Attested TEE infrastructure, ZK prover backend, attestation registry
+last_reviewed: 2026-01-14
 works-best-when:
   - Participants accept some trust in TEEs but want zk-based attestations for audit.
   - Privacy requirements exceed what public smart contracts can do alone.

@@ -1,7 +1,11 @@
 ---
 title: "Pattern: Attestation verifiable on-chain"
 status: ready
-maturity: prod
+maturity: production
+layer: hybrid
+privacy_goal: Verify claims about identities/credentials on-chain with minimal data disclosure
+assumptions: Trusted issuers (banks, KYC providers), EAS/ONCHAINID infrastructure, wallet support
+last_reviewed: 2026-01-14
 works-best-when:
   - Some logic has to be embedded onchain and relies on off-chain attested data
   - A user wants to prove a statement about his identity (membership, KYC,...)