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

# Node operators

> What a Whitechain RPC node is, how it follows the canonical L2 chain, the available node profiles, and what the node does and does not provide.

Run an external Whitechain RPC node that follows the canonical L2 chain. A node is a pair of services: `op-reth` (execution client, JSON-RPC and WebSocket) and `op-node` (consensus client, derives the chain from L1 and peers over libp2p). This section is for teams that want their own RPC endpoint, an indexer or explorer backend, or a private node instead of the public RPC.

<Note>
  Available on Testnet today; Mainnet at launch.
</Note>

## How it works

The Whitechain sequencer is closed and is not reachable from the public internet. Your node never needs access to it. Instead, the node:

1. Reads L1 batches from your own Ethereum L1 RPC and Beacon endpoints.
2. Pulls unsafe blocks from the network over libp2p.
3. Forwards `eth_sendRawTransaction` calls to the public Whitechain RPC, which routes them to the sequencer.

<Note>
  This stack holds no project-side private keys. The sequencer, batcher, proposer, and challenger keys stay on the Whitechain side. You operate a follow-only node.
</Note>

## Concepts: storage vs. sync method

A node is defined by two independent choices. Each node profile is a fixed combination of them.

**Storage**: how much state `op-reth` keeps:

* **Pruned** (`--full`): keeps only recent state, prunes history. Smallest disk footprint. Serves a complete public RPC for current data.
* **Archive** (no `--full`): keeps the full historical state. Largest disk footprint. Required for historical tracing and `eth_call` at old blocks.

**Sync method**: how `op-reth` obtains that state:

* **consensus-layer** (the `op-node` default): `op-node` derives the chain from L1 and feeds blocks to `op-reth` one by one; `op-reth` re-executes every transaction from genesis. No EL P2P peer needed, but the initial sync is long unless you restore a snapshot.
* **execution-layer** (`--syncmode=execution-layer`, "snap"): `op-node` only drives the head; `op-reth` snap-syncs the state directly from a trusted reth peer over EL P2P. Fast, no snapshot restore needed, but it requires a reachable seed peer (`WHITECHAIN_RETH_TRUSTED_PEERS`). Snap sync cannot build archive state, only pruned.

| Storage           | consensus-layer (re-execute) | execution-layer (snap) |
| ----------------- | ---------------------------- | ---------------------- |
| Pruned (`--full`) | `full-node`                  | `full-snap-node`       |
| Archive           | `archive-node`               | Not supported          |

## Node profiles

The stack ships three profiles. Pick one with `PROFILE=<profile>` or a per-profile `make` target.

| Profile          | Use it for                                             | Storage           | Sync method            | Snapshot    | Public RPC |
| ---------------- | ------------------------------------------------------ | ----------------- | ---------------------- | ----------- | ---------- |
| `full-snap-node` | Recommended default, fastest and simplest to bootstrap | Pruned (`--full`) | execution-layer (snap) | Not needed  | Yes        |
| `full-node`      | Public RPC without a snap-sync peer                    | Pruned (`--full`) | consensus-layer        | Recommended | Yes        |
| `archive-node`   | Explorers, indexers, historical tracing                | Full history      | consensus-layer        | Recommended | Yes        |

`full-snap-node` is the recommended default: pruned execution state and the basic RPC namespaces (`eth`, `net`, `web3`, `rpc`). It bootstraps by snap-syncing from a trusted reth peer (`WHITECHAIN_RETH_TRUSTED_PEERS`) instead of re-executing the chain, so it needs no snapshot. Use it when you have a reachable seed reth enode. `full-node` keeps the same pruned state and namespaces but syncs in consensus-layer mode, re-executing the chain from L1. Use it when you have no trusted peer to snap-sync from, and restore a snapshot to avoid a long initial sync. `archive-node` keeps the full historical state and adds the `debug`, `trace`, `txpool`, and `reth` namespaces, so it is required for historical `eth_call`, `debug_traceTransaction`, and log-heavy indexing. Archive cannot snap-sync, so it always re-executes from L1. Restore a snapshot to avoid a very long initial sync. It needs the most disk and RAM.

## Available RPC namespaces

`op-reth` namespaces depend on the profile:

| Profile                        | HTTP                                                            | WebSocket                   |
| ------------------------------ | --------------------------------------------------------------- | --------------------------- |
| `full-snap-node` / `full-node` | `eth`, `net`, `web3`, `rpc`                                     | `eth`, `net`, `web3`, `rpc` |
| `archive-node`                 | `eth`, `net`, `web3`, `rpc`, `debug`, `trace`, `txpool`, `reth` | `eth`, `net`, `web3`, `rpc` |

`op-reth` exposes no `admin` namespace on any profile.

`op-node` exposes an RPC on port `9545`, bound to loopback (`127.0.0.1`) only on every profile, reachable for local monitoring on the host, never from the network:

| Namespace   | Description                                                                |
| ----------- | -------------------------------------------------------------------------- |
| `optimism`  | Rollup state, including `optimism_syncStatus` and `optimism_outputAtBlock` |
| `superroot` | Read-only super-root status methods                                        |
| `opp2p`     | P2P peer information, including `opp2p_self` and `opp2p_peers`             |

The `admin` namespace is not enabled on `op-node` either, so no profile exposes administrative or state-mutating methods.

## Sending transactions

Applications submit transactions to your local `op-reth` HTTP port. The node forwards them to `WHITECHAIN_PUBLIC_RPC`, which routes them to the sequencer. You need no direct access to the sequencer.

```bash theme={null}
curl -s -X POST http://127.0.0.1:8545 \
  -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params":["0x..."],"id":1}'
```

<Note>
  If you restart your node, in-flight transactions remain in the public RPC mempool, not in your local node.
</Note>

## What this node does not provide

This is a follow-only RPC node. It does not include block builder or sequencer roles, the batcher, proposer, or challenger, or the Flashblocks pre-confirmation stream.

If your application needs sub-second pre-confirmations, contact the Whitechain team for the Flashblocks WebSocket URL. The `public-rpc-node` stack does not subscribe to the Flashblocks stream.

## Related

* [Run a node](/operate/run-a-node/run-a-node)
* [Node configuration](/operate/run-a-node/configuration)
* [Node maintenance](/operate/run-a-node/maintenance)
* [Troubleshooting](/operate/run-a-node/troubleshooting)
* [Testnet](/learn/network/testnet)
* [Network reference](/learn/network/reference)