No xOne repository publishes hardware requirements for a node. There is no CPU, RAM or disk recommendation. This post lists the limits the code enforces, the numbers that someone measured, and the commands that measure your own node.
Does xOne publish hardware requirements?
No. No xOne repository publishes a CPU, RAM or disk recommendation for a node. The performance contract says it has no benchmark baseline: "No baseline numbers, no host assignment, no measured margins" (docs/perf.md). The baseline procedure says "No numbers exist yet" (bench/README.md).
Operations ADR-007 is still proposed. It asks the owner for the daily chain growth before disk values are final (ADR-007). The install page names "50 GB free in /data" as its target for a follower. It gives no derivation (ops/install.md). Read the numbers below as limits and measurements, not as a sizing guide.
Which memory and file limits does xOneRS set?
The systemd unit sets LimitNOFILE=65536 and MemoryMax=15G. The command xone doctor checks open files, vm.max_map_count, cgroup memory and address space before a long sync.
The unit (ops/[email protected]) sets:
LimitNOFILE=65536MemoryMax=15G. The unit calls it a cap from an xOneGo operator record (a 30 GB blow-up on a shared host) and says "Tune per host".
xone doctor only reads procfs, cgroupfs and df, and it exits 1 when a check fails (doctor.rs):
| Check | Fail | Warn |
|---|---|---|
| Open files (soft limit) | below 4,096 | below 65,536 |
vm.max_map_count |
none | below 65,530 |
| cgroup memory | below 2 GiB | below 8 GiB |
| Address space | below the MDBX map size | none |
The source does not cite a measurement behind the 2 GiB and 8 GiB values.
When does an xOne node stop for low disk space?
The node stops import when free space on the datadir filesystem falls below the larger of 2% or 2 GiB. It resumes at 3% or 3 GiB, and it exits with code 4 at 1% or 1 GiB.
The node samples the datadir filesystem every 5 seconds. Each line is the larger of a percent and a byte floor. Defaults on main (config.rs):
| Line | Free space below or above | Action |
|---|---|---|
| Stop | 2% or 2 GiB | Stop import, one disk_low alarm |
| Resume | 3% or 3 GiB | Import again |
| Exit | 1% or 1 GiB | After two samples: clean stop, exit code 4 |
The keys are limits.disk_{stop,resume,exit}_{pct,min_bytes} and limits.disk_sample_secs. The node refuses to start unless exit < stop < resume. The ADR proposes higher values (10% or 20 GiB to stop). The code uses lower ones because a build host with 41 GB free of 420 GB stopped every follower test at the proposed line.
While import is stopped, the producer seals no block: the disk guard closes the same gate for both (producer.rs). The ADR text still lists this as not done; the code on main has it. The NoSpace second line of defence lives in xone-db (ADR-007 section 7).
The other clients carry the proposal in their addenda, which are also "proposed". The xOneTS and xOnePy addenda adopt the 10% or 20 GiB stop line. The xOneC addendum stops at 85% used or less than 20 GiB free. xOnePy has a --datadir.minfreedisk flag for a shared disk. The xOneTS, xOnePy and xOneC repositories are private.
How large can the xOne database grow?
chain.mdbx has an upper bound of 1TB by default and a growth step of 64MB. Both are flags. When the map is full, the write fails, committed data stays intact, and you restart with a larger value.
Flags (db-geometry.md):
| Flag | Default | Bounds |
|---|---|---|
--db.max-size |
1TB |
16MB to 8TB |
--db.growth-step |
64MB |
1MB to --db.max-size |
The error names --db.max-size. A larger step means fewer remaps under heavy import. A smaller step means a smaller file.
Should I use memory state or disk state?
By default xOneRS loads the head state into memory. The --state.disk flag reads state from the MDBX tables behind caches instead. The disk-state page says memory state is too much for Apothem.
The page gives 327,356 accounts and about 158 M slots, "over 40 GB" (disk-state.md). A synthetic run (500,000 accounts, 2 M slots) used 1,329 MB with memory state and 1,157 MB with disk state, with the trie still in memory.
xOneTS keeps a similar flag. Its page says Apothem snap sync needs "about 35 GB free during the sync" (xOneTS disk-state.md).
What memory and disk use did xOne measure?
xOne has single runs, not a benchmark. The Rust client used 4.21 GB resident memory and a 20 GB datadir at the head of a net2040 full sync. Where the source states the host load, it is in the row.
| Client, run | Result |
|---|---|
| xOneRS, net2040 full sync, 2026-11-12, load average 17 to 27 | Genesis to block 766,981 in 108 minutes. At the head: VmRSS 4.21 GB (heap 1.41 GB, mapped file 2.80 GB). Datadir 20 GB. |
| xOneRS, Apothem from genesis to block 1,064,000, 2026-11-12 | Resident memory 1.1 to 1.2 GB. Datadir 1.7 GB at block 1,066,000. |
| xOneRS, net2040 snap sync, 2026-11-12 | 72 MB datadir, peak RSS 75,936 kB. |
| xOneTS, net2040 snap sync, 2026-11-12 | 15,881,704 B datadir, peak RSS 560,340 kB. |
| xOneC, replay with 0 mismatches (the page gives no date) | Peak RSS 134 MB (net2040 to block 23,400), 214 MB (Apothem to block 432,000). Load average 33. |
Sources: xOneRS apothem-follow.md, net2040-sync-modes.md, xOneTS, xOneC.
Memory during a live follow is not measured for xOnePy or xOneC. Both performance pages list it under "Not measured". xOnePy's page also states its CPU: 20 cores (i5-13500), with the recovery pool at cores - 2 processes (py-performance.md).
For disk layout and history growth, see node storage and archive mode in xOne. For the numbers the project tracks, see performance.
How do other clients state their hardware requirements?
Other clients publish a recommendation on their own pages. xOne publishes none. The table puts each competitor figure beside the xOne rows. The networks differ, so do not compare the rows one to one.
The competitor figures are for Ethereum or for XDC masternodes. The xOne figures were measured on net2040 and Apothem.
| Client | Network | What the article states | Source |
|---|---|---|---|
| XDC masternode docs | XDC Network masternode | 6-core, 16 GB, 1 TB SSD, 1 Gbps. Stake: 10,000,000 XDC. (The page shows no date.) | docs.xdc.network |
| geth | Ethereum | 16 GB RAM, 2 TB SSD, 25 Mbps, quad-core, as stated in the geth hardware requirements page, 2023-09-14 | geth.ethereum.org |
| erigon | Ethereum | Full: 535 GB used / 2 TB advised. Archive: 2.25 TB / 4 TB. RAM 16/32 GB. As stated in the erigon hardware requirements page, updated 2026-11-11 | docs.erigon.tech |
| reth | Ethereum | Full node >= 1.2 TB, archive >= 2.8 TB, 16 GB RAM, TLC NVMe, as stated in the reth system requirements page, dated 2025-06-23 | reth.rs |
| besu | Ethereum public networks | 1.14 TB for snap sync with Bonsai, minimum JVM memory 8 GB, reference 8 vCPU / 30 GiB, as stated in the besu system requirements page (no date shown) | docs.besu-eth.org |
| nethermind | Ethereum mainnet | 16 GB RAM / 4 cores. Archive: 128 GB / 8 cores. At least 10,000 IOPS. As stated in the nethermind system requirements page (no date shown) | docs.nethermind.io |
| ethrex | Ethereum mainnet | 4-8 cores, 32 GB RAM, 1 TB NVMe. Disk: 500 GB minimum / 1 TB recommended. As stated in the ethrex hardware requirements page (no date shown) | docs.ethrex.xyz |
| xOneRS | XDC net2040 | xOne: no published recommendation; measured: 4.21 GB VmRSS and 20 GB datadir at block 766,981 (full sync, 2026-11-12) | apothem-follow.md and net2040-sync-modes.md |
| xOneRS | XDC Apothem | xOne: no published recommendation; measured: 1.1 to 1.2 GB resident memory to block 1,064,000, datadir 1.7 GB at block 1,066,000 (2026-11-12) | apothem-follow.md |
How do I measure my own node?
Run xone doctor, then capture the environment of a run with bench/collect/env.sh. Report memory as three separate numbers.
- Run
xone doctorand read its findings. - Check the stamp:
xone --version. - Capture the environment for a run record:
bench/collect/env.sh --datadir DIR --binary PATH --pid PID > env.json
python3 -I bench/collect/summarise.py lat.csv
summarise.py reads a CSV with a latency_ms column. Report three memory numbers separately: RSS (VmRSS, RssAnon, RssFile), cgroup memory.current, and page cache. The contract says to report them separately and never compare them as one. Put the node in a cgroup with a fixed memory.max and cpu.max, and sample every second.
To try disk state, start with --state.disk. To run the store tests over it:
XONE_DISK_STATE=1 cargo test -p xone-fault -p xone-sync -p xone-state
See also the node operations guide.
Frequently asked questions
How much RAM does an xOne node need?
No xOne repository publishes a RAM recommendation. The systemd unit sets MemoryMax=15G and says "Tune per host". xone doctor fails below 2 GiB of cgroup memory and warns below 8 GiB.
How much disk space does an xOne node need?
No xOne repository publishes a disk recommendation. The install page names "50 GB free in /data" as a follower target, with no derivation. A net2040 full sync measured a 20 GB datadir at block 766,981.
When does an xOne node stop importing blocks?
The node stops import when free space on the datadir filesystem falls below the larger of 2% or 2 GiB. It resumes at 3% or 3 GiB. It exits with code 4 at 1% or 1 GiB.
What are the XDC masternode hardware requirements?
The XDC masternode docs state 6-core, 16 GB, 1 TB SSD and 1 Gbps, with a stake of 10,000,000 XDC. xOne does not publish its own figure.
Sources
- xOneRS ADR-007, db-geometry, disk-state
- xOneRS perf.md, bench/README.md, ops/install.md
- xOneTS ADR-007 addendum (private)
- xOnePy ADR-007 addendum (private)
- xOneC ADR-007 addendum (private)
This article describes the source and evidence at its review date. Check the linked repository for current implementation and qualification status.
Explore the engineering evidenceEdit this page on GitHub opens the Markdown source (content/blog/xone-hardware-disk/index.md). GitHub may ask you to sign in. Report a correction opens a prefilled GitHub issue for this page.