Requirements
Hardware
Section titled “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.
The figures below are derived from what the public fleet actually runs, not from a specification. Its validators are small cloud hosts — 2 to 4 vCPUs, under 8 GB of memory, and well under 100 GB of disk on the pruning tiers — and they keep up with ordinary load.
| Resource | Guidance |
|---|---|
| CPU | 2–4 vCPUs of modern x86-64 keep up with ordinary load. More cores are headroom for ML-DSA verification under load, not a requirement. |
| RAM | 8 GB. The fleet’s 8141-geth validators run with a 3 GiB Go heap ceiling on hosts of about 7 GiB. |
| Disk | NVMe SSD. A pruned node’s footprint is bounded: the execution layer by its history window, the consensus store by its retention window and byte clamp. An archive node grows continuously — plan for it. |
| Network | Low latency to the other validators matters more than raw bandwidth. |
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 depends on client and tier. A pruned node does not grow: its execution layer keeps a rolling window and its consensus store is bounded by the retention window and the byte clamp. The tx-history tier grows with traffic — on the order of gigabytes per day at the fleet’s resident load on 8141-geth, several times less on frost-reth’s compressed stripped store — and the archive tiers grow with everything. Choose a tier deliberately and monitor free space as a first-class alert — this is the resource that will bite you.
Network
Section titled “Network”| Port | Purpose | Exposure |
|---|---|---|
| 8645 | Ingress — the user-facing JSON-RPC endpoint | Public, if you serve users |
| 9000 | Consensus mesh — mutually-authenticated post-quantum TLS over TCP | Reachable by other validators |
| 9100 | Observer stream — validators only; allowlisted by follower network key | Reachable by your followers |
| 30303 | Execution-layer devp2p mesh — checkpoint bootstrap snap-syncs over it | Reachable by peer execution layers |
| 9184 | Prometheus metrics | Localhost only |
| 8545 | Execution layer RPC | Never public — the ingress fronts it |
| 8551 | Engine API, JWT-authenticated | Never public — localhost only |
The mesh and observer addresses are written as multiaddrs of the form
/ip4/<addr>/udp/9000. The /udp/ is a Mysticeti spelling convention; the
transport is TCP, and firewalls should be opened accordingly.
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
Section titled “Software”| Component | Requirement |
|---|---|
| OS | Linux, x86-64 |
| Container runtime | Docker with Compose, for the packaged deployment |
| Rust | 1.96.1 for the consensus layer, 1.97.1 for frost-reth — each pinned by its rust-toolchain.toml |
| Go | 1.25, for the 8141-geth execution layer |
The toolchains are pinned, not minimums: a builder image must match them for its digests to reproduce. The reference deployment ships digest-pinned container images and a generated Compose file, which is the recommended path.
Reproducible builds
Section titled “Reproducible builds”Node images build reproducibly: building the same commit twice from clean contexts produces bit-identical binaries, image configuration and whole root filesystems. The runtime images are a digest-pinned base plus measured files, so an added file, a swapped library or an altered entrypoint fails the check as surely as a different binary. 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 commitThe deployment tooling measures the binary, the image configuration and the root filesystem of every image before distributing it, and refuses on a mismatch or a missing record.
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.
Run NTP. Consensus bounds how far ahead of local time a peer’s block timestamp may be, so a skewed clock is a peer that disagrees with everyone. The checkpoint freshness guard does not use wall-clock time: it counts block-producing commits since certification last advanced, and alarms and halts at 3 and 10 checkpoint intervals of staleness.
Backups
Section titled “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.