Skip to main content
v0.7.3: minor release with no breaking changes. This release adds new Consensus Layer Prometheus metrics, accepts hex-encoded block heights on arc_getCertificate, and tightens the pending-block RPC filter. Upgrading from v0.7.2 requires no configuration changes. For the full upgrade notes, see CHANGELOG.md and BREAKING_CHANGES.md.
An Arc node syncs blocks from the network and serves a local JSON-RPC endpoint so you can independently verify every block and transaction. It runs two processes: the Execution Layer (EL), which executes transactions and maintains state, and the Consensus Layer (CL), which fetches finalized blocks from relay endpoints (trusted HTTP servers that distribute signed block data), verifies their signatures, and passes them to the EL. For a deeper explanation of how these components fit together, see Running a node.
Arc is currently in its testnet phase. During this period, the network may experience instability or unplanned downtime. Throughout this page, all references to Arc refer specifically to the Arc Testnet.
Choose the install path that fits your environment.
Install pre-built Arc binaries using the arcup script. This is the fastest path and requires no Rust toolchain or build dependencies.

Prerequisites

Before you begin, confirm that you have:
  • Reviewed the node requirements for hardware, software, and network endpoints
  • Prepared a Linux or macOS machine that meets the minimum system requirements
  • Installed Foundry (optional, provides the cast command used to verify your node)

Step 1: Install with arcup

arcup installs the Arc binaries under $ARC_HOME (default ~/.arc). Export ARC_HOME first if you want to install somewhere else; otherwise the default applies for both the installer and the environment file:
The installer places arc-node-execution, arc-node-consensus, arc-snapshots, and arcup itself into $ARC_HOME/bin. Load the produced environment file so the binaries are on your PATH:
Verify the installation:
Each command prints a version string. To update the binaries later, run arcup.

Step 2: Set environment variables

The remaining steps use a small set of variables to keep paths consistent. Write them to a file and source it:

Step 3: Create data directories

Create the data directories for the EL and CL, plus the runtime directory used for IPC sockets:
On macOS, replace the second command with mkdir -p "$ARC_RUN" after uncommenting the macOS line in ~/.arc_env.
When running as a systemd service, the RuntimeDirectory=arc directive creates /run/arc automatically. You can skip the second command in that case.

Step 4: Download blockchain snapshots

Download snapshots so the node starts syncing from a recent block height rather than from genesis:
This command fetches the latest snapshot URLs from https://snapshots.arc.network, downloads the snapshots, and extracts them into $ARC_EXECUTION and $ARC_CONSENSUS.
Snapshots are large. Testnet snapshots are approximately 68 GB EL + 16 GB CL compressed (around 103 GB and 36 GB extracted). The download takes 10–15 minutes on a stable 100 Mbps connection; slower or metered connections can take hours. Ensure you have at least 150 GB of free disk space, a stable network connection, and available CPU. The terminal stops producing output during extraction. This is expected.

Step 5: Initialize the consensus layer

Generate the CL private key file used for network identity. This is a one-time setup step:

Step 6: Start the execution layer

Start the Execution Layer. This creates the IPC sockets that the Consensus Layer connects to.
The EL starts and waits for blocks. Log output shows that the IPC sockets exist at $ARC_RUN/reth.ipc and $ARC_RUN/auth.ipc.On high-traffic public endpoints, raise --rpc.max-connections (default 250) and --rpc.max-subscriptions-per-connection (default 32) if clients see MaxConnections or TooManySubscriptions errors. The defaults bound WebSocket log-fanout memory growth and should only be raised, not lowered.
The --full flag is required on the first start when bootstrapping from a pruned snapshot. It reconciles internal database tables that would otherwise fail a consistency check. After the initial startup completes, restart without --full if you prefer not to prune. --chain arc-testnet uses the bundled genesis configuration; replace with --chain /path/to/genesis.json if you have a custom genesis file. See reth node for additional flags.

Step 7: Start the consensus layer

Open a separate terminal and start the Consensus Layer. The CL connects to the EL through the IPC sockets and begins fetching blocks from the network.

Step 8: Verify the node is syncing

After both layers start, wait roughly 30 seconds, then query the local JSON-RPC endpoint for the latest block height:
The result field is a hexadecimal block number that increases over time. If it stays at 0x0, check the CL logs for errors.If you have Foundry installed, you can run the same check with cast:
Run it several times over a few seconds — the block number increases as the node syncs.If the block number stays at 0x0 or the node does not start as expected, check these common causes:
  • IPC socket files missing. The EL writes sockets at $ARC_RUN/reth.ipc and $ARC_RUN/auth.ipc on startup. If they are not present after 30 seconds, the EL did not start — review its terminal output for a panic or configuration error.
  • CL cannot connect to the EL. Start the EL first. If the CL was launched before the EL was ready, restart the CL.
  • Snapshot extraction incomplete. arc-snapshots download runs silently during extraction. If it was interrupted, $ARC_EXECUTION or $ARC_CONSENSUS may be partially populated. Re-run the download to overwrite the existing files. If you clear the directories first, note that $ARC_CONSENSUS also holds the CL private key written by arc-node-consensus init. Re-run that command after clearing, or your node loses its network identity.
  • Path mismatch between EL and CL. $ARC_RUN must resolve to the same directory in both shells. Re-source ~/.arc_env in any terminal that lost its environment.
Once your node is syncing steadily, you can deploy it as a systemd service for production use, or set up Prometheus and Grafana to view the pre-built dashboards.

Run on separate hosts

The tabs above describe running the Execution Layer and Consensus Layer on the same host, communicating through IPC sockets. To run them on separate hosts, swap IPC for authenticated RPC. This section applies to the binary install paths (arcup and source build); the Docker path is single-host by default.

Generate a JWT secret

The EL and CL authenticate to each other with a shared JWT secret. Generate it once, then securely copy it to both hosts:

Execution layer flags for RPC mode

Remove the IPC flags (--ipcpath, --auth-ipc, --auth-ipc.path) from the EL command and add:
--authrpc.addr 0.0.0.0 exposes port 8551 on every network interface. Restrict access with a firewall rule or private network — the Engine API controls block production and must not be reachable from the public internet.

Consensus layer flags for RPC mode

Remove --eth-socket and --execution-socket from the CL command, and add:
Replace <EL_HOST> with the IP address or hostname of the EL host.
IPC and RPC are mutually exclusive. Use one or the other, not both.

Enable backpressure under memory pressure

The tabs above start the Consensus Layer with backpressure enabled at the default threshold (16). Backpressure throttles execution to match the speed of disk writes, bounding Execution Layer memory growth during startup or extended sync when the node is far behind.If you observe sustained memory pressure on a host that meets the node requirements, lower the threshold to 10 for more aggressive throttling. First, add the reth namespace to the EL --http.api flag so the CL can read backpressure metrics:
Then restart the CL with the lower threshold: