Introduction

The Cocoon Platform is built from eight independently composable components, each running as a service inside an Erigon node. You can enable only the components your deployment needs — a token-only setup has no dependency on the cash layer, and identity can run standalone for use cases that require only KYC infrastructure. All components share a common event bus and a standard service lifecycle, so adding or removing a component at runtime requires no code changes elsewhere.

Every component follows the same lifecycle: Configure → Initialize → Recover → Activate → Deactivate. State transitions are logged to the event bus so dependent components can react without tight coupling.

Component Stack

The eight components are organized into four layers. Upper layers depend on lower layers, but components within a layer are independent of one another.

Layer	Components	Role
Token	Permissioned Tokens	Regulated asset issuance, compliance, distribution
Cash	Confidential Cash (DBC)	Private on-chain settlement
Proving	ZK Proving, Fraud Detection	Cryptographic validity and integrity guarantees
Foundation	Identity, Authorization, Data Storage, Web Hosting	Shared infrastructure consumed by all upper layers

Component Pages

Permissioned Tokens ERC-3643 compliant regulated assets with built-in compliance, distribution, and DVP settlement.

Confidential Cash (DBC) RingCT-based digital bearer certificates that hide amounts and counterparties on-chain.

ZK Proving On-demand zero-knowledge proof generation and verification for compliance and privacy.

Fraud Detection Real-time anomaly detection and rule-based alerting across all on-chain activity.

Identity OnchainID (ERC-734/735) with selective disclosure, encrypted document storage, and DID bridging.

Authorization UCAN capability-based access control enforced across RPC, contracts, and storage.

Data Storage Encrypted off-chain document storage via torrent-ccip with on-chain content addressing.

Web Hosting Decentralized front-end hosting for investor portals and issuer dashboards.

Event Bus and Inter-Component Communication

Components do not call each other directly. All cross-component communication goes through a typed event bus embedded in the node process. When Identity verifies an investor, it emits an identity.verified event. When Permissioned Tokens needs to validate a transfer, it subscribes to the response from Identity rather than calling an Identity API synchronously.

This design means:

• Composability: remove a component and its consumers degrade gracefully rather than hard-failing.

• Observability: every inter-component interaction is a named event that can be logged, replayed, or intercepted.

• Testability: components can be tested in isolation by injecting mock events.

Standard Service Lifecycle

All eight components implement the same five lifecycle hooks, which the node runtime calls in order:

Phase	Description
Configure	Load configuration from environment and config file; validate required parameters.
Initialize	Deploy or connect to on-chain contracts; set up local state and indexes.
Recover	Re-sync from chain state after a restart; replay any missed events.
Activate	Begin serving RPC requests and emitting events.
Deactivate	Drain in-flight requests, flush state, and shut down cleanly.

The lifecycle is idempotent: calling Initialize twice on an already-initialized component is a no-op. This makes it safe to restart individual components without affecting others.