# 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.

{% hint style="info" %}
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.
{% endhint %}

## 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.

```mermaid
graph TD
    subgraph Token["Token Layer"]
        PT["Permissioned Tokens"]
    end
    subgraph Cash["Cash Layer"]
        CC["Confidential Cash (DBC)"]
    end
    subgraph Proving["Proving Layer"]
        ZK["ZK Proving"]
        FD["Fraud Detection"]
    end
    subgraph Foundation["Foundation Layer"]
        ID["Identity"]
        AZ["Authorization"]
        DS["Data Storage"]
        WH["Web Hosting"]
    end

    PT --> CC
    PT --> ID
    PT --> AZ
    PT --> DS
    CC --> ZK
    CC --> ID
    CC --> AZ
    ZK --> Foundation
    FD --> Foundation
```

| 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

<table data-view="cards"><thead><tr><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Permissioned Tokens</strong><br>ERC-3643 compliant regulated assets with built-in compliance, distribution, and DVP settlement.</td><td><a href="/pages/Lp4GCWchUaveBrb0n6E4">/pages/Lp4GCWchUaveBrb0n6E4</a></td></tr><tr><td><strong>Confidential Cash (DBC)</strong><br>RingCT-based digital bearer certificates that hide amounts and counterparties on-chain.</td><td><a href="/pages/PhzsfKAOdDQZPCSxeCjf">/pages/PhzsfKAOdDQZPCSxeCjf</a></td></tr><tr><td><strong>ZK Proving</strong><br>On-demand zero-knowledge proof generation and verification for compliance and privacy.</td><td><a href="/pages/0V1yxifVnYz1qlMHGeDX">/pages/0V1yxifVnYz1qlMHGeDX</a></td></tr><tr><td><strong>Fraud Detection</strong><br>Real-time anomaly detection and rule-based alerting across all on-chain activity.</td><td><a href="https://github.com/erigontech/cocoon/blob/master/docs/platform/components/fraud-detection.md">https://github.com/erigontech/cocoon/blob/master/docs/platform/components/fraud-detection.md</a></td></tr><tr><td><strong>Identity</strong><br>OnchainID (ERC-734/735) with selective disclosure, encrypted document storage, and DID bridging.</td><td><a href="/pages/iNxMIiArUZEgezpvRDeZ">/pages/iNxMIiArUZEgezpvRDeZ</a></td></tr><tr><td><strong>Authorization</strong><br>UCAN capability-based access control enforced across RPC, contracts, and storage.</td><td><a href="/pages/iDWImRaJhGj0drnLxnC2">/pages/iDWImRaJhGj0drnLxnC2</a></td></tr><tr><td><strong>Data Storage</strong><br>Encrypted off-chain document storage via torrent-ccip with on-chain content addressing.</td><td><a href="/pages/xObhrrnenFKG563jUTxI">/pages/xObhrrnenFKG563jUTxI</a></td></tr><tr><td><strong>Web Hosting</strong><br>Decentralized front-end hosting for investor portals and issuer dashboards.</td><td><a href="/pages/RoCRgavSPaNSPxOT8l6M">/pages/RoCRgavSPaNSPxOT8l6M</a></td></tr></tbody></table>

## 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://cocoon.erigon.tech/components/components.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.