Skip to main content
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.
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). Robinhood Chain runs either way on a bare-metal Agent — as systemd services or as Docker containers — and as pods on a Kubernetes Operator 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.

​
Networks and resources

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: These disk figures move when the snapshot is refreshed — the wizard shows the current value.

​
Clients

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

​
Ports

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); 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.
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.

​
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 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; 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