Requirements

Hardware

Frost is more demanding than a typical EVM chain on two axes — CPU, because post-quantum signature verification is real work, and disk, because post-quantum signatures are large.

	Pruned follower	Validator	Full-history / archive
CPU	4 cores	8+ cores, modern x86-64	8+ cores
RAM	16 GB	32 GB	32 GB+
Disk	500 GB NVMe SSD	1 TB NVMe SSD	Grows continuously — plan for it
Network	100 Mbit	1 Gbit, low latency to peers	1 Gbit

NVMe, not SATA. State access is random-read-heavy and the difference is not marginal.

Validators want x86-64. The gas schedule is calibrated against ecrecover throughput on validator-class x86 hardware, where an optimised C implementation runs at full speed. On ARM the ratio between ecrecover and ML-DSA verification differs, so an ARM validator has less headroom under load than the prices imply. See Pricing the verifiers.

Disk growth is the planning constraint. Under sustained load the execution layer grows on the order of gigabytes per day and the consensus layer several times faster. Choose a retention window deliberately and monitor free space as a first-class alert — this is the resource that will bite you.

Network

Port	Purpose	Exposure
8645	Ingress — the user-facing JSON-RPC endpoint	Public, if you serve users
9000/udp	Consensus mesh	Reachable by other validators
9100	Observer stream (followers subscribe here)	As needed
9184	Prometheus metrics	Localhost only
8545	Execution layer RPC	Never public — the ingress fronts it
8551	Engine API, JWT-authenticated	Never public — localhost only

Two of these matter for security rather than convenience.

Do not expose 8545. The execution layer’s RPC has no submission validation and none of the ingress’s policy. Users should reach 8645.

Do not expose 8551. The Engine API drives block production. It is JWT-authenticated, but it should not be reachable at all from outside the host.

Validators need low-latency connectivity to each other. Consensus is a DAG whose commit latency tracks round-trip times between committee members, so network placement affects the whole network’s performance, not just yours.

Software

Component	Requirement
OS	Linux, x86-64
Container runtime	Docker with Compose, for the packaged deployment
Rust	≥ 1.96, if building the consensus layer from source
Go	≥ 1.25, if building the execution layer from source

The reference deployment ships digest-pinned container images and a generated Compose file, which is the recommended path.

Reproducible builds

Node binaries build reproducibly: building the same commit twice from clean contexts produces bit-identical binaries, and the expected digests are recorded per commit and checked in CI on Linux x86-64.

This matters more here than on a typical chain. Consensus-critical parameters — the ML-DSA verifier prices, the frame-transaction validity caps — are compiled into the binary, and a node compiled with different values does not degrade gracefully, it splits the chain. Verifying the digest of what you are about to run is how you confirm you are joining the network rather than forking from it.

Verify before you start:

sha256sum <binary>   # compare against the recorded digest for the commit

An automated check asserts that the pinned execution layer actually compiles the recorded consensus parameters, and that the genesis definition still hashes to its recorded value.

Time

Run NTP. Consensus is sensitive to clock skew, and the checkpoint freshness guard uses wall-clock time to decide whether the chain is progressing.

Backups

What needs backing up is small but critical:

Validator keys, especially checkpoint root keys.
The node configuration and committee manifest.

Chain data does not need backing up — a node can bootstrap from a certified checkpoint and restore a verified snapshot. Keys cannot be regenerated.