diff --git a/CHANGELOG.md b/CHANGELOG.md index f9d0a4d..6cb4374 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,6 +4,7 @@ All notable changes to the EthSystems Map are documented here. ## [Unreleased] +- fix: factual audit of the [Private Bonds](use-cases/private-bonds.md) entry and the cards one hop out. In [Private Bonds](use-cases/private-bonds.md) set Trading as secondary domain, add the FHE PoC and the Atomic DvP Settlement approach, correct the PoC RFQ scope, mark ERC-6123 and ERC-7573 Draft and describe ERC-7573 as oracle-conditional settlement that hides no amounts, replace the unsourced HTLC-replacement forecast with the PoCs' actual DvP scope, and link the DvP, crypto-registry and ICMA BDT patterns, the eWpG jurisdiction and sibling bond use cases; in [Private Bonds](approaches/approach-private-bonds.md) refresh the Railgun figure to the project Dune dashboard (~USD 5.7b, Oct 2026), source the Aztec V5 vulnerability to its 2026-08-07 post, describe the PoC whitelist as its compliance hook, set FHE gas to the PoC measurement (~330K per transfer), scope the PoC disclosure claim to what each PoC exercises, and link eWpG, MiCA, the crypto-registry bridge and ERC-7573; in [Verifiable Attestation](patterns/pattern-verifiable-attestation.md) name the EIP-712 vs EIP-191 signing paths, add EAS (MIT) and ONCHAINID (GPL-3.0) licenses, cite ML-DSA (FIPS 204) and EIP-8051 for PQ migration, and note VC Data Model 2.0 Recommendation status; in [ICMA BDT](patterns/pattern-icma-bdt-data-model.md) scope the taxonomy to term-sheet data (no lifecycle event messages), state the royalty-free licence with ICMA-retained IP and replace the 2023 factsheet with the April 2026 FAQ; in [Crypto-registry bridge](patterns/pattern-crypto-registry-bridge-ewpg-eas.md) describe the eWpG register as a decentralised recording system (§4(11), §16) rather than an off-chain notarial store, scope attestation verification to existence, signer and time, replace dead BaFin links with the statute and the current BaFin licensing page and move EAS docs to docs.attest.org; in [DvP via ERC-7573](patterns/pattern-dvp-erc7573.md) state Draft status and that amounts and parties are observable in calls and events; mark ERC-6123 and ERC-7573 Draft and describe ERC-7573 as oracle-conditional settlement in [Private Corporate Bonds](use-cases/private-corporate-bonds.md); move the EAS docs link to docs.attest.org in [Selective Disclosure](patterns/pattern-regulatory-disclosure-keys-proofs.md); link these cards back to Private Bonds - fix: factual audit of the [Private Treasuries](use-cases/private-treasuries.md) entry and the cards one hop out. Fill the empty context section with sourced cash-pooling, transfer-pricing (OECD Chapter X, BEPS Action 13) and Kinexys/JPMD bullets and scope regulatory capital and liquidity reporting to regulated group entities in [Private Treasuries](use-cases/private-treasuries.md); in [Private Payments](approaches/approach-private-payments.md) add the deposit verification cost, note Aztec Alpha and the July 2026 V5 proving-system disclosure, replace the exit-game description of Stateless Plasma with proof-based exits, mark Plasma user proofs as server-side, note that MPC configurations can hide addresses, correct relay-set floors to the PoC spec and state the Resilient Disbursement Rails PoC scope; add FATF R.16 Travel Rule access, the Swift shared-ledger plan and a Resilient Disbursement Rails link in [Private Payments](use-cases/private-payments.md); state GENIUS Act effective date and ERC-7573 Draft status and oracle dependence, and move the Zama link to zama.org, in [Private Stablecoins](use-cases/private-stablecoins.md); date and source the tokenized Treasury market figure (rwa.xyz, 5 Oct 2026) in [Private Money Market Funds](use-cases/private-money-market-funds.md); replace the unsourced Asia municipal-debt line with Hong Kong digital green bonds and Japan's 2026 Local Finance Act amendment in [Private Government Debt](use-cases/private-government-debt.md) - fix(approach): [Private Money Market Funds](approaches/approach-private-money-market-funds.md): Phase 1 review for the MMF approach cycle. Stable- vs floating-NAV yield, aggregates at the fund's cadence, disclosure-key custody instead of threshold NAV opening, investor-side vs portfolio compliance, maturity corrected to `documented`, three new comparison rows, a conditional recommendation, and new open questions (collateral as a future extension). Links: `private-vaults` removed; `erc3643-rwa` and `private-mtp-auth` added. - fix(use-case): [Private Money Market Funds](use-cases/private-money-market-funds.md): fills Additional Context, scopes Rule 2a-7 to registered funds, updates gates after the 2023 amendments, cross-links open questions to the approach card, and lists it in the [Funds & Assets](domains/funds-assets.md) domain. diff --git a/approaches/approach-private-bonds.md b/approaches/approach-private-bonds.md index dde19c7..44c70ab 100644 --- a/approaches/approach-private-bonds.md +++ b/approaches/approach-private-bonds.md @@ -1,7 +1,7 @@ --- title: "Approach: Private Bond Issuance & Trading" status: ready -last_reviewed: 2026-09-29 +last_reviewed: 2026-10-13 use_case: private-bonds related_use_cases: [private-corporate-bonds, private-government-debt] @@ -54,7 +54,7 @@ open_source_implementations: ### Scenario -A bank issues a EUR 100M corporate bond series with private allocation amounts to 50 institutional investors and operates an active secondary market with RFQ-based price discovery. The bank needs hidden positions and trade sizes, atomic same-chain DvP against EURC, jurisdiction-specific selective disclosure (eWpG for the bond; MiCA for the EURC leg, since bonds that are MiFID II financial instruments fall outside MiCA), and an automated 24/7 market with daily settlement. +A bank issues a EUR 100M corporate bond series with private allocation amounts to 50 institutional investors and operates an active secondary market with RFQ-based price discovery. The bank needs hidden positions and trade sizes, atomic same-chain DvP against EURC, jurisdiction-specific selective disclosure ([eWpG](../jurisdictions/de-eWpG.md) for the bond; [MiCA](../jurisdictions/eu-MiCA.md) for the EURC leg, since bonds that are MiFID II financial instruments fall outside MiCA), and an automated 24/7 market with daily settlement. ### Requirements @@ -68,7 +68,7 @@ A bank issues a EUR 100M corporate bond series with private allocation amounts t - Production timeline of 1-2 years with proven infrastructure - Cross-chain DvP requires trusted relayer or bridge; out of scope for primary path -- Must compose with existing crypto-registries and custodial infrastructure +- Must compose with existing crypto-registries ([Crypto-registry bridge](../patterns/pattern-crypto-registry-bridge-ewpg-eas.md)) and custodial infrastructure - Deployment must satisfy ICMA BDT data-model expectations for bond identifiers ## Approaches @@ -108,7 +108,7 @@ example_vendors: [paladin, railgun] - ZK toolchain is unavailable to the issuer - Coupon logic requires complex computation that does not map cleanly to circuits -**Implementation notes:** PoC implements UTXO with Noir / UltraHonk; multi-token transfers require same-token circuit constraints, so per-pool deployments are the working assumption. Compliance hooks via attestation-gated entry (zero-knowledge proof of KYC Merkle inclusion) and per-note viewing keys. +**Implementation notes:** PoC implements UTXO with Noir / UltraHonk; multi-token transfers require same-token circuit constraints, so per-pool deployments are the working assumption. PoC compliance hooks are an issuer-managed on-chain address whitelist and per-note viewing keys; attestation-gated entry (zero-knowledge proof of KYC Merkle inclusion) is a production alternative to the plaintext whitelist. ### Privacy L2 @@ -128,7 +128,7 @@ example_vendors: [aztec, miden] **Trust assumptions:** - Sequencer set for ordering (Aztec Alpha mainnet uses a staked, decentralized sequencer set; Alpha is early-stage and Aztec advises limiting deposits) - Bridge contract for L1 settlement -- Aztec proving system soundness (a critical soundness vulnerability in the Alpha V5 proving system was disclosed on 2026-07-27) +- Aztec proving system soundness (a critical soundness vulnerability in the Alpha V5 proving system, identified on 2026-07-27 per Aztec's [2026-08-07 post](https://aztec.network/blog/alpha-v5-proving-system-vulnerability), which plans the fix for V6) **Threat model:** - Sequencer outage or censorship; rollup escape paths leak linkage during forced exit @@ -220,7 +220,7 @@ example_vendors: [zama, fhenix] | **CROPS** | CR:hi O:y P:full S:hi | CR:med O:part P:full S:med | CR:med O:part P:part S:med | CR:med O:part P:part S:med | | **Trust model** | Self-custody (L1 + ZK) | Sequencer + bridge | Honest-majority 3-party MPC | t-of-n threshold network | | **Privacy scope** | Amounts + addresses (via gas relayer) | Amounts + addresses (account level) | Amounts only; addresses public | Amounts only; addresses public | -| **Performance** | High gas, chain-dependent throughput | L2-internal fees, unknown TPS | ~0.9M gas per transfer intent plus ~3.8M per 50-tx batch, ~200-300 TPS (vendor) | ~300K gas/tx, 20+ TPS shared, 500-1000 projected (vendor) | +| **Performance** | High gas, chain-dependent throughput | L2-internal fees, unknown TPS | ~0.9M gas per transfer intent plus ~3.8M per 50-tx batch, ~200-300 TPS (vendor) | ~330K gas/transfer (PoC, Sepolia), 20+ TPS shared, 500-1000 projected (vendor) | | **Operator req.** | No (gas relayer optional) | Yes (sequencer) | Yes (MPC committee) | Yes (threshold network) | | **Cost class** | High (L1 verify) | Low (L2-internal) | Low (batched) | Medium | | **Regulatory fit** | Strong (per-note view keys) | Strong (IVKs, app-siloed nullifiers) | Strong for known counterparty | Strong (per-balance ACL) | @@ -230,11 +230,11 @@ example_vendors: [zama, fhenix] ### Business perspective -For institutional bond issuance and trading at scale, UTXO Shielded Notes is the default: production maturity (Railgun ~USD 5b lifetime shielded volume as of 2026), white-label vendor coverage (Paladin), privacy over amounts, counterparties, and addresses (addresses via gas relayer), and a disclosure story built on per-note viewing keys that can be assessed against eWpG (and MiCA for the EURC leg). Privacy L2 fits where bond logic is complex (coupons, structured lifecycle) because it removes circuit-engineering work, but the issuer must accept the rollup's decentralization timeline. co-SNARKs and FHE fit specific institutional contexts: bilateral or club-mode markets where address visibility is acceptable, or coupon-heavy products where homomorphic arithmetic is the natural model. +For institutional bond issuance and trading at scale, UTXO Shielded Notes is the default: production maturity (Railgun ~USD 5.7b cumulative shielded volume as of October 2026 on its project-maintained [Dune dashboard](https://dune.com/railgun_project/railgun)), white-label vendor coverage (Paladin), privacy over amounts, counterparties, and addresses (addresses via gas relayer), and a disclosure story built on per-note viewing keys that can be assessed against eWpG (and MiCA for the EURC leg). Privacy L2 fits where bond logic is complex (coupons, structured lifecycle) because it removes circuit-engineering work, but the issuer must accept the rollup's decentralization timeline. co-SNARKs and FHE fit specific institutional contexts: bilateral or club-mode markets where address visibility is acceptable, or coupon-heavy products where homomorphic arithmetic is the natural model. ### Technical perspective -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. +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. The three EthSystems PoCs differ in how far disclosure is exercised: the FHE PoC tests regulator ACL grants, the Privacy L2 PoC documents regulator viewing-key sharing without testing it, and the UTXO PoC sends transaction details to the issuer-relayer over a private channel. None implements the stablecoin leg of DvP. The architectural choice is driven by trust topology and bond-logic complexity. ### Legal & risk perspective @@ -260,10 +260,10 @@ Issuance can run through UTXO with a vendor-provided shielded pool; secondary tr 1. **Multi-Asset Bond Support.** Tranches, multiple currencies, or collateral types within shielded note systems require either per-tranche pools or extended circuit constraints; unresolved. 2. **Coupon Payment Mechanisms.** Patterns for automated, privacy-preserving coupon distribution to shielded bondholders are emergent; no canonical solution. -3. **Cross-Chain Settlement.** Beyond same-chain atomic DvP, acceptable trust models for cross-chain bond settlement (relayers, bridges, messaging) are unsettled. +3. **Cross-Chain Settlement.** Beyond same-chain atomic DvP, acceptable trust models for cross-chain bond settlement (relayers, bridges, messaging, or the oracle-released key of [ERC-7573](../patterns/pattern-dvp-erc7573.md)) are unsettled. 4. **Secondary Market Structure.** Private RFQ systems with sufficient price discovery; unresolved at the standard level. 5. **Pre-Trade Privacy.** The boundary between order-flow privacy and post-trade confidentiality differs by market; no standard answer. 6. **Market Data & Analytics.** Bond pricing, yield curves, and analytics under transaction privacy require either trusted publishers or zk-statistics; unresolved. 7. **Regulatory Standards.** Standardization of selective-disclosure formats for eWpG / MiCA across jurisdictions is incomplete. -8. **Legacy Integration.** Bridges between on-chain privacy and traditional bond settlement (Euroclear, Clearstream, MarketAxess) are absent. +8. **Legacy Integration.** Bridges between on-chain privacy and traditional bond settlement (Euroclear, Clearstream) and trading venues (MarketAxess) are absent. diff --git a/patterns/pattern-crypto-registry-bridge-ewpg-eas.md b/patterns/pattern-crypto-registry-bridge-ewpg-eas.md index 93a4cf5..3bac353 100644 --- a/patterns/pattern-crypto-registry-bridge-ewpg-eas.md +++ b/patterns/pattern-crypto-registry-bridge-ewpg-eas.md @@ -4,7 +4,7 @@ status: ready maturity: concept type: standard layer: hybrid -last_reviewed: 2026-04-22 +last_reviewed: 2026-10-13 works-best-when: - Germany or eWpG applies and a licensed crypto-register is required. @@ -45,7 +45,7 @@ Operate with a licensed crypto-register today while mirroring key legal facts (i ## Components -- Licensed crypto-register under eWpG holds the legal records, PII, and signed notarial documents off-chain. It is the sole source of legal truth. +- Licensed crypto-securities registrar under eWpG keeps the register on a decentralised, tamper-protected recording system (eWpG §4(11), §16) and holds holder PII, the deposited issuance terms (§5), and signed records off-chain. The register is the sole source of legal truth. - Registrar API integration layer exposes signed records for each legal event (issuance, transfer, lien) to downstream systems. - On-chain attestation schema defines the structure of mirrored facts: event type, record hash, registrar identifier, timestamp. PII never appears on-chain. - Middleware attester reads the registrar's signed records, computes the hash, and posts an attestation on-chain under the schema. @@ -65,7 +65,7 @@ Guarantees: - Legal compliance with eWpG is preserved; the licensed registrar remains the authoritative record keeper. - On-chain anchor provides tamper-evident linkage between the registrar's private ledger and a public timestamp. -- Mirrored facts are cryptographically verifiable without requiring regulator access to the plaintext. +- Anyone can verify that an attestation exists, who signed it, and when, without the plaintext; matching it to a record needs the plaintext. Threat model: @@ -79,7 +79,7 @@ Threat model: - Two sources of truth require ongoing reconciliation. Drift between the registrar and the on-chain anchor must be detected and resolved operationally. - Strong incident and runbook discipline is required. A mismatch is not self-resolving; it triggers a manual investigation. - Registrar dependency limits availability. Downtime at the registrar halts new anchors even if the on-chain side is healthy. -- The pattern is explicitly transitional: it assumes a future regulatory regime where the register itself can move on-chain and automation can replace the middleware. +- The pattern is explicitly transitional. eWpG already requires the crypto-securities register to run on a decentralised recording system, but under a licensed registrar; the pattern assumes a later setup where register entries live directly on the public chain and automation can replace the middleware. ## Example @@ -90,6 +90,7 @@ Threat model: ## See also -- [BaFin on eWpG](https://www.bafin.de/EN/PublikationenDaten/Fachartikel/2021/fa_bj_2107_eWpG_en_en.html) -- [BaFin crypto-securities register](https://www.bafin.de/EN/Aufsicht/FinTech/Geschaeftsmodelle/DLT_Blockchain_Krypto/Kryptowertpapierregisterfuehrung/Wertapierregister_node_en.html) -- [EAS documentation](https://easscan.org/docs) +- [eWpG statute text (German)](https://www.gesetze-im-internet.de/ewpg/) +- [BaFin crypto-securities registration](https://www.bafin.de/EN/unternehmen-maerkte/erlaubnis-registrierung/geschaefte-krypto/kryptowertpapierregisterfuehrung/kryptowertpapierregisterfuehrung_node_en.html) +- [EAS documentation](https://docs.attest.org/) +- [Use case: Private Bonds](../use-cases/private-bonds.md) · [Approach: Private Bonds](../approaches/approach-private-bonds.md) · [Jurisdiction: DE eWpG](../jurisdictions/de-eWpG.md) diff --git a/patterns/pattern-dvp-erc7573.md b/patterns/pattern-dvp-erc7573.md index fc104ca..1c245c2 100644 --- a/patterns/pattern-dvp-erc7573.md +++ b/patterns/pattern-dvp-erc7573.md @@ -4,13 +4,13 @@ status: ready maturity: concept type: standard layer: hybrid -last_reviewed: 2026-09-18 +last_reviewed: 2026-10-13 works-best-when: - Asset and cash legs live on different networks (L1 or L2). avoid-when: - Both legs already settle on the same network with simple on-chain transfers. - - You're searching for a production-ready solution (EIP not yet recommended). + - You're searching for a production-ready solution (ERC-7573 is in Draft status). - You're searching for a fully trustless solution. context: i2i @@ -24,7 +24,7 @@ crops_profile: crops_context: cr: "Oracle governance is typically codified in bilateral or consortium agreements, so the practical censorship risk sits below the protocol-level score. Reaches `high` if threshold decryption oracles with k-of-n quorum replace single-operator oracles, removing any single exclusion point." o: "Oracle and contract implementations vary by deployment. Improves to `yes` by releasing oracle implementations and outcome key services under a copyleft license." - p: "Standard ERC-7573 provides atomic settlement but no privacy: trade identifier, amounts, and counterparties may be observable on-chain. Reaches `partial` or `full` by layering threshold-encrypted mempools, minimal on-chain trade data, and private or proof-based payment layers." + p: "Standard ERC-7573 provides atomic settlement but no privacy: trade identifier, amounts, and counterparties are observable in calls and events. Reaches `partial` or `full` by layering threshold-encrypted mempools, minimal on-chain trade data, and private or proof-based payment layers." s: "Rides on the decryption oracle operator's honesty for liveness. Improves to `high` by replacing operational trust with verifiable proofs of outcome key validity and threshold quorum." post_quantum: @@ -117,3 +117,4 @@ These extensions do not change how the contracts decide outcomes: the asset cont - [ERC-7573 specification](https://ercs.ethereum.org/ERCS/erc-7573) - [Private Trade Settlement approach](../approaches/approach-private-trade-settlement.md) +- [Private Bonds approach](../approaches/approach-private-bonds.md) (cross-chain settlement open question) diff --git a/patterns/pattern-icma-bdt-data-model.md b/patterns/pattern-icma-bdt-data-model.md index 3d55fac..76ed52f 100644 --- a/patterns/pattern-icma-bdt-data-model.md +++ b/patterns/pattern-icma-bdt-data-model.md @@ -1,13 +1,13 @@ --- -title: "Pattern: ICMA Bond Data Taxonomy (canonical terms/events)" +title: "Pattern: ICMA Bond Data Taxonomy (canonical bond terms)" status: ready maturity: production type: standard layer: offchain -last_reviewed: 2026-06-18 +last_reviewed: 2026-10-13 works-best-when: - - You want machine-readable bond terms and lifecycle events across tools. + - You want machine-readable bond terms across tools. - Multiple issuance platforms need to interoperate without bespoke mappings. avoid-when: - A jurisdiction or domain mandates a different canonical schema. @@ -22,7 +22,7 @@ crops_profile: crops_context: cr: "Schema governance sits with a single standards body (ICMA). Could reach `medium` if the schema is published as a permissionless open registry with attestation-anchored contributions and no approval gate." - o: "Open specification, publicly documented. Implementations can reuse the schema without licensing barriers, though schema evolution is gated by the standards body." + o: "Open specification, publicly documented. Implementations can reuse the schema under ICMA's royalty-free license, though ICMA retains the IP and schema evolution is gated by the standards body." p: "Schema itself contains no participant data; only field definitions. Raw bond data stays off-chain, with only hashes anchored on-chain, so the pattern does not expose confidential details." s: "Rides on the correctness of off-chain validators and the integrity of hash anchoring. Well-defined schemas reduce integration errors and make regulator reconciliation straightforward." @@ -40,11 +40,11 @@ related_patterns: ## Intent -Use the ICMA Bond Data Taxonomy as the canonical schema for bond terms and lifecycle events. A shared data model avoids fragmentation across issuance platforms, registrars, and regulators, and provides a stable foundation for attestations and zero-knowledge proofs over bond data. +Use the ICMA Bond Data Taxonomy as the canonical schema for bond terms. A shared data model avoids fragmentation across issuance platforms, registrars, and regulators, and provides a stable foundation for attestations and zero-knowledge proofs over bond data. ## Components -- Canonical schema defines bond terms (identifiers, parties, cash flows, covenants) and lifecycle events (issuance, coupons, redemption, restructuring). +- Canonical schema (XML Schema, with a JSON format also available) defines the key terms of a bond term sheet: amounts, currency, dates, interest terms, parties, governing law, selling restrictions, and DLT platform fields. It does not define lifecycle event messages (coupon payments, redemptions); event records can reference BDT fields but need a separate schema. - Schema validator checks that bond records conform to the canonical definitions before they are signed, hashed, or anchored. - Compression layer converts verbose representations (for example XML) into binary or compact serialization for efficient on-chain anchoring. - Registrar integration maps internal registrar records to the canonical schema so existing systems can emit conformant data without rewriting their back office. @@ -52,7 +52,7 @@ Use the ICMA Bond Data Taxonomy as the canonical schema for bond terms and lifec ## Protocol -1. [operator] Author bond terms and lifecycle events in the canonical schema. +1. [operator] Author bond terms in the canonical schema. 2. [operator] Validate the record against the schema and compress for storage. 3. [operator] Store the record (on-chain hash anchor, off-chain canonical payload). 4. [auditor] Use the same schema when preparing selective-disclosure proofs or attestations. @@ -85,4 +85,5 @@ An issuance platform publishes bond terms in the canonical schema. The registrar ## See also - [ICMA Bond Data Taxonomy overview](https://www.icmagroup.org/fintech-and-digitalisation/fintech-advisory-committee-and-related-groups/bond-data-taxonomy/) -- [ICMA BDT Factsheet (PDF)](https://www.icmagroup.org/assets/documents/Regulatory/FinTech/Bond-data-taxonomy/ICMA-Bond-Data-Taxonomy-BDT-Factsheet-March-2023-140323.pdf) +- [ICMA BDT FAQs, April 2026 (PDF)](https://www.icmagroup.org/assets/documents/Regulatory/FinTech/Bond-data-taxonomy/ICMA-Bond-Data-Taxonomy-FAQs-April-2026-280426.pdf) +- [Use case: Private Bonds](../use-cases/private-bonds.md) · [Approach: Private Bonds](../approaches/approach-private-bonds.md) diff --git a/patterns/pattern-regulatory-disclosure-keys-proofs.md b/patterns/pattern-regulatory-disclosure-keys-proofs.md index 370c48b..fbe2afd 100644 --- a/patterns/pattern-regulatory-disclosure-keys-proofs.md +++ b/patterns/pattern-regulatory-disclosure-keys-proofs.md @@ -120,5 +120,5 @@ The transfer agent of a tokenized security holds the register key. Each issuance ## See also -- [EAS documentation](https://easscan.org/docs) +- [EAS documentation](https://docs.attest.org/) - [Aztec](../vendors/aztec.md) diff --git a/patterns/pattern-verifiable-attestation.md b/patterns/pattern-verifiable-attestation.md index 28e5532..2cf3b9b 100644 --- a/patterns/pattern-verifiable-attestation.md +++ b/patterns/pattern-verifiable-attestation.md @@ -4,7 +4,7 @@ status: ready maturity: production type: standard layer: hybrid -last_reviewed: 2026-09-29 +last_reviewed: 2026-10-13 works-best-when: - Smart-contract logic must gate on off-chain attested facts (KYC status, accreditation, membership). @@ -27,14 +27,14 @@ crops_profile: crops_context: cr: "The user depends on the issuer to produce or refresh attestations. CR lifts to `medium` when credentials are portable across competing issuers under a shared schema." - o: "EAS and W3C Verifiable Credentials are open standards with multiple implementations; ONCHAINID implements ERC-734/735, which remain unmerged draft proposals. Users can run their own verifier and swap issuers." + o: "EAS and W3C Verifiable Credentials are open standards with multiple implementations; ONCHAINID implements ERC-734/735, which remain unmerged draft proposals. EAS contracts are MIT-licensed; ONCHAINID contracts are GPL-3.0. Users can run their own verifier and swap issuers." p: "On-chain verification reveals that the user holds an attestation of a given type at a given time. Wrapping the attestation in a zero-knowledge proof lets the user disclose only the predicate (over 18, accredited) without revealing the raw claim." - s: "Rides on issuer key custody, a sound signature scheme (ECDSA, typically over an EIP-712 typed-data digest), and the revocation registry being queryable on-chain." + s: "Rides on issuer key custody, a sound signature scheme (ECDSA over an EIP-712 typed-data digest for EAS delegated and off-chain attestations, or over an EIP-191 prefixed hash for ONCHAINID claims; direct EAS on-chain attestations rely on the attester's transaction signature), and the revocation registry being queryable on-chain." post_quantum: risk: high vector: "ECDSA signatures on attestations are broken by a CRQC. An attacker could forge attestations once issuer public keys are exposed. HNDL does not apply to signatures themselves, but long-lived attestations exposed on-chain may need re-issuance before a CRQC arrives." - mitigation: "Migrate issuer signing to a post-quantum scheme once standardized, for example ML-DSA. Rotate issuer keys on a defined schedule. See [Post-Quantum Threats](../domains/post-quantum.md)." + mitigation: "Migrate issuer signing to a post-quantum signature scheme such as ML-DSA (FIPS 204); on-chain verification needs a verifier contract or a precompile such as [EIP-8051](https://eips.ethereum.org/EIPS/eip-8051) (Draft). Rotate issuer keys on a defined schedule. See [Post-Quantum Threats](../domains/post-quantum.md)." standards: [EAS, ERC-734, ERC-735, EIP-712, W3C-VC] @@ -44,10 +44,10 @@ related_patterns: open_source_implementations: - url: https://github.com/ethereum-attestation-service/eas-contracts - description: "Ethereum Attestation Service contracts (production)" + description: "Ethereum Attestation Service contracts (production, MIT)" language: "Solidity" - url: https://github.com/onchain-id/solidity - description: "ONCHAINID reference implementation of ERC-734/735 (production)" + description: "ONCHAINID implementation of ERC-734/735 (production, GPL-3.0)" language: "Solidity" --- @@ -87,7 +87,7 @@ Threat model: - Issuer honesty and key custody. A compromised issuer key can produce forged attestations until the key is revoked. - Availability of the revocation registry at verification time. A stale read defeats revocation. -- Signature-scheme soundness. ECDSA, whether over a raw hash or an EIP-712 typed-data digest, is classically secure and PQ-vulnerable. +- Signature-scheme soundness. ECDSA, whether over an EIP-191 prefixed hash or an EIP-712 typed-data digest, is classically secure and PQ-vulnerable. - On-chain visibility of the verification event reveals which contract the user interacted with and when. Network-layer privacy and zero-knowledge wrappers are out of scope for this pattern. ## Trade-offs @@ -104,10 +104,10 @@ A buyer on a tokenized bond platform holds an accredited-investor attestation is ## See also - [EAS (Ethereum Attestation Service)](https://attest.org/) -- [W3C Verifiable Credentials Data Model 2.0](https://www.w3.org/TR/vc-data-model-2.0/) +- [W3C Verifiable Credentials Data Model 2.0](https://www.w3.org/TR/vc-data-model-2.0/) (W3C Recommendation, 15 May 2025) - [ERC-734 (draft, unmerged)](https://github.com/ethereum/EIPs/issues/734) - [ERC-735 (draft, unmerged)](https://github.com/ethereum/EIPs/issues/735) -- [ONCHAINID reference implementation of ERC-734/735](https://github.com/onchain-id/solidity) +- [ONCHAINID implementation of ERC-734/735](https://github.com/onchain-id/solidity) - [EIP-712](https://eips.ethereum.org/EIPS/eip-712) - [Approach: Private Bonds](../approaches/approach-private-bonds.md) - [Domain: Identity and Compliance](../domains/identity-compliance.md) diff --git a/use-cases/private-bonds.md b/use-cases/private-bonds.md index 783c950..b4eb874 100644 --- a/use-cases/private-bonds.md +++ b/use-cases/private-bonds.md @@ -2,7 +2,7 @@ title: Private Bonds status: ready primary_domain: Funds & Assets -secondary_domain: +secondary_domain: Trading --- ## 1) Use Case @@ -40,14 +40,16 @@ 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/ethsystems/pocs/tree/master/pocs/private-bond); two approaches: Custom UTXO (EVM) and Privacy L2 (Aztec). +See [Approach: Atomic DvP Settlement](../approaches/approach-dvp-atomic-settlement.md) for the settlement leg, including cross-network DvP via ERC-7573. + +**PoC Implementation:** [Private Bond PoC](https://github.com/ethsystems/pocs/tree/master/pocs/private-bond); three approaches: Custom UTXO (EVM), Privacy L2 (Aztec), and FHE (Zama fhEVM). ## 6) Open Questions _Notes below reference the PoC implementation._ - Secondary market: RFQ model + pre-trade privacy requirements (what must be hidden?) - - _PoC approach:_ Issuer acts as relayer and can serve as market matcher; peer-to-peer RFQ not in scope + - _PoC approach:_ Negotiation and RFQ run off-chain with on-chain settlement; in Custom UTXO the issuer relays and can act as matcher, in Privacy L2 either party or a relayer submits the swap - Minimum viable privacy: amounts/positions only vs parts of the term sheet? - _PoC approach:_ Amounts and positions hidden; legal entity identities can remain public (dual identity model) - ISO 20022 relevance for bond workflows vs ICMA BDT usage @@ -55,5 +57,10 @@ _Notes below reference the PoC implementation._ ## 7) Notes And Links - **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) +- **Standards:** [ERC-6123](https://ercs.ethereum.org/ERCS/erc-6123) (Draft; derivative/bond lifecycle), [ERC-7573](https://ercs.ethereum.org/ERCS/erc-7573) (Draft; conditional cross-chain DvP, atomicity rests on the decryption oracle, hides no amounts or counterparties), [ICMA Bond Data Taxonomy (BDT)](../patterns/pattern-icma-bdt-data-model.md) +- **Current standards:** ERC-20 tokens; HTLC sequences for cross-chain DvP (ERC-7573 is a proposed alternative); the approach targets same-chain atomic DvP, but no PoC implements the stablecoin leg: the Custom UTXO PoC's issuer-submitted `atomicSwap` is single-asset and the Privacy L2 PoC settles payment off-chain +- **Patterns:** [Atomic DvP via ERC-7573](../patterns/pattern-dvp-erc7573.md) · [Crypto-registry bridge (eWpG) with EAS mirroring](../patterns/pattern-crypto-registry-bridge-ewpg-eas.md) +- **Jurisdiction:** [DE / eWpG](../jurisdictions/de-eWpG.md) (crypto-securities register) +- **Domains:** [Funds & Assets](../domains/funds-assets.md) · [Trading](../domains/trading.md) +- Related: [private-corporate-bonds.md](private-corporate-bonds.md) (hiding funding signals from competitors) +- Related: [private-government-debt.md](private-government-debt.md) (auction integrity and holder privacy) diff --git a/use-cases/private-corporate-bonds.md b/use-cases/private-corporate-bonds.md index 9c14d29..4dfd5ba 100644 --- a/use-cases/private-corporate-bonds.md +++ b/use-cases/private-corporate-bonds.md @@ -68,4 +68,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-government-debt.md](private-government-debt.md) (different privacy model - less critical) -- Standards: ERC-6123 (bond lifecycle), ERC-7573 (atomic DvP) +- Standards: [ERC-6123](https://ercs.ethereum.org/ERCS/erc-6123) (Draft; derivative/bond lifecycle), [ERC-7573](https://ercs.ethereum.org/ERCS/erc-7573) (Draft; conditional cross-chain DvP, atomicity rests on the decryption oracle, hides no amounts or counterparties; see [pattern](../patterns/pattern-dvp-erc7573.md))