Glossary
Definitions for terminology used throughout the Cocoon platform documentation. Terms are listed alphabetically within thematic groups.
Core Platform Concepts
Compliance Module
A pluggable smart contract that is called by the ERC-3643 token engine on every transfer. A module can inspect the sender, receiver, amount, and any associated identity claims, then either approve the transfer, block it, or modify its parameters. Common built-in modules enforce country allow-lists, maximum balance limits, and holding period restrictions. Operators can deploy custom modules implementing the IComplianceModule interface.
DBC (Digital Bearer Certificates)
Cocoon's confidential cash instrument. A DBC is a cryptographic token representing a fixed denomination of value (analogous to a banknote) that can be transferred without revealing its amount or the identity of its holder to outside observers. DBCs use RingCT for transfer confidentiality and are the cash leg of every atomic settlement on Cocoon. Unlike account-based stablecoins, DBCs are bearer instruments: possession of the key image constitutes ownership.
DVP (Delivery versus Payment)
A settlement principle requiring that the transfer of an asset (delivery) and the transfer of cash (payment) happen simultaneously and atomically — neither leg completes unless both do. On Cocoon, DVP is enforced at the protocol level: a token transfer and the corresponding DBC cash transfer are bundled in a single transaction and either both commit or both revert. This eliminates the settlement risk inherent in sequential delivery and payment.
ERC-3643 / T-REX
An Ethereum token standard for permissioned, compliance-enforced security tokens. ERC-3643 extends ERC-20 with mandatory transfer checks delegated to a pluggable compliance contract, and ties each token holder to an on-chain identity (see OnchainID). Every transfer calls the compliance contract before executing; if the compliance contract rejects the transfer, the transaction reverts. T-REX (Token for Regulated EXchanges) is the original industry name for the framework that was standardised as ERC-3643.
NAV (Net Asset Value)
The per-share value of a fund token, calculated as the total value of the fund's assets divided by the number of outstanding shares. On Cocoon, NAV is published on-chain via token_publishNAV and used by the subscription and redemption functions to convert between stablecoin amounts and token shares. NAV publication is the responsibility of the fund operator (typically the fund administrator or a licensed price provider).
Permissioned Validium
Cocoon's overall privacy architecture. A Validium is a layer-2 design where transaction data is kept off the main chain (unlike a ZK-Rollup, which posts compressed data on-chain) and validity is asserted via ZK proofs. Cocoon is permissioned because access to the chain is restricted to vetted operators and investors, rather than being open to the public. The combination of off-chain data and on-chain proofs gives Cocoon institutional-grade privacy without sacrificing cryptographic verifiability.
Proof-of-Execution
A ZK proof demonstrating that a specific contract call or state transition was computed correctly, without revealing the inputs. Cocoon generates proofs-of-execution for each batch of blocks. These proofs are posted to Ethereum, allowing any external party to verify that the operator's chain state is correct without having access to the underlying transaction data.
Pre-proof vs ZK Full Proof
Cocoon operates in two modes for different block ranges:
Pre-proof (optimistic): Blocks are accepted immediately and state roots are posted to Ethereum with a fraud-proof window. Any party with data access can submit a fraud proof during this window to challenge an incorrect state root. Faster and cheaper.
ZK full proof: A zero-knowledge proof is generated for the block batch and verified on Ethereum. Once the proof is accepted, the state is final and cannot be challenged. Higher computational cost; used for final settlement and regulatory anchoring.
Cryptographic Primitives
Key Image
A deterministic value derived from a private key and the public key of a DBC output being spent. The key image is unique to the combination of key and output — it is posted on-chain when a DBC is spent, allowing the chain to detect double-spends without revealing which output was spent or who spent it. The SpentBook is the on-chain set of all key images that have been used.
ML-KEM (Post-Quantum Key Encapsulation)
Module Lattice-based Key Encapsulation Mechanism (NIST FIPS 203). Cocoon uses ML-KEM to encrypt DBC output amounts and recipient keys in a way that is secure against quantum computers. ML-KEM replaces ECDH in the DBC encryption layer, ensuring that harvested ciphertexts cannot be retroactively decrypted by a quantum adversary.
MLSAG Ring Signature
Multilayered Linkable Spontaneous Anonymous Group signature — the signing scheme used in RingCT. An MLSAG signature proves that the signer is a member of a ring of public keys without revealing which member signed. In Cocoon's DBC layer, the ring includes the actual sender along with decoy public keys drawn from the UTXO set. This provides sender anonymity within the operator's transaction set.
Pedersen Commitment
A cryptographic commitment scheme of the form C = vG + rH, where v is the value being hidden, r is a random blinding factor, and G, H are independent curve generators. Pedersen commitments are homomorphic: C(a) + C(b) = C(a + b). Cocoon's RingCT layer uses Pedersen commitments to hide DBC transfer amounts while allowing the chain to verify that input values equal output values (no inflation).
Selective Disclosure
The ability to reveal specific claims or attributes from an identity without revealing the complete identity record. On Cocoon, selective disclosure is implemented by storing claim documents encrypted on the torrent layer and sharing only the symmetric decryption key with the requesting party via id_grantClaimAccess. A regulator can be granted access to a specific document (e.g. a KYC report) without being able to read other documents or claims associated with the same identity.
Stealth Address
A one-time address derived from a recipient's public key, used so that an outside observer cannot link multiple DBC outputs to the same recipient. The sender computes a fresh stealth address for each transfer; only the recipient (who holds the corresponding private key) can detect and spend outputs sent to their stealth addresses by scanning the chain.
State and Proving Architecture
QMTree
The Quadratic Merkle Tree — Cocoon's state commitment scheme. QMTree is a binary Merkle tree over the chain's key-value state, designed to produce compact roots and efficient inclusion/exclusion proofs. The QMTree root at each block is the input to the ZK proof circuit. The qm_ RPC namespace exposes the tree's contents and allows callers to generate and verify inclusion proofs without running a full node.
SpentBook
The on-chain registry of all key images that have been spent in DBC transfers. When a DBC output is redeemed, its key image is appended to the SpentBook. Before accepting a new DBC transaction, the chain checks that none of the input key images are already in the SpentBook. This prevents double-spending without revealing which specific outputs were spent.
StorageSink
The abstraction layer in Erigon that routes state writes to the appropriate backend (disk, memory, or a distributed key-value store). The StorageSink is also responsible for feeding the QMTree: every state write is mirrored into the Merkle tree so that the tree root always reflects the current chain state.
Twig
A sub-tree within the QMTree. The full QMTree is partitioned into fixed-size twigs; each twig covers a contiguous range of key space. Proofs reference the twig root as an intermediate node, making proof generation and verification more efficient for large state sizes. The twig structure also enables parallel proof generation across independent key ranges.
txNum
A globally unique, monotonically increasing transaction counter assigned to every transaction on the Cocoon chain. Unlike block-scoped transaction indices, txNum is chain-global, making it suitable as a stable key for proof circuits and audit records. The QMTree uses txNum as the primary ordering key for state changes.
Identity and Authorization
did:key / did:pkh
Two DID (Decentralized Identifier) methods used in Cocoon's UCAN layer:
did:key — a DID derived directly from a cryptographic public key, with no on-chain registration required. Format:
did:key:z...(multibase-encoded public key).did:pkh — a DID derived from a blockchain account address. Format:
did:pkh:eip155:33:0x...(CAIP-10 account identifier). Cocoon usesdid:pkhto bind UCAN capabilities to Ethereum wallet addresses.
OnchainID / ERC-734 / ERC-735
The on-chain identity standard used by Cocoon's identity layer:
ERC-734 defines the key management interface for identity contracts: management keys, action keys, and claim-signer keys, each with different permission levels.
ERC-735 defines the claims interface: how claims (signed attestations from trusted issuers) are attached to, retrieved from, and removed from identity contracts.
OnchainID is the reference implementation of ERC-734/735, widely used in the ERC-3643 ecosystem.
UCAN (User Controlled Authorization Networks)
A capability-based authorization framework using signed JWTs. A UCAN delegation grants an audience DID the ability to perform specified capabilities on behalf of an issuer DID, optionally with time limits and attenuation constraints. UCAN delegations are chainable: the audience can re-delegate a subset of capabilities to a further audience, forming a delegation chain. Cocoon uses UCAN to implement fine-grained, delegatable permissions for token operations without centralised session management.
Cross-Chain and Interoperability
EIP-8141 / Frame Transactions
EIP-8141 defines frame transactions — a new Ethereum transaction envelope type that embeds arbitrary structured payloads (frames) alongside the standard EVM call. Cocoon uses frame transactions to attach UCAN delegation proofs, encrypted DBC keys, and torrent-ccip content references to transactions without polluting the EVM calldata. The auth_ component processes the UCAN frames; the DBC layer processes the key frames.
torrent-ccip / CCIP-Read / CCIP-Write
Cocoon's off-chain data availability layer:
CCIP-Read (EIP-3668) — a standard for resolving off-chain data on-demand. When an on-chain function cannot find data, it reverts with a
OffchainLookuperror containing a gateway URL. The client fetches the data from the gateway and re-submits the call with the result.CCIP-Write — an extension of CCIP-Read for writing data off-chain and writing only the content hash on-chain.
torrent-ccip — Cocoon's implementation of CCIP-Read/Write using BitTorrent as the data store. Documents are seeded as torrents; their info hashes are stored on-chain; CCIP-Read gateways resolve the hashes to download URLs. This keeps the chain lean while maintaining data availability within the operator boundary.
Prover Infrastructure
ProverBackend / VerifierBackend
Pluggable interfaces for ZK proof generation and verification. The default backend is Zilkworm. Alternative backends (sp1, risc0) can be selected via the PROVER_BACKEND environment variable. The VerifierBackend must match the ProverBackend: a proof generated by Zilkworm cannot be verified by the SP1 verifier.
Zilkworm
Cocoon's default ZK prover backend. Zilkworm is a Rust-based proving library optimised for the Cocoon state transition circuit. It generates proofs significantly faster than general-purpose SNARK frameworks for the specific computations Cocoon requires (QMTree updates, RingCT balance checks, compliance hook execution). Zilkworm proofs are succinct enough to be posted and verified on Ethereum within a standard block gas limit.
Storage and Web
WebF
Cocoon's on-chain web hosting layer. WebF allows operators to publish static web sites (HTML, CSS, JavaScript, media) by storing files in the torrent layer and writing a content root on-chain. The WebF gateway serves the site by resolving the on-chain root to the torrent info hash and streaming file content to the browser. Sites are referenced by their on-chain site ID and are immutable — publishing an update creates a new site version.
Last updated