> ## Documentation Index
> Fetch the complete documentation index at: https://docs.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 on a chain with history behind it.
* **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, 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 | Initial sync | Public RPC |
| - | - | - | - | - | - |
| `full-snap-node` | Recommended default, fastest and simplest to bootstrap | Pruned (`--full`) | execution-layer (snap) | Fast, snap-syncs from the trusted peer | Yes |
| `full-node` | Public RPC without a snap-sync peer | Pruned (`--full`) | consensus-layer | Long, re-executes from genesis | Yes |
| `archive-node` | Explorers, indexers, historical tracing | Full history | consensus-layer | Longest, re-executes from genesis | Yes |

`full-snap-node` is the recommended default: pruned execution state, bootstrapped by snap-syncing from a trusted reth peer (`WHITECHAIN_RETH_TRUSTED_PEERS`) instead of re-executing the chain. Use it when you have a reachable seed reth enode. `full-node` keeps the same pruned state 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 expect a long initial sync on a chain with history behind it. `archive-node` keeps the full historical state, so it is the profile that can answer historical `eth_call`, `debug_traceTransaction`, and log-heavy indexing. Archive cannot snap-sync, so it always re-executes from L1, which makes its initial sync the longest of the three. It needs the most disk and RAM.

<Note>
  There are no published `op-reth` database snapshots to download. `full-snap-node` bootstraps from its trusted peer, and `full-node` and `archive-node` sync by re-executing the chain from L1.
</Note>

## Available RPC namespaces

`op-reth` namespaces come from two `.env` variables that apply to all three profiles, and the two ports are configured independently:

| Port | Variable | Default |
| - | - | - |
| HTTP RPC `8545` | `HTTP_API` | `eth`, `net`, `web3`, `rpc` |
| WebSocket RPC `8546` | `WS_API` | `eth`, `net`, `web3`, `rpc` |

`archive-node` is no exception: by default it serves the same read-only set as the pruned profiles. `debug`, `trace`, `txpool`, and `reth` are an explicit opt-in through `HTTP_API` or `WS_API`, and only `archive-node` holds the history those methods read. Enable them only behind a proxy that allowlists methods and rate-limits clients. See [RPC namespaces](/operate/run-a-node/configuration#rpc-namespaces).

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

Flashblocks are not enabled on Whitechain Sepolia, so there is no pre-confirmation stream to subscribe to today. When the rollout lands, the stream stays separate from the public RPC and the `public-rpc-node` stack does not carry it. See [Flashblocks](/learn/network/transaction-finality#flashblocks).

## Related

* [Run a node](/operate/run-a-node/run-a-node)
* [Network artifacts](/operate/run-a-node/network-artifacts)
* [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)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.