How to run an XDC Apothem follower with xOne: measured

How do I run an xOne follower on Apothem?

Build xOneRS and start it with the Apothem bootnodes. The node imports each block on its own state and serves JSON-RPC.

The README quick start gives the command:

cargo build --locked --release -p xone
./target/release/xone --network apothem --datadir <datadir> \
    --bootnodes "$(paste -sd, ops/bootnodes/apothem.txt)" --http

The code on main now embeds the Apothem and mainnet boot lists from ops/bootnodes/*.txt and uses them when no --bootnodes is given (bootnodes/mod.rs, issue #619). The Apothem guide records an earlier build: without --bootnodes it had no peer after 3 minutes; with the 28 geth-XDC bootnodes, the first peer connected within seconds. Passing --bootnodes still works. See also run a node.

How long does a full sync from genesis take?

The guide records no total. It says 85.27 million blocks "takes days at these rates". The team has not measured it.

The guide records the first million blocks, run on 2026-11-12 on a shared host: 214 blocks per second on average over the first million V1 blocks, resident memory 1.1 to 1.2 GB, and a datadir of 1.7 GB at block 1,066,000. That run had not reached the V2 switch at block 56,828,700.

How do I follow Apothem with snap sync?

Add --syncmode snap. On an empty datadir, the node downloads the state at a pivot over snap/1, proves every range, and executes from the pivot plus one. From geth-XDC peers it also needs --snap.gap-rpc.

xone --network apothem --datadir <datadir> --syncmode snap \
    --bootnodes "$(paste -sd, ops/bootnodes/apothem.txt)" \
    --snap.gap-rpc <archive-rpc> --http

The flags reference says --snap.gap-rpc takes an archive RPC that serves eth_getProof. It supplies the state of the gap blocks below the pivot. With no xOne peer and no such RPC, the start fails with a typed error. The support matrix marks Apothem sync modes "not-qualified" in xOneRS. The measurements below are not that qualification.

What do the other xOne clients document for Apothem?

xOneC has an Apothem snap page with a run. xOneTS and xOnePy have notes.

• xOneC: the page records a run of 2026-11-13 from an empty datadir, with a geth peer and a nethermind peer as sources. The download took 25 min and the root moved 8 times. The datadir after install was 42 GB, and the peak need on the host was about 85 GB. xOneC has no discovery: the bootnode list is its peer set. The run stopped at block 85,346,195 on a transaction that needs the bn254 precompiles. They were added, and the node reached the tip.
• xOneTS: notes say Apothem needs about 35 GB free during snap sync.
• xOnePy: notes keep the download rows on disk. Its sync-modes page lists "Apothem by snap" under "Not covered".

What did the xOne team measure on its Apothem followers?

Two read-only samples on 2026-11-14, at 19:20 and 19:33 UTC. The reference is a geth-XDC snap node. Its head was 85,385,427 at 19:20 and 85,385,812 at 19:33. Lag is the reference head minus the node head. A lag of -1 means the node answered one second after the reference.

Source: xOne team measurement, 2026-11-14. The RssAnon and RssFile split is from a second pass on the same day.

The xOneC VmRSS is mostly RssFile, the mapped MDBX file.

Do the RPC answers match the reference?

Yes, in the first sample. At 19:20, the xOneRS snap, xOnePy snap and xOneC snap nodes each answered 50 of 50 calls with JSON equal to the geth-XDC snap node (method above). The second xOneRS node refused RPC at 19:20 because its process had exited. A later start answered at 19:33. No RPC compare was taken at 19:33.

How do the other clients compare in the same sample?

The modes differ, so these rows give context and not a ranking. This is the 19:20 UTC sample. See also xOne vs geth-XDC.

The probe read head 0 for erigon-xdc minimal. This post does not explain it.

What is not measured?

The samples show nodes that were already at the head. They do not show how a node got there.

• Sync time from an empty datadir on Apothem. The xOneRS guide covers the first million blocks. The xOneC page covers one snap run.
• A full-sync xOne follower. All xOne rows are snap.
• A time series. Two samples, 13 minutes apart.
• Apothem minting. Apothem allows --mine, but a public run needs the owner's approval. No xOne mint on Apothem is recorded here.

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

Can xOne follow Apothem from genesis?

Yes. xone --network apothem with the Apothem bootnodes imports every block from genesis. The guide says this takes days. The team has not measured the total.

Does snap sync on Apothem need an archive node?

From geth-XDC peers, yes. --snap.gap-rpc needs an archive RPC that serves eth_getProof. With no xOne peer and no such RPC, the start fails with a typed error.

How much disk did the xOne Apothem followers use?

The xOneRS node used 75.11 GB, the xOnePy node 31.12 GB and the xOneC node 51.05 to 51.12 GB. The geth-XDC reference used 154.13 GB.