Skip to main content
Deploy an external Whitechain RPC node on your own server. By the end of this guide you will have a running op-reth + op-node pair that follows the canonical L2 chain and exposes JSON-RPC and WebSocket endpoints.
Available on Testnet today; Mainnet at launch.

Prerequisites

Hardware

Disk usage grows with the chain. Restoring a snapshot saves the initial sync time but does not change steady-state growth.

Software

  • A Linux server with a public IP.
  • Docker with Compose v2.
  • make, git, openssl, curl, jq.
  • zstd and tar if you restore from a snapshot.

L1 RPC and Beacon

You need your own Ethereum L1 RPC and Beacon endpoints. op-node reads L1 batches through the RPC. It reads blob data through the Beacon API, since Whitechain batches are posted to L1 as EIP-4844 blobs, and blobs are only retrievable through the Beacon API, not the execution RPC. A regular execution-only endpoint is not enough; whatever you use must expose both. Run your own L1 node, or use a provider that offers a matching pair of endpoints for the network below. Not every provider exposes a Beacon API on its free tier, so confirm both endpoints respond before filling in .env.

Files from the Whitechain team

  • genesis.json (L2 execution genesis) and rollup.json (OP rollup configuration) for your network. Both are published, with checksums and a regeneration recipe, in the whitechain-bootstrap repository. See Network artifacts.
  • WHITECHAIN_PUBLIC_RPC: the public Whitechain RPC URL, used as the transaction-forwarding target.
  • WHITECHAIN_RETH_TRUSTED_PEERS: a trusted reth enode to snap-sync from (required for full-snap-node).
  • WHITECHAIN_PUBLIC_OP_NODE_P2P (optional): a static op-node peer.
  • An op-reth database snapshot URL (optional, recommended for full-node and archive-node).
For testnet, the artifacts/testnet/ files and .env.testnet.example already ship with working values for all of these, byte for byte identical to the published artifacts. You only need to request values from the Whitechain team for mainnet, or if you need a fresh snapshot URL.

Set up the node

  1. Get the public-rpc-node manifests onto your server, from the whitechain-labs/node repository.
  2. Place the network artifacts under artifacts/<network>/. The folder name must match WHITECHAIN_NETWORK in .env. See Network artifacts for where to download them and how to verify them.
  3. Create your .env from the example and fill in the required values.
    For the full list of variables, see Node configuration.
  4. To skip the long initial sync on full-node or archive-node, restore a snapshot first. See Restore from a snapshot. full-snap-node skips this step. It snap-syncs directly from WHITECHAIN_RETH_TRUSTED_PEERS.
  5. Start the profile you chose.
    make up validates .env and the artifacts, generates keys/jwt.txt if missing, then runs docker compose --profile <profile> up -d.
  6. Confirm the node responds on the profile’s HTTP port.
For full-node and archive-node, initial sync from genesis re-executes every transaction and can take from minutes on a fresh testnet to many hours on a long-running chain. Restore a snapshot to cut this down, or use full-snap-node, which snap-syncs from its trusted peer instead and typically completes in about an hour on testnet.

Verify the sync

Watch the logs with make logs-full-snap-node (or logs-full-node / logs-archive-node). In op-node you should see Connected to L1 Beacon API and started p2p host with your local peerID early on. What follows depends on the profile’s sync method:
  • full-snap-node (execution-layer / snap): Starting EL sync, then repeating Inserting unsafe L2 execution payload to drive EL sync and Inserted new L2 unsafe block lines. These appear as blocks are pulled from the trusted peer and applied to op-reth.
  • full-node / archive-node (consensus-layer): repeating Advancing bq origin lines (L1 batch derivation), then Inserted new L2 unsafe block lines as op-reth re-executes each block.
Underneath this, op-reth runs its own staged sync pipeline (14 stages) independently of what op-node reports. The RPC keeps reporting block 0 until the pipeline finishes, which is expected, not a hang. Watch the op-reth container logs directly: docker logs -f whitechain-<profile>-op-reth 2>&1 | grep --line-buffered -iE "stage=|received headers|finished stage". Header download logs Received headers ... to_block=N; later stages log checkpoint=X target=Y.
In the first few minutes after start, the node may report no peers ready to handle block requests until the static peer handshake completes. Wait for a connected peer to appear before treating this as an error.
op-node RPC on 9545 is bound to loopback (127.0.0.1) only, on every profile. Query it from the host the node runs on, not over the network.
Check how far the node is behind the wall clock:
Check connected peers: