Every xOne and nethermind-xdc node in the sample was at the head of its network, within 2 blocks. Their datadir sizes and memory use differ, and the tables below give the numbers. Core block fields were equal for every node. The RPC difference is the JSON shape.
nethermind-xdc is the XDC fork of Nethermind, an XDCIndia client like xOne. Its repository, XDCIndia/xdc-nethermind-private, is private. This post compares measurements. It does not rank the clients. For the geth-XDC comparison, see xOne vs geth-XDC.
Measured read-only on 2026-11-14 at 19:20 UTC by the xOne team on its own follower nodes; one sample, not a time series.
How were the nodes measured?
Each node was read once, read-only, at the same moment. The source for every number below is "xOne team measurement, 2026-11-14 19:20 UTC". It has no file link.
- Head and lag.
eth_blockNumberon each node. Lag is the reference head minus the node head at the same second. The reference is a geth-XDC node of the same network: full sync on net2040, snap sync on Apothem. A negative lag means the node was ahead by that many blocks. Reference heads: net2040 841,381; Apothem 85,385,427. - Disk.
du -sx --block-size=1of the datadir. - Memory.
VmRSSof the main process, from/proc.RssAnonis heap.RssFileis mapped files. An MDBX or RocksDB map counts asRssFile. Where both are read, compareRssAnon. xOnePy runs extra worker processes that are not counted. - RPC. 50 calls to the node and the reference: 30
eth_getBlockByNumber(n, false)for n = head-130 to head-101, 10eth_getBlockTransactionCountByNumberfor the last 10 of those, and 10eth_getBlockByHash(hash, false)for the first 10 hashes. The check compares the whole JSON after it lowers the case of strings. The core fields are hash, parentHash, stateRoot, receiptsRoot, transactionsRoot, number, miner, gasUsed and timestamp.
Do both clients stay at the head on net2040?
Yes, at this sample. All five nethermind-xdc nodes were at 841,381, lag 0. The xOne nodes were at lag 0, except two xOnePy nodes at lag 2. The sync or pruning mode is in the node name. "Not read" means the probe did not read the value.
| Node | Head | Lag | Datadir bytes (GB) | VmRSS kB | RssAnon kB | RssFile kB |
|---|---|---|---|---|---|---|
| xOneRS full | 841,381 | 0 | 20,637,130,752 (20.64) | 85,948 | 65,116 | 16,492 |
| xOneRS full (second node) | 841,381 | 0 | 20,703,092,736 (20.70) | 601,132 | not read | not read |
| xOneRS archive | 841,381 | 0 | 22,784,475,136 (22.78) | 198,324 | 88,216 | 108,164 |
| xOneRS fast | 841,381 | 0 | 147,234,816 (0.15) | 211,284 | not read | not read |
| xOneRS minimal | 841,381 | 0 | 147,230,720 (0.15) | 228,564 | not read | not read |
| xOneTS full | 841,381 | 0 | 19,564,638,208 (19.56) | 298,696 | 277,000 | 24,864 |
| xOnePy snap | 841,379 | 2 | 94,523,392 (0.09) | 83,408 | not read | not read |
| xOnePy minimal | 841,379 | 2 | 94,642,176 (0.09) | 107,900 | not read | not read |
| xOneC full | 841,381 | 0 | 17,990,488,064 (17.99) | 106,064 | 58,476 | 46,888 |
| xOneC archive | 841,381 | 0 | 22,218,342,400 (22.22) | 123,472 | not read | not read |
| xOneC snap | 841,381 | 0 | 142,987,264 (0.14) | 79,628 | not read | not read |
| xOneC minimal | 841,381 | 0 | 142,864,384 (0.14) | 74,312 | not read | not read |
| nethermind-xdc A (memory pruning) | 841,381 | 0 | 7,383,662,592 (7.38) | 950,156 | 828,204 | 61,908 |
| nethermind-xdc B (memory pruning) | 841,381 | 0 | 7,346,262,016 (7.35) | 728,292 | not read | not read |
| nethermind-xdc C (memory pruning) | 841,381 | 0 | 7,403,175,936 (7.40) | 873,956 | not read | not read |
| nethermind-xdc archive | 841,381 | 0 | 11,367,477,248 (11.37) | 1,043,128 | not read | not read |
| nethermind-xdc full (hybrid) | 841,381 | 0 | 7,558,971,392 (7.56) | 713,808 | not read | not read |
Source: xOne team measurement, 2026-11-14 19:20 UTC, net2040.
How do disk and memory compare on net2040?
Compare the same mode. The nethermind-xdc archive datadir is 11.37 GB. The xOneRS and xOneC archive datadirs are 22.78 GB and 22.22 GB. The nethermind-xdc full (hybrid) datadir is 7.56 GB. The xOne full datadirs are 17.99 GB to 20.70 GB. The three memory-pruning nodes are 7.35 GB to 7.40 GB.
For heap, RssAnon is the fair column. nethermind-xdc A reads 828,204 kB. The xOne full nodes read 58,476 kB (xOneC), 65,116 kB (xOneRS) and 277,000 kB (xOneTS). The xOneRS archive node reads 88,216 kB. No RssAnon was read for the other nethermind-xdc nodes, so only VmRSS exists for them (713,808 kB to 1,043,128 kB).
This sample does not say why the sizes differ. For what xOne writes to a datadir, see the storage layout. The nethermind-xdc nodes have no snap-like or minimal row on net2040. The xOne snap, fast and minimal nodes are 0.09 GB to 0.15 GB.
Do both clients stay at the head on Apothem?
Yes, at this sample. Reference lag 0 is the head 85,385,427. A lag of -1 means the node was one block ahead.
| Node | Head | Lag | Datadir bytes (GB) | VmRSS kB | RssAnon kB | RssFile kB |
|---|---|---|---|---|---|---|
| xOneRS snap | 85,385,428 | -1 | 75,107,868,672 (75.11) | 519,008 | 489,112 | 33,192 |
| xOnePy snap | 85,385,428 | -1 | 31,119,683,584 (31.12) | 179,856 | 166,264 | 14,236 |
| xOneC snap | 85,385,428 | -1 | 51,045,007,360 (51.05) | 10,107,556 | 349,504 | 9,793,144 |
| nethermind-xdc hybrid | 85,385,427 | 0 | 23,662,329,856 (23.66) | 1,765,084 | 1,673,928 | 62,064 |
| nethermind-xdc hybrid (second node) | 85,385,428 | -1 | 23,463,948,288 (23.46) | 1,614,848 | 1,499,068 | 56,312 |
Source: xOne team measurement, 2026-11-14 19:20 UTC, Apothem.
The xOneC node reads 10,107,556 kB of VmRSS, but 9,793,144 kB of it is RssFile, mapped files. Compare its RssAnon, 349,504 kB, with the others. The two nethermind-xdc nodes read 1,673,928 kB and 1,499,068 kB of RssAnon. The xOne nodes read 489,112 kB (xOneRS), 166,264 kB (xOnePy) and 349,504 kB (xOneC). Datadirs: nethermind-xdc 23.66 GB and 23.46 GB; xOne 31.12 GB to 75.11 GB.
Does nethermind-xdc return the same RPC JSON as xOne?
The core fields are equal; the JSON shape is not. Block objects had equal hash, roots, number, miner, gas used and timestamp on all nodes: 40 of 40 for each. Every xOne node that answered returned whole-JSON equal results for 50 of 50 calls. The xOneRS Apothem snap node on the second host refused RPC after the head probe, so its row has no RPC result.
Each nethermind-xdc node matched the reference whole-JSON in 10 of 50 calls. The 40 other calls were block objects, and each differed in the keys below. The 10 equal calls are the 10 transaction counts.
| Network | nethermind-xdc nodes | JSON keys that differ from the reference (40 block objects each) |
|---|---|---|
| net2040 | A, B, C, archive, full (hybrid) | lacks penalties, validator, validators, parentBeaconBlockRoot, excessBlobGas, blockAccessListHash; adds totalDifficulty; size has another value |
| Apothem | hybrid, hybrid (second node) | lacks penalties, validator, validators; adds totalDifficulty; size has another value |
The reference JSON contains the XDC fields validator, validators and penalties. The nethermind-xdc JSON does not contain them. A tool that reads these fields needs a client that returns them. See the xOne RPC surface.
What does nethermind publish about these topics?
The claims below are from Nethermind and the fork notes. They are not measured here.
| Topic | Published claim | xOne fact |
|---|---|---|
| XDC fork releases | Releases v1.36.0-xdc.1 to v1.36.0-xdc.4 list an XDPoS V2 validator mode, eth/100 message ids, an Apothem follower and a minimal-disk follower, as stated in the private repository. | xOne has follower nodes on both networks, as the tables show. |
| State pruning | Pruning modes Hybrid and Full, as stated in Nethermind state pruning. | Full sync keeps the state of a recent window (sync modes). |
| Archive | Pruning.Mode None, as stated in the 2.0.0 release notes. |
--gcmode archive (flags.md). |
| Health check | A /health endpoint that returns 503 on NoPeers, as stated in Nethermind health check. |
/readyz returns 503 while the node is syncing (metrics.rs). |
What does this sample not show?
It shows one moment, with one node per mode on most rows. It has no sync times, no throughput and no time series of memory. No Apothem nethermind-xdc archive or full node was in the sample. The post uses the node labels, such as "memory pruning", and does not define them further. See which xOne client and networks.
Correction
On 2026-11-15 we removed an Apothem row that was labelled "xOneRS snap (second node)". That node reports the version xOne/v1.1.0/linux-amd64/go1.25.0: it runs xOneGo, the earlier Go line, not xOneRS. The other rows are unchanged.
Frequently asked questions
Do xOne and nethermind-xdc agree on block data?
Yes, on the core fields. Hash, roots, number, miner, gas used and timestamp were equal in 40 of 40 block objects for every nethermind-xdc node. The JSON shape differs in the XDC fields.
Which one uses less disk on net2040?
The nethermind-xdc nodes read 7.35 GB to 11.37 GB. The xOne full and archive nodes read 17.99 GB to 22.78 GB. The xOne snap, fast and minimal nodes read 0.09 GB to 0.15 GB.
Which one uses less heap?
On net2040 full nodes, xOne RssAnon is 58,476 kB to 277,000 kB. nethermind-xdc A reads 828,204 kB. On Apothem, xOne reads 166,264 kB to 489,112 kB and nethermind-xdc reads 1,499,068 kB and 1,673,928 kB.
Why does a nethermind-xdc block object differ from an xOne one?
Its JSON lacks penalties, validator and validators and adds totalDifficulty. On net2040 it also lacks three post-merge fields and reports another size. The core fields are equal.
Is the nethermind-xdc source public?
No. The repository, XDCIndia/xdc-nethermind-private, is private.
Sources
- xOne team measurement, 2026-11-14 19:20 UTC (no file link)
- XDCIndia/xdc-nethermind-private (private)
- Nethermind state pruning
- Nethermind 2.0.0 release
- Nethermind health check
- xOneRS docs/cli/flags.md
- xOneRS metrics.rs
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-vs-nethermind-xdc/index.md). GitHub may ask you to sign in. Report a correction opens a prefilled GitHub issue for this page.