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

# Supported chains overview

> At-a-glance matrix of chains, networks, clients, and node types Novacula supports

Novacula supports seven blockchains today. This page is the at-a-glance matrix; each per-chain page covers ports, defaults, and the config you can override in detail.

When you deploy, the wizard offers only what your chosen executor declares — its chains, networks, clients, and versions. This matrix is the full set across all executors; the live options for a given deploy are the intersection with that [executor's capabilities](/docs/executors/overview).

## Matrix

| Chain        | Networks                     | Roles                             | Clients                                       | Node types   | Per-chain page                    |
| ------------ | ---------------------------- | --------------------------------- | --------------------------------------------- | ------------ | --------------------------------- |
| **Bitcoin**  | `mainnet`, `signet`          | `node`                            | `bitcoind`                                    | Full, Pruned | [Bitcoin](/docs/chains/bitcoin)   |
| **BSC**      | `mainnet`, `chapel`          | `node`                            | `geth`                                        | Full, Pruned | [BSC](/docs/chains/bsc)           |
| **Ethereum** | `mainnet`, `sepolia`         | `el` + `cl`                       | EL: `geth`<br />CL: `lighthouse`              | Full         | [Ethereum](/docs/chains/ethereum) |
| **Igra**     | `mainnet`, `galleon-testnet` | `kaspad` + `el`                   | `kaspad` · `igra-reth`                        | Full         | [Igra](/docs/chains/igra)         |
| **Ink**      | `mainnet`                    | `el` + `rollup`                   | `op-reth` · `op-node`                         | Full         | [Ink](/docs/chains/ink)           |
| **Monad**    | `mainnet`, `testnet`         | `consensus` + `execution` + `rpc` | `monad-bft` · `monad-execution` · `monad-rpc` | Full         | [Monad](/docs/chains/monad)       |
| **Tron**     | `mainnet`, `nile`            | `node`                            | `java-tron`                                   | Full         | [Tron](/docs/chains/tron)         |

Most chains offer **Full** only. **Bitcoin** and **BSC** also offer **Pruned**, which trims disk by dropping old block history at the cost of not serving the full history.

A multi-role chain runs more than one process per node — Ethereum runs an execution client (`el`) plus a consensus client (`cl`); Igra runs a `kaspad` node plus an `igra-reth` execution layer; Ink runs an `op-reth` execution layer plus an `op-node` rollup client; Monad runs three. Each role is a separate process (Agent) or container (Operator) with its own resources, and you pick its client and version independently in the wizard.

Ink is **Kubernetes-only** — deploy it through an Operator executor; it isn't offered for bare-metal Agents.

## Resource defaults

The deploy wizard pre-fills the resource form with per-network, per-client defaults sized for a fresh sync. You can change them; if your selection exceeds the executor host's available capacity, the wizard shows a non-blocking warning. The numbers below are for **Full** nodes.

For single-process chains the defaults are fixed per network:

| Chain × network | CPU      | RAM    | Disk     |
| --------------- | -------- | ------ | -------- |
| Bitcoin mainnet | 2 cores  | 4 GiB  | 1200 GiB |
| Bitcoin signet  | 1 core   | 4 GiB  | 100 GiB  |
| BSC mainnet     | 16 cores | 64 GiB | 7 TiB    |
| BSC chapel      | 8 cores  | 32 GiB | 1 TiB    |
| Tron mainnet    | 16 cores | 32 GiB | 4500 GiB |
| Tron nile       | 8 cores  | 16 GiB | 300 GiB  |

Disk above is for **Full** nodes; **Bitcoin Pruned** and **BSC Pruned** trim the disk request (see their per-chain pages).

For multi-role chains — **Ethereum**, **Igra**, **Ink**, and **Monad** — each role is sized separately, and the total is the sum of its roles' requests. The wizard shows the live numbers for your exact selection as you choose clients, so deploy there to see the current defaults.

## What every chain shares

Whatever client you choose, these conventions hold:

* **Outbound only.** No inbound ports need exposing for the platform to manage your node. You can still choose to expose RPC for your own use.
* **One data directory per node.** Config and data live under a single mount (Operator: one volume; Agent: a subdirectory under `data_dir`). Monad is the partial exception — its triedb lives on its own volume.
* **Setup is handled for you.** JWT secret generation (Ethereum, Igra), snapshot bootstraps where a chain supports them, and checkpoint sync URLs (Ethereum consensus client) all run as part of node startup — they aren't config you maintain.
* **Guarded overrides.** Each chain marks some settings as managed (rejected if you try to change them, because the platform owns them) and exposes the rest as typed, described keys with hints in the UI. See [Edit node configuration](/docs/nodes/edit-configuration).

## Adding chain support

New chains arrive in executor releases. Once an executor runs a release that includes a chain, it declares that chain in its capabilities and the deploy wizard offers it automatically — nothing changes on your account, and there's no setup on your side. To pick up a newly supported chain, [upgrade the executor](/docs/executors/upgrade-executor).
