System Requirements

Running a Zink node — whether validator or RPC — demands serious hardware. The SVM is CPU- and memory-intensive, and the ledger grows continuously. Under-specced machines will fall behind the cluster, miss votes, or fail to serve RPC requests in time.

Upstream-compatible

Zink runs the same Agave validator software shape as Solana. If a host is viable for serious Solana validator or RPC work, it is in the right class for Zink.

Hardware

Validator

Component	Minimum	Recommended
CPU	16 cores / 32 threads, 2.8 GHz+ (modern AMD EPYC or Intel Xeon)	24+ cores with strong single-thread performance and AVX2/AVX-512 support
RAM	256 GB ECC	512 GB ECC
OS disk	500 GB NVMe SSD	500 GB+ NVMe SSD
Ledger disk	1 TB NVMe SSD (high IOPS)	2 TB NVMe SSD
Accounts disk	500 GB NVMe SSD	1 TB NVMe SSD
Network	1 Gbps symmetric	10 Gbps symmetric

RPC node

RPC nodes often need more storage because they maintain account indexes and serve historical data:

Component	Minimum	Recommended
CPU	16 cores / 32 threads	32+ cores
RAM	256 GB ECC	512 GB ECC
Ledger disk	2 TB NVMe SSD	4 TB NVMe SSD
Accounts disk	1 TB NVMe SSD	2 TB NVMe SSD
Network	1 Gbps symmetric	10 Gbps symmetric

Zink-specific

Zink's current state footprint may be smaller than Solana mainnet because it serves a narrower workload, but operators should still size for replay spikes, snapshot downloads, indexing overhead, and future growth. The tables above are conservative on purpose.

Disk layout

Separating ledger and accounts onto independent NVMe drives is strongly recommended. The validator performs heavy random I/O against accounts and sequential writes to the ledger simultaneously; putting both on the same drive creates contention.

/mnt/ledger    → dedicated NVMe for --ledger
/mnt/accounts  → dedicated NVMe for --accounts

If you run a public or index-heavy RPC node, consider an additional dedicated volume for long-retention data or exported datasets instead of letting everything compete on the same disks.

Network prerequisites

A validator needs more than bandwidth. It also needs stable reachability.

Connectivity

Requirement	Why it matters
Publicly reachable IPv4 address	Peers need to reach your gossip, repair, and turbine ports
No restrictive NAT / CGNAT	Port mapping problems can make the node invisible even if the process is healthy
Low packet loss	Replay and repair traffic degrade quickly on lossy links
Reliable clock sync	Large clock drift causes confusing startup and consensus issues

Ports

The validator uses a range of UDP and TCP ports for gossip, turbine, repair, and optional RPC:

Port / Range	Protocol	Purpose
8000–10000	UDP + TCP	Default dynamic port range for gossip, turbine, repair, TPU, and related traffic. Controlled by --dynamic-port-range.
8899	TCP	JSON-RPC, if enabled
8900	TCP	WebSocket RPC, if enabled

Upstream-compatible

The default port layout matches standard Agave validator expectations. If you already know how to open ports for Solana validator traffic, the same pattern applies here.

Firewall rules

• Inbound UDP 8000–10000 must be open to the public internet, or at minimum to the other cluster nodes you expect to peer with.
• Inbound TCP 8000–10000 should also be allowed because several validator services bind TCP inside the dynamic range.
• Inbound TCP 8899/8900 should be open only if you intentionally serve RPC traffic.
• Outbound traffic should be broadly allowed; blocking peer-to-peer ports is one of the fastest ways to create a node that starts but never joins properly.

Bandwidth

Expect sustained bandwidth usage of 100–300 Mbps during normal operation, with spikes materially higher during snapshot downloads or catchup. A 1 Gbps symmetric connection is the practical floor for serious operator work.

Operating system

Requirement	Details
OS	Ubuntu 22.04 LTS or 24.04 LTS
Kernel	5.15+ recommended
File system	ext4 or XFS on NVMe volumes
Time sync	systemd-timesyncd, chrony, or equivalent must be healthy

Zink recommendation

macOS and Windows are not supported for production node operation. Use Linux. Development and testing with solana-test-validator on macOS is fine.

System tuning

The following kernel and process settings are worth applying before first boot.

sysctl

sudo tee /etc/sysctl.d/21-agave-validator.conf >/dev/null <<'EOF'
# Increase UDP socket buffers
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728

# Increase memory map areas
vm.max_map_count = 1000000

# Increase open-file ceiling
fs.nr_open = 1000000
EOF

sudo sysctl --system

File descriptor and memlock limits

sudo tee /etc/security/limits.d/90-zink-validator.conf >/dev/null <<'EOF'
* - nofile 1000000
* - memlock 2000000
EOF

If you run the validator via systemd, also set these in the unit:

LimitNOFILE=1000000
LimitMEMLOCK=2000000000

Verification

ulimit -n
cat /proc/sys/vm/max_map_count
cat /proc/sys/net/core/rmem_max
cat /proc/sys/net/core/wmem_max

Preflight checklist

Before starting a node, confirm:

# CPU info — check core count and AVX support
lscpu | grep -E "^CPU\(s\)|Model name|Flags.*avx"

# Memory
free -h

# Disk layout and free space
lsblk
df -h /mnt/ledger /mnt/accounts

# Open file limit
ulimit -n

# Max memory map areas
cat /proc/sys/vm/max_map_count

# Time sync
timedatectl status

Healthy operator assumptions before boot:

• ledger and accounts live on separate NVMe devices
• the host has a public IP and the intended dynamic port range is open
• clock sync is healthy
• the host is not swapping under idle conditions
• validator binaries match the cluster version you intend to join

Next steps

• CLI & Tooling — install the Solana CLI and Agave validator
• Run a Validator — full validator setup
• Run an RPC Node — full RPC node setup