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

# Robinhood Chain

> Single-process Nitro L2 anchored on Ethereum, with required L1 endpoints

<Note>
  Robinhood Chain needs an **x86\_64** host on a bare-metal Agent — an Agent on an arm64 host doesn't advertise it, so the wizard won't offer it for that executor. Operators aren't affected.
</Note>

Robinhood Chain is a Nitro L2 anchored on Ethereum. A node runs a single **nitro** process that derives the L2 from Ethereum L1. The sequencer, the feed endpoint, and P2P are baked in per network, but the **L1 endpoints** Nitro reads from are **yours to provide** (see [L1 endpoints](#l1-endpoints-required)).

Robinhood Chain runs either way on a bare-metal Agent — as `systemd` services or as Docker containers — and as pods on a [Kubernetes Operator](/recipes/provision-on-kubernetes) executor. The client ships as a binary and as an image, so you pick the **Runtime** in the wizard's **Target** step (defaults to **Systemd**). See [Runtime](/docs/nodes/deploy-a-node#runtime-agent-only).

## Networks and resources

| Network   | Sequencer                                       | Parent chain       |
| --------- | ----------------------------------------------- | ------------------ |
| `testnet` | `https://sequencer.testnet.chain.robinhood.com` | Ethereum `sepolia` |

The deploy wizard pre-fills **8 CPU / 64Gi** for the nitro process on either node type; the disk default is sized from the current snapshot of that node type:

| Node type | Disk   |
| --------- | ------ |
| Full      | 650Gi  |
| Archive   | 9150Gi |

These disk figures move when the snapshot is refreshed — the wizard shows the current value.

## Clients

| Role   | Client    | Versions         |
| ------ | --------- | ---------------- |
| `main` | **nitro** | `3.11.3-beb2108` |

One pinned client today. The deploy wizard offers exactly the client and version the executor declares.

## Ports

| Name            | Port   | Notes                        |
| --------------- | ------ | ---------------------------- |
| RPC (HTTP)      | `8547` | JSON-RPC                     |
| RPC (WebSocket) | `8548` | Optional, private by default |
| Metrics         | `6070` | Prometheus exporter          |

Ports are managed for you and aren't user-overridable.

## Node types

Robinhood Chain offers **Full** and **Archive**. Both bootstrap from a snapshot rather than syncing from genesis (see [Snapshot bootstrap](#snapshot-bootstrap)); **Archive** keeps all historical state and is heaviest on disk. The node type is fixed for the life of the node.

## L1 endpoints (required)

Nitro derives the L2 chain from Ethereum L1 — it does **not** sync purely from L2 peers, and Novacula supplies **no public L1 fallback**. A Robinhood Chain node needs two L1 endpoints:

* **Ethereum execution RPC** (`l1`) — the L1 blocks Nitro reads.
* **Ethereum beacon REST** (`l1beacon`) — the L1 consensus data, including blob data.

Robinhood `testnet` reads Ethereum `sepolia`. You supply both in the deploy wizard's **Connections** step, and change them later on the node's **Connections** tab. In this release the L1 endpoints are entered as **external URLs** — each must work without a password or API key. The beacon endpoint must come from a consensus client that keeps every blob — on Lighthouse that's `--supernode` or `--semi-supernode`; a beacon node running without one of them can't feed the L2. An Ethereum node you deploy on Novacula gets that flag when you pick the `blob-serving` node type in the wizard; expose its execution RPC and beacon API (without RPC-key auth) and enter those URLs. See [Connections](/docs/nodes/deploy-a-node#connections).

<Warning>
  A Robinhood Chain node is only as reliable as the L1 behind it. If Nitro stops making progress, the L1 endpoints are the first thing to suspect. Prefer an Ethereum node you control over a shared public endpoint for a production node.
</Warning>

## Snapshot bootstrap

On the first deploy, the node seeds from a recent snapshot instead of syncing block-by-block, which cuts sync time. The archive it pulls depends on the [node type](#node-types) you chose. The download runs once per data directory, so a node whose data directory has already been bootstrapped skips the step.

## Monitoring

Block height, sync progress, and disk are surfaced in the node view — see [Node monitoring](/docs/nodes/monitoring); Nitro reports no peer count. The node's **Overview** tab shows each observed L1 endpoint — its URL, its last check time, and its sync percentage, height, and lag when the upstream reports them. The **Connections** tab is where you change the endpoints.

## Where to next

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