From 862af117cfec8f3c371d8a48320a2a6f5839957f Mon Sep 17 00:00:00 2001 From: rymnc <43716372+rymnc@users.noreply.github.com> Date: Fri, 18 Sep 2026 19:59:54 +0530 Subject: [PATCH 1/2] chore(use-cases): private stablecoins --- CHANGELOG.md | 1 + jurisdictions/cn-crypto-ban.md | 6 +++--- jurisdictions/hk-crypto-licensing.md | 18 +++++++++++------- jurisdictions/sg-MAS.md | 7 ++++--- patterns/pattern-dvp-erc7573.md | 4 ++-- patterns/pattern-plasma-stateless-privacy.md | 8 ++++---- ...ern-private-stablecoin-shielded-payments.md | 3 +-- patterns/pattern-verifiable-attestation.md | 17 +++++++++-------- use-cases/private-stablecoins.md | 4 ++-- 9 files changed, 37 insertions(+), 31 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 977d7eb..8a5cdc5 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-stablecoins entry and the cards one hop out - fix(pattern): clarify [ERC-3643 Tokenized RWAs](patterns/pattern-erc3643-rwa.md) transfer-path semantics; distinguish investor-initiated transfer checks from mint and forced-transfer paths, and separate owner and agent controls. - fix(pattern): correct cross-chain atomicity claims. [Private PvP via ERC-7573](patterns/pattern-private-pvp-stablecoins-erc7573.md) now follows the ERC-7573 shape (one leg locked, the other paid through the decryption contract, an oracle-released key that releases or returns the locked leg) and states conditional settlement instead of "both legs settle or both revert"; the old recipe finalised one leg and then claimed both escrows revert. [Atomic DvP via ERC-7573](patterns/pattern-dvp-erc7573.md) drops the timeout reclaim that ERC-7573 does not define and names the oracle condition. [Permissioned Ledger Interoperability](patterns/pattern-permissioned-ledger-interoperability.md) states the coordinator trust assumption of two-phase commit ([#198](https://github.com/ethsystems/map/pull/198)) - fix(ci): repair the Vale prose gate. Scope [EthSystems.Marketing](.vale/styles/EthSystems/Marketing.yml) to promotional claims instead of the bare words "only", "first" and "unique"; drop the [EthSystems.Terminology](.vale/styles/EthSystems/Terminology.yml) swap that forced "Multi-Party Computation" to lower case against GLOSSARY.md; ignore file names used as link text; pass `files` to `vale-action` as a JSON array, the one form the action parses, so the job lints the six content directories instead of the whole repository; and drop the `continue-on-error` added in [#196](https://github.com/ethsystems/map/pull/196), which kept the job green while Vale still exited 1 on 207 findings. Also clears the five real marketing terms and the remaining ERC-7573 and DA Layer terminology drift in the prose. Vale findings in the linted scope: 187 to 0 ([#197](https://github.com/ethsystems/map/pull/197)) diff --git a/jurisdictions/cn-crypto-ban.md b/jurisdictions/cn-crypto-ban.md index 493d057..5320a53 100644 --- a/jurisdictions/cn-crypto-ban.md +++ b/jurisdictions/cn-crypto-ban.md @@ -9,14 +9,14 @@ key-regulations: - 2021 Notice on Further Preventing and Dealing with Crypto Trading Risks - Anti-Money Laundering Law - Data Security Law / PIPL -last_reviewed: 2026-06-19 +last_reviewed: 2026-09-18 --- > Developer orientation. Not legal advice. ## At a Glance -China holds one of the world's strictest stances: cryptocurrency trading, mining, and payment services have been banned since 2021, and related business activity is treated as illegal. In parallel the state promotes permissioned enterprise blockchain (the Blockchain Service Network, BSN) and its CBDC, the e-CNY, under full data localisation and state oversight, so privacy features that limit government visibility are not viable. China is prohibitive toward public crypto and directive about permissioned and CBDC use. +China holds one of the world's strictest stances: cryptocurrency trading, mining, and payment services have been banned since 2021, and related business activity is treated as illegal. In parallel the state promotes permissioned enterprise blockchain (the Blockchain-based Service Network, BSN) and, as a separate programme, its CBDC, the e-CNY, both under full data localisation and state oversight, so privacy features that limit government visibility are not viable. China is prohibitive toward public crypto and directive about permissioned and CBDC use. ## What to Watch @@ -27,4 +27,4 @@ China holds one of the world's strictest stances: cryptocurrency trading, mining ## See also - [Jurisdiction: Hong Kong SAR (HK)](hk-crypto-licensing.md) -- [Blockchain Service Network (BSN)](https://bsnbase.io/) +- [Blockchain-based Service Network (BSN)](https://en.wikipedia.org/wiki/Blockchain-based_Service_Network) (the official `bsnbase.io` site is not reachable from outside mainland China) diff --git a/jurisdictions/hk-crypto-licensing.md b/jurisdictions/hk-crypto-licensing.md index c82d1b6..8292494 100644 --- a/jurisdictions/hk-crypto-licensing.md +++ b/jurisdictions/hk-crypto-licensing.md @@ -3,28 +3,32 @@ title: "Jurisdiction: Hong Kong SAR (HK)" status: ready region: APAC scope: - entities: [licensed exchanges, custodians, fund managers, trading platforms] - activities: [trading, custody, fund management, token distribution] + entities: [licensed exchanges, custodians, fund managers, trading platforms, stablecoin issuers] + activities: [trading, custody, fund management, token distribution, stablecoin issuance] key-regulations: - - SFC VASP licensing regime - - AMLO (Anti-Money Laundering Ordinance) + - SFC VASP/VATP licensing regime + - Stablecoins Ordinance (Cap. 656), HKMA-administered + - AMLO (Anti-Money Laundering and Counter-Terrorist Financing Ordinance) - Securities and Futures Ordinance -last_reviewed: 2026-06-19 +last_reviewed: 2026-09-18 --- > Developer orientation. Not legal advice. ## At a Glance -Under "One Country, Two Systems," Hong Kong runs a separate, progressive regime, distinct from the mainland ban. Since 2023 it has offered a licensing path (the SFC's VASP regime) covering exchanges, custody, and professional asset management, positioning itself as an APAC institutional crypto hub. It is permissive but licensed: retail access is limited to SFC-approved tokens, with broader scope for professional investors. +Under "One Country, Two Systems," Hong Kong runs a separate, progressive regime, distinct from the mainland ban. Since 2023 it has offered a licensing path (the SFC's VASP regime, operated through virtual asset trading platform licences) covering exchanges, custody, and professional asset management, positioning itself as an APAC institutional crypto hub. It is permissive but licensed: retail access is limited to SFC-approved tokens, with broader scope for professional investors. Stablecoins belong to a different regulator: the Stablecoins Ordinance (Cap. 656) commenced on 1 August 2025 and makes issuing a fiat-referenced stablecoin a licensed activity supervised by the HKMA. The HKMA granted the first two issuer licences on 10 April 2026, from 36 applications received by the 30 September 2025 deadline. ## What to Watch -- Pending stablecoin issuer framework. +- How quickly the HKMA widens the licensed-issuer set beyond the first two, and whether licensed HKD-referenced stablecoins reach the market as signalled for H2 2026. - Token classification (security vs commodity) guidance still evolving. - Capital-flow boundaries between Hong Kong and mainland China. ## See also - [Jurisdiction: China (CN)](cn-crypto-ban.md) +- [Regulatory Regime for Stablecoin Issuers (HKMA)](https://www.hkma.gov.hk/eng/key-functions/international-financial-centre/stablecoin-issuers/) +- [Register of Licensed Stablecoin Issuers (HKMA)](https://www.hkma.gov.hk/eng/regulatory-resources/registers/register-of-licensed-stablecoin-issuers/) +- [Virtual asset trading platform operators (SFC)](https://www.sfc.hk/en/Rules-and-standards/Virtual-assets/Virtual-asset-trading-platforms-operators) - [AMLO Guidance (HKMA)](https://www.hkma.gov.hk/eng/key-functions/banking/anti-money-laundering-and-counter-financing-of-terrorism/ordinances-statutory-guidelines/) diff --git a/jurisdictions/sg-MAS.md b/jurisdictions/sg-MAS.md index 0ef02f8..054c910 100644 --- a/jurisdictions/sg-MAS.md +++ b/jurisdictions/sg-MAS.md @@ -9,18 +9,18 @@ key-regulations: - Payment Services Act 2019 - Financial Services and Markets Act 2022 (DTSP regime) - MAS Single-Currency Stablecoin framework (2023) -last_reviewed: 2026-08-02 +last_reviewed: 2026-09-18 --- > Developer orientation. Not legal advice. ## At a Glance -Singapore is permissive toward digital asset activity and heavily licensed in how it permits it. Digital payment token services fall under the Payment Services Act 2019, and since 30 June 2025 a separate Digital Token Service Provider regime under the Financial Services and Markets Act 2022 has captured Singapore-incorporated firms serving customers wholly outside Singapore. That regime commenced without a transition window, and MAS indicated it would rarely license firms whose substantive activity sits entirely abroad, because it cannot supervise them. The stablecoin position is easy to overstate: MAS finalised the policy features of its single-currency stablecoin framework in August 2023, covering tokens pegged to the Singapore dollar or a G10 currency, but the implementing legislation has not yet been introduced in Parliament, so the "MAS-regulated stablecoin" label has no statutory basis yet. Tokenisation pilots run in parallel, including tokenised MAS bills settled in wholesale central bank digital currency. +Singapore is permissive toward digital asset activity and heavily licensed in how it permits it. Digital payment token services fall under the Payment Services Act 2019, and since 30 June 2025 a separate Digital Token Service Provider regime under the Financial Services and Markets Act 2022 has captured Singapore-incorporated firms serving customers wholly outside Singapore. That regime commenced without a transition window, and MAS indicated it would rarely license firms whose substantive activity sits entirely abroad, because it cannot supervise them. The stablecoin position is easy to overstate: MAS finalised the policy features of its single-currency stablecoin framework in August 2023, covering tokens pegged to the Singapore dollar or a G10 currency, but the implementing legislation has not yet been passed, so the "MAS-regulated stablecoin" label has no statutory basis yet. MAS opened the consultation on the implementing amendments to the Payment Services Act 2019 on 1 September 2026, closing 16 October 2026, with subsidiary legislation to be consulted on separately; a bill has still to reach Parliament. Tokenisation pilots run in parallel, including tokenised MAS bills settled in wholesale central bank digital currency. ## What to Watch -- The stablecoin bill and an expected public consultation, which determine when the single-currency framework acquires legal force. +- The outcome of the 1 September 2026 consultation and the bill that follows it, which determine when the single-currency framework acquires legal force. - Treatment of tokens that fall outside the single-currency scope, including foreign-issued and multi-currency stablecoins, which stay under the general digital payment token rules. - Travel rule application to transfers involving unhosted wallets. - Whether wholesale central bank digital currency settlement pilots produce durable market infrastructure. @@ -28,5 +28,6 @@ Singapore is permissive toward digital asset activity and heavily licensed in ho ## See also - [Monetary Authority of Singapore](https://www.mas.gov.sg/) +- [MAS consultation on legislative amendments to implement the stablecoin framework (Sep 2026)](https://www.mas.gov.sg/news/media-releases/2026/mas-consults-on-legislative-amendments-to-implement-stablecoin-regulatory-framework) - [Jurisdiction: Indonesia / OJK (Digital Financial Assets)](./id-OJK.md) - [Jurisdiction: Hong Kong SAR (HK)](./hk-crypto-licensing.md) diff --git a/patterns/pattern-dvp-erc7573.md b/patterns/pattern-dvp-erc7573.md index 561b4fa..fc104ca 100644 --- a/patterns/pattern-dvp-erc7573.md +++ b/patterns/pattern-dvp-erc7573.md @@ -4,7 +4,7 @@ status: ready maturity: concept type: standard layer: hybrid -last_reviewed: 2026-09-11 +last_reviewed: 2026-09-18 works-best-when: - Asset and cash legs live on different networks (L1 or L2). @@ -30,7 +30,7 @@ crops_context: post_quantum: risk: medium vector: "Oracle decryption relies on standard public-key encryption; outcome key commitments inherit hash assumptions. Payment-network signatures carry host-chain PQ exposure." - mitigation: "Migrate decryption to PQ-safe KEM schemes (Kyber, ML-KEM) as ERC-7573 extensions mature. See [Post-Quantum Threats](../domains/post-quantum.md)." + mitigation: "Migrate decryption to a PQ-safe KEM, ML-KEM (FIPS 203), as ERC-7573 extensions mature. See [Post-Quantum Threats](../domains/post-quantum.md)." standards: [ERC-7573, ERC-20] diff --git a/patterns/pattern-plasma-stateless-privacy.md b/patterns/pattern-plasma-stateless-privacy.md index e5a320f..2d52efe 100644 --- a/patterns/pattern-plasma-stateless-privacy.md +++ b/patterns/pattern-plasma-stateless-privacy.md @@ -4,7 +4,7 @@ status: ready maturity: testnet type: standard layer: L2 -last_reviewed: 2026-06-18 +last_reviewed: 2026-09-18 works-best-when: - High transaction volume with privacy requirements. @@ -86,7 +86,7 @@ Guarantees: - Transaction amounts, sender, and receiver are hidden from chain observers; only commitments and per-block sender lists are visible. - zero-knowledge proofs ensure no double-spend or inflation without revealing transaction details. - Users control their own data; no operator can freeze specific balances if forced exit is implemented. -- Funds are secured by L1; users can always exit with a valid proof. +- Funds are secured by L1: a user can exit without the block producer's cooperation only if they hold their own transaction history. Threat model: @@ -111,10 +111,10 @@ Threat model: - The block producer includes the transaction in a block and posts only the Merkle root to L1. - Institution B receives the note, verifies the proof, and stores it locally. - On-chain observers see only that a deposit occurred and that a state root was updated; no amounts and no parties. -- Institution B can later withdraw to any L1 address, breaking the link to the original depositor. +- Institution B can later withdraw to any L1 address. That breaks the direct deposit-to-withdrawal link, but sender-side unlinkability is bounded by the per-block sender lists published on L1: the anonymity set is the set of senders in the blocks involved, not the whole chain. ## See also - [Plasma original paper](https://plasma.io/) -- [Intmax2 paper (eprint 2023/1082)](https://eprint.iacr.org/2023/1082) +- [Intmax2 paper (eprint 2023/1082)](https://eprint.iacr.org/2023/1082) -- the paper presents Intmax2 as a ZK-rollup; it is grouped with Plasma here because Data Availability sits with users rather than on L1, which is the property this pattern turns on - [Post-Quantum Threats](../domains/post-quantum.md) diff --git a/patterns/pattern-private-stablecoin-shielded-payments.md b/patterns/pattern-private-stablecoin-shielded-payments.md index 84ef127..6963aa0 100644 --- a/patterns/pattern-private-stablecoin-shielded-payments.md +++ b/patterns/pattern-private-stablecoin-shielded-payments.md @@ -4,7 +4,7 @@ status: ready maturity: testnet type: standard layer: L2 -last_reviewed: 2026-06-17 +last_reviewed: 2026-09-18 works-best-when: - The cash leg must be private in both amounts and counterparties, with selective disclosure available to auditors. @@ -116,7 +116,6 @@ Threat model: - [Zama](../vendors/zama.md) - [Fhenix](../vendors/fhenix.md) - [Inco](../vendors/inco.md) -- [Canton Network press release on weekend USDC cash leg](https://www.canton.network/canton-network-press-releases/digital-asset-complete-on-chain-us-treasury-financing) - [Aztec programmable-privacy documentation](https://docs.aztec.network/) - [Zama confidential ERC-20 overview](https://www.zama.ai/post/confidential-erc-20-tokens-using-homomorphic-encryption) - [Fhenix encrypted computation overview](https://blog.arbitrum.io/fhenix-private-computation/) diff --git a/patterns/pattern-verifiable-attestation.md b/patterns/pattern-verifiable-attestation.md index c3b31ee..73e46c1 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-06-17 +last_reviewed: 2026-09-18 works-best-when: - Smart-contract logic must gate on off-chain attested facts (KYC status, accreditation, membership). @@ -27,9 +27,9 @@ 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, ONCHAINID (ERC-734/735), and W3C Verifiable Credentials are open standards with multiple implementations. 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. 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 or EIP-712 typed data), and the revocation registry being queryable on-chain." + 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." post_quantum: risk: high @@ -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. Current ECDSA and EIP-712 signatures are classically secure and PQ-vulnerable. +- Signature-scheme soundness. ECDSA, whether over a raw 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 @@ -103,10 +103,11 @@ A buyer on a tokenized bond platform holds an accredited-investor attestation is ## See also -- [EAS (Ethereum Attestation Service)](https://attest.sh/) -- [W3C Verifiable Credentials](https://www.w3.org/TR/vc-data-model/) -- [ERC-734](https://eips.ethereum.org/EIPS/eip-734) -- [ERC-735](https://eips.ethereum.org/EIPS/eip-735) +- [EAS (Ethereum Attestation Service)](https://attest.org/) +- [W3C Verifiable Credentials Data Model 2.0](https://www.w3.org/TR/vc-data-model-2.0/) +- [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) - [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-stablecoins.md b/use-cases/private-stablecoins.md index 26aef48..fb45322 100644 --- a/use-cases/private-stablecoins.md +++ b/use-cases/private-stablecoins.md @@ -47,9 +47,9 @@ See detailed solution architecture and trade-offs in [**Approach: Private Paymen **Jurisdiction-Specific Implementations:** -- **China:** Apply these patterns to e-CNY (Digital Yuan) infrastructure through approved BSN channels +- **China:** Stablecoins are out of scope; the state-sanctioned analogue is e-CNY, a centrally operated PBoC system distributed through licensed operator banks rather than a public ledger. Permissioned enterprise chains (BSN) are a separate programme and are not an access channel to e-CNY, so these patterns apply only where an approved operator admits them - **EU/US:** Licensed stablecoins under MiCA/GENIUS frameworks -- **Hong Kong:** SFC-licensed digital payment token services +- **Hong Kong:** HKMA-licensed issuers of fiat-referenced stablecoins under the [Stablecoins Ordinance (Cap. 656)](../jurisdictions/hk-crypto-licensing.md); SFC-licensed virtual asset trading platforms for the trading leg ### Non‑Solutions From d55e785567a55fe4617ab7837e48e14a0c80f85f Mon Sep 17 00:00:00 2001 From: rymnc <43716372+rymnc@users.noreply.github.com> Date: Fri, 18 Sep 2026 20:15:05 +0530 Subject: [PATCH 2/2] fix: touch these files --- approaches/approach-private-payments.md | 2 +- patterns/pattern-l2-encrypted-offchain-audit.md | 2 +- patterns/pattern-private-pvp-stablecoins-erc7573.md | 2 +- patterns/pattern-tee-based-privacy.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/approaches/approach-private-payments.md b/approaches/approach-private-payments.md index 6c0abcc..54c0abd 100644 --- a/approaches/approach-private-payments.md +++ b/approaches/approach-private-payments.md @@ -1,7 +1,7 @@ --- title: "Approach: Private Payments" status: ready -last_reviewed: 2026-08-11 +last_reviewed: 2026-09-18 use_case: private-stablecoins related_use_cases: [resilient-disbursement-rails, private-treasuries] diff --git a/patterns/pattern-l2-encrypted-offchain-audit.md b/patterns/pattern-l2-encrypted-offchain-audit.md index 835fe1d..9c4469e 100644 --- a/patterns/pattern-l2-encrypted-offchain-audit.md +++ b/patterns/pattern-l2-encrypted-offchain-audit.md @@ -4,7 +4,7 @@ status: ready maturity: testnet type: standard layer: hybrid -last_reviewed: 2026-06-17 +last_reviewed: 2026-09-18 works-best-when: - You need hidden amounts and positions with a minimal on-chain footprint. diff --git a/patterns/pattern-private-pvp-stablecoins-erc7573.md b/patterns/pattern-private-pvp-stablecoins-erc7573.md index 27f6b86..fcec47d 100644 --- a/patterns/pattern-private-pvp-stablecoins-erc7573.md +++ b/patterns/pattern-private-pvp-stablecoins-erc7573.md @@ -4,7 +4,7 @@ status: ready maturity: concept type: standard layer: hybrid -last_reviewed: 2026-09-11 +last_reviewed: 2026-09-18 works-best-when: - Two permissioned or regulated stablecoins (same L2 or cross-L2) must settle against each other with amount privacy, and both parties accept an oracle as the settlement trigger. diff --git a/patterns/pattern-tee-based-privacy.md b/patterns/pattern-tee-based-privacy.md index c1767e6..a2b6e67 100644 --- a/patterns/pattern-tee-based-privacy.md +++ b/patterns/pattern-tee-based-privacy.md @@ -4,7 +4,7 @@ status: ready maturity: production type: standard layer: offchain -last_reviewed: 2026-06-17 +last_reviewed: 2026-09-18 works-best-when: - Confidential computation is needed with lower latency than zero-knowledge proofs or multi-party computation can deliver.