Components
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 Proofs | 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 regulated asset issuance with compliance transfer hooks.
- Confidential Cash (DBC) — RingCT-based Digital Bearer Certificates for private on-chain value transfer.
- Identity — OnchainID on-chain identity infrastructure (ERC-734 keys, ERC-735 claims).
- Authorization — UCAN capability-based delegation in place of traditional RBAC.
- Data Storage — torrent-ccip decentralized, encrypted, access-controlled storage.
- ZK Proving — QMTree state commitments with two-tier proof model for L1 settlement.
- Fraud Proofs — bisection-protocol challenge mechanism for the optimistic rollup.
- Web Hosting — operator-served front-end pattern with chain-tied site identity.
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.