rymnc · Oct 6, 2026 · Oct 5, 2026
@@ -4,6 +4,7 @@ All notable changes to the EthSystems Map are documented here.
 
 ## [Unreleased]
 
+- 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.
 - chore(pattern): re-review [Private Client Authentication for Institutional EOAs](patterns/pattern-private-mtp-auth.md) and [Compliance Monitoring](patterns/pattern-compliance-monitoring.md); no content change.

@@ -1,7 +1,7 @@
 ---
 title: "Approach: Private Payments"
 status: ready
-last_reviewed: 2026-09-29
+last_reviewed: 2026-10-05
 
 use_case: private-stablecoins
 related_use_cases: [resilient-disbursement-rails, private-treasuries]
@@ -136,7 +136,7 @@ example_vendors: [railgun]
 
 | Operation          | Value                      |
 | ------------------ | -------------------------- |
-| Gas: deposit       | ~155K                      |
+| Gas: deposit       | ~155K + ~2.6M verification |
 | Gas: transfer      | ~181K + ~2.6M verification |
 | Gas: withdraw      | ~47K + ~2.6M verification  |
 | Proof gen (client) | 410-991ms                  |
@@ -197,7 +197,7 @@ poc_spec: pocs/private-payment/plasma/SPEC.md
 
 **Summary:** Operator-coordinated rollup posts only Merkle roots on L1; users custody their transaction history client-side.
 
-**How it works:** Users build proofs of inclusion against operator-published roots. Operators batch transfers, generate aggregated SNARKs (Plonky2-style recursion), and post anchor data to L1. Withdrawals exit through an L1 anchor contract via an exit game; users prove sufficient balance to escape an offline operator.
+**How it works:** Users build proofs of inclusion against operator-published roots. Operators batch transfers, generate aggregated SNARKs (Plonky2-style recursion), and post anchor data to L1. Withdrawals are claimed against the anchor contract with a zero-knowledge balance proof; users can submit balance proofs directly to exit when the operator is offline.
 
 **Trust assumptions:**
 
@@ -207,7 +207,7 @@ poc_spec: pocs/private-payment/plasma/SPEC.md
 
 **Threat model:**
 
-- Operator offline or censoring forces escape-game exits with weaker privacy
+- Operator offline or censoring forces proof-based direct exits with weaker privacy
 - User data loss collapses to lost funds; backup architecture is load-bearing
 - Operator equivocation needs fraud-proof or multi-operator dispute
 
@@ -216,14 +216,14 @@ poc_spec: pocs/private-payment/plasma/SPEC.md
 - Volume is high and minimal L1 footprint matters
 - Institution can run or contract user-side state custody
 - Forced withdrawal as a recovery path is acceptable
-- End users custody their own state by design; operator cannot censor without triggering the exit game, making the I2U privacy property structural rather than contingent
+- End users custody their own state by design; operator cannot censor without users falling back to proof-based direct exits, making the I2U privacy property structural rather than contingent
 
 **Avoid when:**
 
 - User-side state custody is operationally infeasible
 - Exit-delay risk is not tolerable for the asset class
 
-**Implementation notes:** PoC uses Plonky2 with operator-side recursive aggregation; client proofs run in 5.9-9.8s, operator proofs in 38-49s. PlasmaBlind (folding-scheme aggregation) is a tracked alternative.
+**Implementation notes:** PoC uses Plonky2 with operator-side recursive aggregation; user proofs (run by the balance-prover service, not on device) take 5.9-9.8s and operator proofs 38-49s. PlasmaBlind (folding-scheme aggregation) is a tracked alternative.
 
 #### Benchmarks
 
@@ -233,7 +233,7 @@ poc_spec: pocs/private-payment/plasma/SPEC.md
 | Gas: transfer        | Off-chain (operator-set fee) |
 | Gas: withdraw        | ~343K (operator, amortized)  |
 | Gas: batch           | ~255K (operator, amortized)  |
-| Proof gen (client)   | 5.9-9.8s                     |
+| Proof gen (user)     | 5.9-9.8s                     |
 | Proof gen (operator) | 38-49s                       |
 
 ### TEE-Based Privacy
@@ -285,7 +285,7 @@ example_vendors: [taceo-merces]
 
 **Summary:** MPC nodes jointly compute transfers under secret-shared balances; co-SNARKs commit a verifiable summary on chain.
 
-**How it works:** Bilateral counterparties send secret-shared inputs to an MPC committee that runs the transfer logic and produces a collaborative SNARK. The chain verifies the SNARK; counterparty addresses are public, but amounts and balance state are hidden under sharing.
+**How it works:** Bilateral counterparties send secret-shared inputs to an MPC committee that runs the transfer logic and produces a collaborative SNARK. The chain verifies the SNARK; amounts and balances stay hidden, and addresses can be hidden too depending on configuration.
 
 **Trust assumptions:**
 
@@ -296,7 +296,7 @@ example_vendors: [taceo-merces]
 **Threat model:**
 
 - Collusion above the threshold reveals all state
-- Counterparty addresses leak; only amount confidentiality is provided
+- Counterparty addresses leak unless the configuration hides them
 - MPC committee liveness is an availability boundary
 
 **Works best when:**
@@ -340,7 +340,7 @@ example_vendors: []
 **Trust assumptions:**
 
 - IResilientIdentity operator and implementing partner are distinct legal entities, jurisdictions, and personnel
-- Relay set meets size and jurisdictional-diversity floors (pilot N≥8 / ≥2 operators / ≥2 jurisdictions; production N≥16 / ≥4 operators / ≥3 jurisdictions)
+- Relay set meets size and jurisdictional-diversity floors (pilot ≥8 independent operators, production ≥16, with jurisdictional diversity)
 - Smartcard secure-element vendor and applet supply chain
 - Mesh transport availability for last-mile
 
@@ -391,7 +391,7 @@ Engineering capacity dictates a lot. L1 Shielded Payments is the lightest integr
 
 ### Legal & risk perspective
 
-This is a perspective for legal review by the deploying institution, not legal advice. L1 Shielded Payments and Privacy L2, paired with viewing-key disclosure, expose per-jurisdiction view keys and attestation logs (EAS, ONCHAINID) as the disclosure interface; whether that interface satisfies MiCA, GENIUS Act, or another regime is a question for jurisdictional review. Stateless Plasma adds operator records as an additional disclosure surface that legal review would scope. TEE attestations are typically accepted by auditors who already accept HSM-rooted custody, but acceptance varies by regulator. MPC exposes per-counterparty audit; address-level visibility may limit use to known-counterparty contexts depending on the regulator's view. Resilient Disbursement Rails inverts the disclosure model by minimizing what each party holds; whether a humanitarian regime accepts that posture depends on the donor policy and the destination-country regulator, and legal sign-off would document the minimization and the multi-jurisdiction relay roster.
+This is a perspective for legal review by the deploying institution, not legal advice. L1 Shielded Payments and Privacy L2, paired with viewing-key disclosure, expose per-jurisdiction view keys and attestation logs (EAS, ONCHAINID) as the disclosure interface; whether that interface satisfies MiCA, GENIUS Act, or another regime is a question for jurisdictional review. Stateless Plasma adds operator records as an additional disclosure surface that legal review would scope. TEE attestations are typically accepted by auditors who already accept HSM-rooted custody, but acceptance varies by regulator. MPC exposes per-counterparty audit; address-level visibility, where configured, may limit use to known-counterparty contexts depending on the regulator's view. Resilient Disbursement Rails inverts the disclosure model by minimizing what each party holds; whether a humanitarian regime accepts that posture depends on the donor policy and the destination-country regulator, and legal sign-off would document the minimization and the multi-jurisdiction relay roster.
 
 ## Recommendation
 

@@ -87,5 +87,5 @@ 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
+- Asia: the Hong Kong SAR Government issued digital green bonds in 2023, 2024 and November 2025 (HK$10 billion third offering on HSBC Orion, optional e-HKD/e-CNY settlement) ([HKSAR Government](https://www.info.gov.hk/gia/general/202511/11/P2025111100724.htm)); Japan amended the Local Finance Act in 2026 so local governments can issue municipal bonds as blockchain-based digital securities from 1 April 2027, giving issuers real-time holder information ([Cabinet Office summary](https://www.cao.go.jp/bunken-suishin/doc/r07/16ikkatuho_gaiyou.pdf))
 - See also: [EPIC map](https://epic-webapp.vercel.app/) (GovTech & EPIC team): treasury transparency, audit trails
@@ -73,4 +73,4 @@ See detailed solution architecture and trade-offs in [**Approach: Private Money
 - Related: [private-stablecoins.md](private-stablecoins.md) (non-yield alternative; settlement cash)
 - Related: [private-treasuries.md](private-treasuries.md) (corporate treasury use of MMFs)
 - Differentiation: Unlike stablecoins, money market funds earn yield. Institutions prefer MMFs over non-yield stablecoins for treasury management.
-- Market context: Tokenized treasuries/MMFs are among the largest RWA categories outside stablecoins
+- Market context: Tokenized U.S. Treasury funds, including Treasury MMFs, are the largest distributed RWA category outside stablecoins: USD 14.8B of USD 38.8B per [rwa.xyz](https://app.rwa.xyz/treasuries) (2026-10-05)
@@ -27,7 +27,7 @@ Business-to-business payment patterns reveal supplier relationships, pricing, an
 
 - **Must hide:** Amounts, counterparty identities, payment purpose/memo, timing patterns
 - **Public OK:** Payment system availability, general network statistics
-- **Regulator access:** AML/CFT monitoring, tax reporting, sanctions screening
+- **Regulator access:** AML/CFT monitoring, Travel Rule originator and beneficiary information ([FATF R.16, revised June 2025](https://www.fatf-gafi.org/en/publications/Fatfrecommendations/update-Recommendation-16-payment-transparency-june-2025.html)), tax reporting, sanctions screening
 
 **Constraints:**
 
@@ -69,7 +69,7 @@ Institutions disbursing grants or payments on the ground (government-to-person t
 
 ## 5) Recommended Approaches
 
-See [Approach: Private Payments](../approaches/approach-private-payments.md) for detailed solution architecture covering L1 shielded pools, Plasma/Intmax2 stateless rollups, privacy L2s, TEE, and MPC approaches with quantitative comparison from PoC validation.
+See [Approach: Private Payments](../approaches/approach-private-payments.md) for detailed solution architecture covering L1 shielded pools, Plasma/Intmax2 stateless rollups, privacy L2s, TEE, MPC, and Resilient Disbursement Rails, with PoC benchmarks for the L1 shielded pool and stateless Plasma.
 
 See also [private-stablecoins.md](private-stablecoins.md) for stablecoin-specific privacy patterns. Additional considerations:
 
@@ -91,7 +91,8 @@ 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)
+- Related: [resilient-disbursement-rails.md](resilient-disbursement-rails.md) (humanitarian disbursement in adversarial jurisdictions)
 - 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
+- Market context: Governments building digital currency infrastructure; cross-border payment networks exploring blockchain settlement, including Swift's own shared-ledger plan ([announced September 2025](https://consensys.io/blog/consensys-scaling-decentralized-finance), prototype by Consensys)
 - 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
@@ -32,7 +32,7 @@ Institutions need practical paths to onboard their users (corporates, funds, cou
 - **Must hide:** transfer **amounts**, **payer/payee identities to non-participants**, and **memos/workflow metadata**; optionally timing/ordering leakage minimised
 - **Public OK:** existence of a transaction/anchor; contract code; allow-list membership proofs (no PII); attestation schemas
 - **Regulator access:** **scoped viewing keys** and/or **[attestations](../patterns/pattern-verifiable-attestation.md)** with **access logging**; revocation & rotation policies
-- **Settlement:** **Atomic DvP/PvP** across cash↔asset or cash↔cash using [ERC‑7573](https://ercs.ethereum.org/ERCS/erc-7573) semantics; minutes‑level finality OK for pilot
+- **Settlement:** **Atomic DvP/PvP** across cash↔asset or cash↔cash using [ERC‑7573](https://ercs.ethereum.org/ERCS/erc-7573) conditional settlement (Draft; atomicity rests on the decryption oracle, and ERC-7573 itself hides no amounts or counterparties); minutes‑level finality OK for pilot
 - **Ops:** predictable L2 costs; encrypted audit log with L1 anchors; issuer controls (freeze/blacklist) where mandated; KYC holder gating (e.g., [ERC‑3643](https://eips.ethereum.org/EIPS/eip-3643))
 
 **Constraints:**
@@ -48,7 +48,7 @@ See detailed solution architecture and trade-offs in [**Approach: Private Paymen
 **Jurisdiction-Specific Implementations:**
 
 - **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
+- **EU/US:** Licensed stablecoins under MiCA (stablecoin titles apply since 30 June 2024) and the US GENIUS Act (enacted 18 July 2025; takes effect by 18 January 2027 at the latest, implementing rules still in progress)
 - **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
@@ -68,7 +68,7 @@ See detailed solution architecture and trade-offs in [**Approach: Private Paymen
 
 ## 7) Notes And Links
 
-- **Standards & Infrastructure:** [ERC‑7573](https://ercs.ethereum.org/ERCS/erc-7573) · [ERC‑3643](https://eips.ethereum.org/EIPS/eip-3643) · [ERC‑5564 Stealth Addresses](https://eips.ethereum.org/EIPS/eip-5564) · [Aztec](https://docs.aztec.network/) · [Zama fhEVM](https://www.zama.ai/post/confidential-erc-20-tokens-using-homomorphic-encryption) · [Fhenix](https://www.fhenix.io/)
+- **Standards & Infrastructure:** [ERC‑7573](https://ercs.ethereum.org/ERCS/erc-7573) · [ERC‑3643](https://eips.ethereum.org/EIPS/eip-3643) · [ERC‑5564 Stealth Addresses](https://eips.ethereum.org/EIPS/eip-5564) · [Aztec](https://docs.aztec.network/) · [Zama fhEVM](https://www.zama.org/post/confidential-erc-20-tokens-using-homomorphic-encryption) · [Fhenix](https://www.fhenix.io/)
 - **Regulatory Frameworks (jurisdiction-specific):** see [jurisdiction](../jurisdictions/)
 - **Technical Note on Privacy:** FHE implementations (Fhenix, Zama fhEVM) encrypt data-in-use providing **confidentiality** but **not unlinkability**. To hide address linkage and prevent transaction graph analysis, combine with **[ERC-5564 Stealth Addresses](https://eips.ethereum.org/EIPS/eip-5564)** or equivalent unlinkability mechanisms.