How It Works

Cocoon is organised into four layers. Each layer has a precise responsibility, and each is independently deployable as an Erigon component. Together they deliver confidential, compliant, verifiable settlement for institutional finance.

The Four-Layer Stack

Everything inside the operator boundary stays within your infrastructure. Ethereum only ever receives state roots and ZK proofs — never raw transaction data, balances, or identity documents.

The Four Layers Explained

Token Layer

Tokenized assets — shares, bonds, fund units — are represented as ERC-3643 permissioned tokens. ERC-3643 extends the ERC-20 interface with compliance transfer hooks: every transfer is validated against the sender's and receiver's on-chain identity claims before it settles. Tokens are transparent to the operator and its compliance tools, but invisible to external parties.

Cash Layer

The cash leg of every settlement uses DBC (Digital Bearer Certificates) — a confidential cash instrument implemented with RingCT (Ring Confidential Transactions). RingCT uses Pedersen commitments to hide both the transfer amount and the sender's identity from all parties except those directly involved and the operator's compliance tooling. DBCs settle atomically with token transfers, eliminating the traditional gap between delivery and payment.

Proving Layer

The proving layer generates the cryptographic evidence that makes Cocoon's privacy model trustworthy without requiring counterparties to trust the operator.

• QMTree — a Merkle-tree based state commitment scheme that produces a compact root representing the entire chain state at each block.

• ZK provers — generate zero-knowledge proofs that a given state transition is valid, without revealing the underlying data.

• Verifier — validates proofs before they are accepted by the chain.

• Proof pipeline — orchestrates proof generation and batching for efficient Ethereum posting.

• Fraud proofs — allow any party with data access to challenge an incorrect state root, providing an additional security backstop.

State roots and proofs are posted to Ethereum at regular intervals, anchoring Cocoon's state to a public, neutral ledger.

Foundation Layer

The foundation layer provides the shared infrastructure every other component depends on.

• Identity (OnchainID / ERC-734/735) — on-chain identity contracts hold signed claims (KYC status, accreditation, jurisdiction) issued by trusted claim issuers. Supporting documents are encrypted and stored off-chain; only the claim hash lives on-chain.

• Auth (UCAN / EIP-8141) — capability-based authorization using UCAN (User Controlled Authorization Networks) with EIP-8141 Ethereum integration, enabling fine-grained, delegatable permissions without centralised session management.

• Storage (torrent-ccip / BitTorrent) — encrypted documents and large data objects are stored via a BitTorrent-based content-addressed store, referenced on-chain via torrent-ccip links. This keeps the chain lean while preserving data availability within the operator boundary.

• WebF (decentralized hosting) — a decentralised web-hosting layer that serves investor-facing interfaces directly from operator-controlled infrastructure, without dependency on centralised CDNs.

Privacy Model

Data	Who can see it	Where it lives
Token balances and transfers	Operator, compliance tooling, permissioned counterparties	Operator chain state
DBC cash amounts and senders	Operator compliance tooling only (via view keys)	Operator chain state, hidden via Pedersen commitments
Identity claims (KYC status, etc.)	Claim issuer, operator, claim subject	On-chain (claim hashes only)
Identity documents (passports, etc.)	Operator, claim issuer, subject — via selective disclosure	Encrypted off-chain storage
State roots	Anyone	Ethereum
ZK proofs of state validity	Anyone	Ethereum
Raw transaction data	No one outside operator infrastructure	Never leaves operator

Transaction Lifecycle

The following sequence traces a share purchase in the Tokenized MMF product: an investor submits a subscription, the compliance layer checks their eligibility, the token and cash legs settle atomically, and proof of settlement is anchored to Ethereum.

Step-by-step

1. Investor submits subscription. The investor sends a transaction containing a DBC note (a Pedersen-committed cash instrument representing their payment) and the requested token amount.

2. Token compliance check. The ERC-3643 token contract calls the Identity Registry to verify that the investor holds valid on-chain claims — KYC clearance, accreditation status, and permitted jurisdiction. The transfer is rejected at this step if any required claim is missing or expired.

3. DBC cash lock. The Cash Layer locks the investor's DBC note, cryptographically verifying that the committed amount matches the subscription value without revealing the amount to any party beyond the operator's compliance tooling.

4. Atomic settlement. The token contract mints fund tokens to the investor and simultaneously releases the locked DBC cash to the fund operator. Both legs settle in the same transaction — there is no delivery-versus-payment gap.

5. ZK proof generation. The Proving Layer's proof pipeline takes the resulting state transition and generates a zero-knowledge proof that the transition was executed correctly according to the chain's rules.

6. Ethereum anchoring. The state root and ZK proof are posted to Ethereum. From this point, any party can verify that settlement occurred correctly by checking the proof, without seeing any transaction data.

Component Deployability

Each component listed above maps to a discrete Erigon component module. Operators can enable only the components their use case requires — for example, a payments deployment may omit the token layer entirely and run only the Cash, Proving, and Foundation components. Component configuration is managed via the operator configuration file; see the Operator Guide for details.