Tokenized Money Market Fund

The Tokenized Money Market Fund is available today as a production-ready product on Cocoon.

Business Context

Money market funds are among the most widely held instruments in institutional cash management. A fund holds short-duration, high-quality assets — treasury bills, commercial paper, repurchase agreements — and issues shares to investors who receive daily yield with near-immediate liquidity. In practice, the operational reality falls far short of that promise.

Traditional fund administration involves a chain of intermediaries: transfer agents, fund accountants, custodians, and prime brokers. Subscription and redemption cycles typically settle T+1 or T+2, meaning capital is in transit and not earning yield during that window. KYC onboarding is handled bilaterally between each investor and the fund administrator, producing siloed records that are re-verified on every new relationship. NAV is calculated overnight by the fund accountant and distributed via PDF or data feed — opaque to any on-chain logic. Fund reports reach auditors and regulators through secure file transfer processes that are manual, error-prone, and difficult to audit.

The result: a product that promises liquidity but delivers settlement friction, a compliance posture that is expensive to maintain, and a reporting infrastructure that cannot participate in automated downstream workflows.

How Cocoon Solves This

Cocoon tokenizes MMF shares as ERC-3643 permissioned tokens. Each share transfer is gated by on-chain compliance modules that check investor eligibility in real time — no manual intervention required. Settlement is atomic: subscription and redemption execute as Delivery versus Payment (DVP) transactions, meaning cash and tokens move simultaneously with no counterparty risk and no settlement window.

Investor identity and KYC claims live on-chain via OnchainID. Once an investor is onboarded, their eligibility is verifiable by any contract in the Cocoon ecosystem without re-submitting documentation. Compliance rules — jurisdiction restrictions, maximum holding limits, freeze authority — are encoded directly in the token contract and enforced at the protocol level.

Cash settlement uses DBC (Digital Bearer Certificates), Cocoon's confidential cash layer. DBC amounts are hidden using RingCT commitments, so counterparties see only that a valid payment occurred — not the size of any investor's position. This preserves the compliance transparency that regulators require (who transferred, to whom, whether they were eligible) while protecting the commercial confidentiality that institutional investors expect.

Fund documents — NAV reports, auditor letters, regulatory filings — are encrypted and published via torrent-ccip, accessible only to authorized parties whose OnchainID holds the appropriate claim.

Token and Cash Duality

The MMF design reflects a deliberate asymmetry between token transparency and cash confidentiality.

Token transfers are transparent to compliance. The ERC-3643 registry records every holder, every transfer, every compliance check. Regulators, auditors, and the fund manager can see the full ownership history. This is a feature: it replaces the transfer agent's proprietary ledger with a shared, auditable record while preserving the fund manager's ability to freeze, force-transfer, or restrict tokens under applicable law.

Cash movements are confidential. When an investor pays for a subscription or receives a redemption, the DBC amount is hidden. Other market participants cannot observe the size of any investor's cash flows. The fund administrator and the investor's own identity contract can verify settlement, but the amount is not visible on-chain to third parties.

This duality matches regulatory expectations: token ownership (fund exposure) is reportable; payment flows (investor cash balances) are private.

Investor Lifecycle

The full investor journey — from initial onboarding through yield distribution — runs as follows:

Onboarding

1. The investor deploys an OnchainID identity contract on Cocoon.

2. A KYC/AML claim is issued by an authorized claim issuer — typically the fund's compliance agent or a regulated identity provider.

3. The identity is registered in the MMF token's identity registry, making the investor eligible to hold and transfer the token.

Onboarding is a one-time process per investor. Once the OnchainID is registered and claims are current, the investor can participate in any product that recognizes the same registry without re-submitting documentation.

Subscription

1. The investor acquires DBC cash (from a prior redemption, an OTC desk, or another on-chain source).

2. The investor locks DBC into the subscription escrow contract.

3. The escrow reads the current NAV from the NAV oracle and computes the number of shares to mint.

4. DVP executes: DBC is burned (or transferred to the fund's cash account) and MMF tokens are minted to the investor in a single atomic transaction.

If the transaction reverts for any reason — stale NAV, compliance rejection, insufficient balance — no state changes. There is no partial settlement.

Redemption

1. The investor calls the redemption function, locking their tokens in escrow.

2. The escrow reads NAV and computes the DBC payout.

3. DVP executes: tokens are burned and DBC is released to the investor atomically.

Yield Distribution

Yield accrues as the fund's NAV increases. Distributions are made on the fund's schedule by minting additional DBC to registered holders proportionally, or by adjusting the token-to-NAV ratio depending on the fund's accumulating vs. distributing structure.

NAV Oracle

The fund's net asset value is published on-chain by the fund accountant or an authorized price feed. The NAV oracle contract:

• Accepts signed NAV updates from authorized publisher addresses

• Enforces a staleness window — subscriptions and redemptions revert if the NAV is older than a configurable threshold (typically 24 hours for daily-priced funds)

• Emits an event log of every NAV publication for audit purposes

The oracle is not a price feed in the DeFi sense. It does not aggregate multiple sources or use TWAP logic. It is a credentialed publication mechanism: the fund accountant signs and submits the NAV, the contract verifies the signature, and the value becomes available for DVP pricing.

Compliance Modules

Every MMF token transfer passes through a stack of compliance modules checked atomically at transfer time:

Module	What It Checks
Country Allow List	Investor's registered jurisdiction is on the fund's permitted country list
Max Balance	Transfer would not cause the investor to exceed their holding limit
Freeze Status	Neither the sender nor receiver is frozen by the fund manager
Claim Validity	Investor's KYC/AML claim is current and issued by an authorized issuer
Transfer Pause	Fund-level pause is not active (used during NAV calculation windows or regulatory holds)

Compliance checks are read-only calls against on-chain state. They add no settlement latency beyond gas execution.

Document Management

Fund documents — monthly reports, audited financial statements, regulatory notices, tax summaries — are managed through Cocoon's torrent-ccip document layer:

1. The fund administrator encrypts the document with a key derived from the recipient set's OnchainID claims.

2. The encrypted document is published to the distributed content network.

3. The content hash and access metadata are anchored on-chain.

4. Authorized parties (investors with valid claims, auditors with auditor claims, regulators with regulatory claims) can retrieve and decrypt the document.

No document content is stored on-chain. The chain holds only the hash, the access policy, and the publication timestamp. This keeps gas costs minimal while providing a tamper-evident audit trail.

ZK State Verification

Cocoon generates QMTree-based ZK proofs of the MMF token state that are verified on Ethereum mainnet. This means:

• The total supply, holder set, and compliance state of the fund are verifiable by any Ethereum contract or off-chain verifier.

• Institutional counterparties who cannot or will not run a Cocoon node can still verify fund state trustlessly.

• Regulatory reporting can reference on-chain Ethereum proofs rather than relying on the fund administrator's attestation.

Proofs are generated on a configurable cadence and submitted to the Cocoon ZK verifier contract on Ethereum.