For a yield-bearing tokenized treasury product where operator-independent NAV verification is the load-bearing property, ZK Shielded Commitments is the default: positions and redemptions are private, the running-total commitment is opened by a threshold subset of custodians and auditors who do not include the operator, and the fund continues to function under operator outage. FHE suits funds with complex yield logic (multi-strategy MMFs, dynamic allocation) where homomorphic arithmetic removes circuit-design overhead; the trade-off is reliance on the FHE network for both decryption and throughput. TEE is a viable PoC starting point and a near-term production option for funds whose custodians already accept hardware-rooted trust.

The dominant engineering question is the NAV-proof model. ZK with a running total_shares commitment keeps per-transaction proving constant and pushes full-audit cost off the critical path; circuit complexity for gate enforcement and yield attribution is the ceiling. FHE simplifies the programming model but inherits shared-throughput limits and per-ciphertext revocation gaps. TEE eliminates both proving cost and revocation issues but introduces a hardware trust chain and side-channel surface that auditors must accept. Threshold custody administration (key rotation, custodian onboarding, t parameter selection) is non-trivial across all three.

This is a perspective for legal review by the deploying fund operator, not legal advice. The three options expose distinct evidence patterns: ZK Shielded Commitments via per-position view keys plus ZK public outputs proving gate compliance (liquidity ratio, concentration) without revealing positions, with EAS-logged disclosures as the trail; FHE via per-balance ACL granularity with no per-ciphertext revocation (revocation depends on subsequent balance updates triggering re-grants, or the disclosure model has to rely on append-only audit logs); TEE via enclave-mediated disclosure that depends on enclave-code reproducibility, multi-party signing, and the vendor governance model. Whether any of these patterns satisfies SEC Rule 2a-7 or ESMA MMFR auditor expectations is a question for jurisdictional review. Threshold custodian composition (independence from the operator, jurisdictional diversity) is a structural-risk parameter that legal review would weigh in any of the three.

Requirements

  • Daily or intraday NAV computation with verifiable correctness
  • SEC Rule 2a-7 (US) and ESMA MMFR (EU) compliance: gates, liquidity fees, concentration limits
  • Atomic subscription and redemption settlement (no partial fills)
  • Yield attribution provably correct per investor without revealing positions
  • Operator-independent solvency: NAV verifiable by a threshold subset, not the operator

Constraints

  • Threshold opening (t-of-n) by independent custodians or auditors must be administratively feasible
  • Periodic full-audit checkpoints must run off the critical path of subscription/redemption
  • Fund-circuit hash registered immutably at deployment; circuit upgrades imply migration
  • Compliance gates (Rule 2a-7 liquidity ratio, concentration limits) must be enforceable without revealing individual positions

Architectural options

ZK Shielded Commitments

prototyped

Share positions are shielded UTXO commitments; a running `total_shares` commitment is updated per transaction; NAV opens via threshold key holders independent of the operator.

How it works

Each position is a commitment to (attestation hash, share count, entry NAV). Subscription mints a position commitment and increments a running Pedersen commitment to total_shares; redemption nullifies the position and decrements the running total. ZK circuits enforce conservation, gate logic (Rule 2a-7 liquidity ratio, concentration), and yield-attribution constraints. NAV is computed by any t-of-n threshold key holders opening total_shares and multiplying by an oracle price-per-share; a periodic full-audit checkpoint verifies the running total against all active positions, off the redemption critical path.

Trust assumptions
  • L1 / L2 consensus and verifier contract correctness
  • Threshold custodian / auditor set (t-of-n) for NAV opening; operator does not participate in the threshold
  • Oracle integrity for per-share price (single oracle or quorum)
Threat model
  • Adversary observes L1 / L2; cannot break ZK soundness
  • Threshold compromise (t collusions) reveals NAV but not individual positions
  • Oracle compromise distorts NAV; mitigated by quorum
  • Periodic full-audit catches running-total drift from circuit bugs
Works best when
  • Operator independence is a hard requirement (regulator, donor policy, internal governance)
  • Daily or intraday NAV cadence matches the proving budget
  • Threshold custodian / auditor administration is feasible
Avoid when
  • Yield logic is complex enough that circuit complexity exceeds practical bounds
  • Threshold administration overhead (key rotation, custodian onboarding) is unacceptable
Implementation notes

PoC uses Railgun-class shielded pool primitives. Compliance gates encoded as ZK public outputs (e.g., post-redemption liquidity ratio > 30%); 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.

FHE Encrypted Balances

prototyped

Balances are FHE ciphertexts on an FHE-enabled L2; NAV is computed homomorphically; threshold key holders decrypt for publication.

How it works

Subscriptions encrypt the share count under the FHE network's keys; balances are stored as ciphertexts with ACL-based read access. NAV is computed under encryption (sum of ciphertexts × per-share price); a t-of-n threshold network decrypts the result for posting on chain. Yield attribution runs as homomorphic arithmetic; gate logic uses encrypted comparisons.

Trust assumptions
  • t-of-n threshold network for FHE decryption keys
  • FHE library implementation correctness
  • ACL grants honored by all participants
Threat model
  • Threshold compromise reveals all balances
  • No revocation per ciphertext; ACL revocation requires re-encryption on balance update
  • Shared throughput across all FHE applications on the network is a bottleneck
Works best when
  • Yield logic is complex (path-dependent strategies) and benefits from homomorphic arithmetic
  • Per-balance ACL granularity matches the disclosure model
  • Threshold-network trust is acceptable to all custodians
Avoid when
  • Operator independence requires that no single network be load-bearing
  • Throughput pressure across all FHE applications is unacceptable

TEE Enclave

prototyped

Positions sealed inside a TEE enclave; NAV computed in the clear internally; remote-attested results posted on chain.

How it works

Subscriptions are encrypted to the enclave's attested public key; the enclave maintains positions in cleartext memory. NAV computation, gate enforcement, and yield attribution all run inside the enclave; the enclave signs results under its attested key. Selective disclosure runs through enclave-mediated views: regulators submit signed queries, the enclave returns scoped responses.

Trust assumptions
  • TEE vendor and remote-attestation chain (Intel TDX, AMD SEV, AWS Nitro, Azure CC)
  • Cloud co-tenant isolation
  • Enclave software supply chain (reproducible build, multi-party signing)
Threat model
  • Side-channel and microarchitectural attacks against the enclave class
  • Vendor compromise or compelled disclosure of attestation keys
  • Enclave software vulnerabilities expose all fund state to a single-party adversary
Works best when
  • Near-term deployment is needed and ZK / FHE proving costs are prohibitive
  • Hardware trust is already accepted by custodians
  • Enclave reproducibility and signing pipeline are operationalized
Avoid when
  • Threat model includes nation-state-class side-channel adversaries
  • Operator independence requires that no single hardware vendor be load-bearing

Side-by-side

Axis ZK Shielded Commitments FHE Encrypted Balances TEE Enclave
Maturity prototyped prototyped prototyped
Context i2i i2i i2i
Trust model Math + threshold (t-of-n) for NAV opening Threshold (t-of-n) decryption Hardware vendor + supply chain
Privacy scope Amounts + addresses Amounts only; addresses public Amounts + addresses (inside enclave)
Performance Constant per tx; periodic full-audit scales with positions Heaviest compute; shared throughput Cheapest; near-instant
Operator req. None (relayer optional) Yes (threshold network) Yes (enclave host)
Cost class Medium-high Medium Low
Regulatory fit Strong (per-position view keys, EAS-logged) Strong (per-balance ACL, no revocation) Conditional (vendor attestation)
Failure modes Threshold compromise; circuit bugs; oracle compromise Threshold compromise; no revocation; throughput Side-channel; vendor compromise; enclave outage

Decision factors

  • If yield logic is complex (multi-strategy, path-dependent) and per-balance ACL granularity is required, choose FHE Encrypted Balances.
  • If near-term deployment is required and custodians already accept hardware-rooted trust, choose TEE Enclave as a PoC or transitional path.
  • If operator independence cannot be administered through threshold custody, none of the three approaches removes the trust assumption, re-scope the requirement.

Hybrid composition

Run primary NAV through ZK Shielded Commitments; use TEE for high-frequency intraday yield strategies that exceed practical proving budgets, with the TEE output committed back into the ZK running total at the next checkpoint. FHE handles complex strategy attribution where the dominant operation is homomorphic arithmetic. Compliance gating runs uniformly through the regulator-disclosure-keys pattern across all rails.

Open questions
  1. Yield-cohort attribution. Balancing fungible-share privacy against the complexity of attributing yield across different entry-NAV cohorts; pro-rata is the working assumption but other models may better serve specific products.
  2. Peer-to-peer share trading. Shielded MMF shares traded peer-to-peer with privately enforced NAV-based pricing; integration with shielded DvP is unresolved.
  3. Mixed-currency underlying. Hiding currency exposure when the underlying basket spans multiple currencies; oracle and ACL design are unresolved.
  4. MMF-as-cash-equivalent. Whether shielded MMF shares can serve as the cash leg in DvP for other instruments.

Last reviewed