> ## Documentation Index
> Fetch the complete documentation index at: https://docs.novacula.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Gnosis

> Two-role (EL + CL) Gnosis Chain nodes — Reth × Lighthouse, container-only

Gnosis Chain is an EVM chain with the same post-merge shape as Ethereum. Every Gnosis node is two roles: an **execution-layer (EL)** client and a **consensus-layer (CL)** client, deployed and managed together. They talk over the JWT-authenticated Engine API, which Novacula sets up and secures for you; the node page shows them as two roles.

Gnosis is a **container-only** chain — both of its clients ship as images rather than binaries, so both roles always run as containers:

* On a [Kubernetes Operator](/recipes/provision-on-kubernetes) executor, as pods in the cluster, like every other chain.
* On a [bare-metal Agent](/recipes/provision-on-bare-metal) executor, as Docker containers on the host rather than as `systemd` services.

<Note>
  Deploying onto an Agent, the wizard's **Runtime** field locks itself to **Docker** — Gnosis's only valid runtime — so there's nothing to choose. On an Agent Novacula installs the Docker engine for you before the node's first launch, the same way it does for [Igra](/docs/chains/igra). See [Runtime](/docs/nodes/deploy-a-node#runtime-agent-only).
</Note>

To deploy, open **Deploy Node**, pick **Gnosis**, then choose a network. The wizard offers exactly the networks, clients, and versions your target executor declares.

## Networks

| Network   | Type       |
| --------- | ---------- |
| `mainnet` | Production |
| `chiado`  | Testnet    |

Gnosis nodes run as **Full** nodes.

## Clients

One client per role today: **Reth** (the Gnosis build, `gnosis-reth`) as the EL and **Lighthouse** (`gnosis-lighthouse`) as the CL.

| Role   | Client              | Versions |
| ------ | ------------------- | -------- |
| **EL** | `gnosis-reth`       | `2.0.0`  |
| **CL** | `gnosis-lighthouse` | `8.2.1`  |

## Resources

Defaults are set per client and per network; the node's footprint is the EL client plus the CL client. The wizard pre-fills these and lets you adjust CPU and memory before deploying.

| Role / client          | `mainnet` CPU / RAM | `mainnet` disk | `chiado` CPU / RAM | `chiado` disk |
| ---------------------- | ------------------- | -------------- | ------------------ | ------------- |
| EL `gnosis-reth`       | 4 cores / 40 GiB    | 1024 GiB       | 2 cores / 4 GiB    | 256 GiB       |
| CL `gnosis-lighthouse` | 2 cores / 12 GiB    | 500 GiB        | 1 core / 4 GiB     | 100 GiB       |

## Ports

| Name          | Port   | Role |
| ------------- | ------ | ---- |
| EL RPC (HTTP) | `8545` | EL   |
| CL beacon API | `5052` | CL   |

These are the endpoints you consume: JSON-RPC on `:8545` from the EL (the `eth` and `net` namespaces) and the beacon API on `:5052` from the CL. The Engine API the two roles use to talk to each other is internal and managed by Novacula. In a [pool](/docs/nodes/pools), the EL JSON-RPC is the role the pool serves.

## Sync

* **Snapshot bootstrap (EL)** — before its first start, a fresh Reth downloads a recent full-node snapshot into its data directory, so it starts from recent chain data instead of syncing from genesis. The node reads **Downloading snapshot** while it runs, on an Agent and an Operator alike; an interrupted download resumes where it left off. See [Snapshot bootstrap](/docs/nodes/node-lifecycle#snapshot-bootstrap).
* **Checkpoint sync (CL)** — always on, managed automatically. Lighthouse fetches a recent finalized state from a public Gnosis checkpoint provider; Novacula keeps more than one per network in preference order.

## Configuration

Gnosis runs with a managed, network-pinned configuration — there are no client config overrides to set when you deploy. Novacula writes the data directories, ports, Engine API, JWT, and metrics settings for you.

## Monitoring

The node page shows per-role status, sync progress, peers, CPU, memory, and disk for both the EL and CL — see [Node monitoring](/docs/nodes/monitoring). While Reth is still backfilling, its sync progress is read from its pipeline stages rather than from `eth_syncing`, which can report 100% before the pipeline has finished; block height follows the same reading until the RPC serves a real height.

## What you can build

* **RPC provider** — the Reth EL paired with the Lighthouse CL, serving JSON-RPC on `:8545`, on its own or behind a [pool](/docs/nodes/pools).
* **Beacon endpoint for an external validator** — run the EL + CL pair, then point a separately-operated validator client at the CL beacon API on `:5052`. Novacula runs the node beneath your validator; it does not manage the validator client itself.

## Where to next

* [Deploy a node](/docs/nodes/deploy-a-node)
* [Provision on Kubernetes](/recipes/provision-on-kubernetes) · [Provision on bare metal](/recipes/provision-on-bare-metal)