Conversation
| | **Maturity** | documented | documented | documented | | ||
| | **Context** | i2i | i2i | i2i | | ||
| | **CROPS** | CR:hi O:y P:full S:hi | CR:med O:part P:part S:med | CR:med O:no P:full S:lo | | ||
| | **Trust model** | Math + threshold (t-of-n) for NAV opening | Threshold (t-of-n) decryption | Hardware vendor + supply chain | |
There was a problem hiding this comment.
The ZK section still requires an independent threshold group for NAV opening (L74–80), while L176 says “none beyond the transfer agent.” Is that threshold still part of the intended model, and how does it fit with the transfer agent’s role?
There was a problem hiding this comment.
Good catch, thanks! The independent threshold is no longer part of the model. A threshold stays only as an option for holding the register key. I missed these lines in the ZK section. Fixed in 8b249ec
For ZK Shielded Commitments, the independent threshold is no longer part of the model
| - url: https://github.com/ethsystems/pocs/tree/master/pocs/private-payment/shielded-pool-compliance | ||
| description: "EthSystems PoC: KYC-gated shielded pool with in-circuit compliance" | ||
| language: "Noir, Solidity, Rust" | ||
| - url: https://github.com/ethsystems/pocs/tree/master/pocs/private-bond/fhe | ||
| description: "EthSystems PoC (draft): FHE confidential bond on Zama's fhEVM" | ||
| language: "Solidity, TypeScript" | ||
| - url: https://github.com/ethsystems/pocs/tree/master/pocs/private-trade-settlement/tee_swap | ||
| description: "EthSystems PoC (draft): TEE-coordinated atomic swaps of private notes" | ||
| language: "Rust, Noir, Solidity" |
There was a problem hiding this comment.
do any of these belong here for implementations of private money market funds?
There was a problem hiding this comment.
Good point, none are MMF implementations, but building blocks. I've dropped the two drafts from other use cases and kept the shielded-pool base our PoC builds on, plus Railgun and OpenZeppelin's ERC-7984 contracts for the FHE route. The future PoC can go in a pocs: block once done.
| - Atomic subscription and redemption settlement (no partial fills) | ||
| - Daily or intraday NAV computation with verifiable correctness (total shares outstanding stays public) | ||
| - Aggregate figures are published at the fund's cadence, not per transaction, so totals don't reveal individual flows | ||
| - SEC Rule 2a-7 (US) and ESMA MMFR (EU) compliance: gates (MMFR only; removed from Rule 2a-7 in 2023), liquidity fees, concentration limits. Private funds follow offering rules instead, such as eligibility and investor-count limits. |
There was a problem hiding this comment.
this can be reworded
| - SEC Rule 2a-7 (US) and ESMA MMFR (EU) compliance: gates (MMFR only; removed from Rule 2a-7 in 2023), liquidity fees, concentration limits. Private funds follow offering rules instead, such as eligibility and investor-count limits. | |
| - SEC Rule 2a-7 (US) and ESMA MMFR (EU) compliance: liquidity fees, concentration limits, and MMFR liquidity gates. Private funds instead follow offering requirements such as investor eligibility and investor-count limits. |
| - The confidential set is small and concentrated, so unlinkability gains are limited | ||
|
|
||
| **Implementation notes:** PoC uses Railgun-class shielded pool primitives. Compliance gates encoded as ZK public outputs (e.g., post-redemption weekly liquid assets ≥ 50%, the SEC Rule 2a-7 minimum since the 2023 amendments); regulator scope via per-position view keys logged through EAS. Yield attribution uses pro-rata share-of-total computation: each redeemer proves `my_shares / total_shares * total_yield = entitled_amount`. | ||
| **Implementation notes:** PoC uses Railgun-class shielded pool primitives, as in EthSystems' [shielded-pool-compliance](https://github.com/ethsystems/pocs/tree/master/pocs/private-payment/shielded-pool-compliance) PoC: a KYC-gated pool with attestation expiry, a compliance policy enforced inside the value-conserving circuits, and an encrypted audit channel to a threshold committee. An MMF variant adds issuance into investor positions, yield distribution and investor counters. Compliance gates encoded as ZK public outputs (e.g., eligibility and jurisdiction caps; portfolio rules such as post-redemption weekly liquid assets ≥ 50%, the SEC Rule 2a-7 minimum since the 2023 amendments, are measured on the fund's assets, outside the pool); regulator scope via per-position view keys logged through EAS. Yield attribution uses pro-rata share-of-total computation: each redeemer proves `my_shares / total_shares * total_yield = entitled_amount`. This fits a floating-NAV fund, and only with entry NAV tracked per position; in a stable-NAV fund, yield reaches positions as new shares, through a periodic mint into each position or a public multiplier over share-denominated positions. |
There was a problem hiding this comment.
| **Implementation notes:** PoC uses Railgun-class shielded pool primitives, as in EthSystems' [shielded-pool-compliance](https://github.com/ethsystems/pocs/tree/master/pocs/private-payment/shielded-pool-compliance) PoC: a KYC-gated pool with attestation expiry, a compliance policy enforced inside the value-conserving circuits, and an encrypted audit channel to a threshold committee. An MMF variant adds issuance into investor positions, yield distribution and investor counters. Compliance gates encoded as ZK public outputs (e.g., eligibility and jurisdiction caps; portfolio rules such as post-redemption weekly liquid assets ≥ 50%, the SEC Rule 2a-7 minimum since the 2023 amendments, are measured on the fund's assets, outside the pool); regulator scope via per-position view keys logged through EAS. Yield attribution uses pro-rata share-of-total computation: each redeemer proves `my_shares / total_shares * total_yield = entitled_amount`. This fits a floating-NAV fund, and only with entry NAV tracked per position; in a stable-NAV fund, yield reaches positions as new shares, through a periodic mint into each position or a public multiplier over share-denominated positions. | |
| **Implementation notes:** The PoC uses Railgun-class shielded pool primitives from EthSystems' [shielded-pool-compliance](https://github.com/ethsystems/pocs/tree/master/pocs/private-payment/shielded-pool-compliance), with KYC-gated entry, attestation expiry, circuit-level compliance checks, and an encrypted audit channel. The MMF variant adds investor positions, yield distribution, investor counters, ZK compliance outputs, per-position regulator view keys, and pro-rata yield attribution, with fund-level portfolio rules measured outside the pool. |
railgun-class is a little iffy here. its not railgun class exactly - maybe we can omit it and reference the shielded pool spec here instead (https://specs.ethsystems.org/2/)
There was a problem hiding this comment.
Agreed on dropping Railgun-class; it now cites 2/SHIELDED-POOL and 3/ATTESTED-POOL. I took your rewrite with one change: 'pro-rata yield attribution' became yield as new shares (mint or multiplier), since pro-rata only fits floating-NAV funds. Updated in updated in 7179e01
| - How does yield attribution work with position privacy? *(See the [approach card](../approaches/approach-private-money-market-funds.md#open-questions): answered for stable-NAV funds, where yield arrives as new shares; open for floating-NAV funds, open question 1.)* | ||
| - What's the relationship to stablecoin privacy patterns? *(See the [approach card](../approaches/approach-private-money-market-funds.md#open-questions), open questions 4 and 5: the cash leg and a shared anonymity set.)* | ||
| - How to handle fund gates/fees with position privacy? *(See the [approach card](../approaches/approach-private-money-market-funds.md#constraints): they depend only on aggregate flows; portfolio rules are unaffected by investor privacy.)* | ||
| - How do holders that must stay public coexist with confidential ones? *(See the [approach card](../approaches/approach-private-money-market-funds.md#open-questions), open question 7.)* |
There was a problem hiding this comment.
not sure if i like this format - if a question is answered for a stable-nav fund, then why is the question not framed just for floating-nav funds?
these can all be reworded - if the open question is answered, we can drop it. if it has more nuance with the recent research, they can be reworded
What are you adding?
Description
Phase 1 review of the Private MMF approach card and use case, for the approach cycle. Continuation of the pattern maintenance in #205.
documented, three comparison rows, a conditional recommendation, new open questions (collateral as a future extension).Checklist