04

The supply side

Operators

Powered by Fermah shows who buys proofs. This page follows who makes them: the prover names published by Fermah Explorer, the requirements for running a node, and what the public contract evidence confirms.


Fermah Proof Explorer

The prover names in the record.

A snapshot of the public Explorer, captured . These are Explorer display names; their Ethereum operator addresses have not been matched.

Prover names
10
With connected machines
6
Connected machines
7
Fermah Explorer snapshot · 2026-10-26 07:57 UTC
Prover nameMachines in sourceConnectedTasks completed · 1hFirst seen in Explorer
moonli ↗221152026-02-25
staking4all ↗11582026-05-08
rubynodes ↗11562026-04-24
blackblocks ↗21312026-08-12
fermah.wg.c4d ↗2,723182026-08-13
fermah.cp.g4 ↗15,400002026-08-11
natsai ↗1002026-04-06
p-ops ↗2002026-02-12
cp0x ↗2002026-02-24
fermah.c.g2 ↗2102026-08-06

Machine counts include all records in the source, including disconnected entries. They are not a count of operating servers. A zero connected count in this snapshot does not establish that an operator has left. The 1h counters belong to the source’s rolling window at capture time.

Open current Explorer ↗Download snapshot JSON

Running a prover node

Start with the assigned profile.

A Seeker submits a Proof Request, the Matchmaker allocates it, and a prover node generates the proof. Onboarding is permissioned: submit your Mainnet Ethereum public address to Fermah for whitelisting and obtain the assigned prover-node name before installation.

  1. Prepare the server

    Use a supported OS, compatible NVIDIA drivers and CUDA toolkit, Docker and NVIDIA Container Toolkit.

  2. Configure the identity

    Install the prover binary, use the assigned configuration and create the machine secret. Keep private keys and secrets on your machine.

  3. Register, then start

    Configure Ethereum Mainnet RPC, register the node, set up telemetry and start it. The --el registration flag applies to an already-registered EigenLayer operator participating with the same operator identity key.

Official commands: Installation ↗ · Configuration ↗ · Registration ↗. Checked October 26, 2026.

Software and supported OS profiles
Official Installation profiles · checked October 26, 2026
OSArchitectureCUDAGLIBC
Ubuntu 22.04 LTSamd6412.22.34+
Ubuntu 24.04 LTSamd6412.92.39+

Other Linux distributions need compatible GLIBC. Both NVIDIA drivers and CUDA toolkit are required; the CUDA numbers above are not driver release numbers.

Root Docker v24+ is used for telemetry, rootless Docker v24+ for prover containers. Configure NVIDIA Container Toolkit for rootless Docker.

Official Installation guide ↗

Hardware: two published CPU/RAM profiles

The Mainnet Overview and the dedicated Provers page disagree for these two ZKsync roles. Neither establishes which CPU/RAM minimum governs. Confirm the assigned profile with Fermah before choosing hardware.

Published CPU/RAM values · checked October 26, 2026
RoleMainnet OverviewProvers page
Circuit Prover (CP)16 vCPU · 64 GB RAM32 vCPU · 128 GB RAM
CPU Witness Generator · all16 vCPU · 64 GB RAM32 vCPU · 128 GB RAM

Both pages give CP 24 GB GPU VRAM and 375 GB SSD. WGC additionally includes a compressor requiring at least 24 GB GPU memory, so CPU witness-round figures alone do not describe a complete WGC machine.

Mainnet Overview ↗ · Provers ↗

Individual witness rounds
Individual CPU witness rounds, not a complete WGC specification
RoundvCPURAM
basic_circuits1632 GB
leaf_aggregation1680 GB
node_aggregation84 GB
recursion_tip41 GB
scheduler41 GB

These CPU/RAM rows agree across the two pages. Disk requirements are not stated for these rounds. Source: Provers ↗

Multiple GPUs and remaining setup questions

The Multi-GPU guide describes one prover-node instance/container per GPU, separate Fermah home directories, unique machine secrets, independent registration and explicit GPU pinning.

Its examples mount /var/run/docker.sock and use root systemd services. The guide does not explain how those examples relate to the rootless prover-container requirement; confirm the container context for your setup.

The checked guides do not establish a universal stake minimum, bandwidth minimum or uptime SLA. This does not establish that no such conditions exist.

Multi-GPU Setup ↗ · Mainnet Overview ↗


Contract evidence

Keep the network explicit.

The Mainnet configuration example names the following addresses. Blockscout identifies contracts at both addresses on Ethereum Sepolia (chain ID 11155111). A production Ethereum Mainnet AVS deployment is not confirmed by this evidence.

fermahServiceManager
0xEE4eE799e09Ea975139c93Da2E403a8A0Ea8eE6a ↗Sepolia · source not verified
fermahStakeRegistry
0x0118abd80cC8895Cbd40f5912e8E36c863CC61c1 ↗Sepolia · source not verified

Checked 2026-10-26. On Ethereum Mainnet (chain ID 1), the indexer did not identify these addresses as contracts. An indexer response is not an independent bytecode check and does not prove that no deployment exists. These addresses are not used to assign Ethereum identities to the Explorer names above.

Official configuration example ↗Download contract evidence

Corrections

Keep the record useful.

A changed prover name, a missing source or an updated setup requirement? Send the public source and the detail to correct.

Suggest a correctionOfficial node docs ↗

Atlas does not infer which person owns an address or request private keys, machine secrets or a wallet connection.