To choose an xOne sync mode on XDC, start from what the node must do. Use archive for reads of old state. Use snap or minimal for the smallest disk and the shortest start. Use full if you want to execute every block from genesis with no pin file. The xOneTS, xOnePy and xOneC repositories are private, so their links need access. This post describes what is on main today.

Sync modes explains how each mode works, archive mode explains the history tables, and snapshot bootstrap gives the import steps. This post only helps you choose.

Which mode fits what I need?

Each cell has one fact. The last column gives the source.

REFERENCE TABLEScroll to explore all columns →
You need full snap (fast = snap) minimal archive Sources
A validator Yes. Seals verified on net2040 in all four clients (xOneRS holds a seat) Yes. Seals verified in all four clients: 3 of 3, or a held seat Yes. 3 of 3 on a borrowed seat, all four clients xOnePy, xOneC: 3 of 3. xOneTS: not at the tip yet. xOneRS: the tracker row predates the archive store tracker, flags (--mine, --keystore)
RPC for recent blocks Yes, inside the state window Yes, from the pivot up. eth_getLogs has nothing below pivot + 1 Yes, same as snap Yes, any block flags (--gcmode), retention (derived window, row 16)
Historical state reads No. Older blocks get unsupported history No. State starts at the pivot No. Older data is deleted Yes: eth_getBalance, eth_getTransactionCount, eth_getCode, eth_getStorageAt, eth_call archive guide, snapshot guide
Smallest disk 18.00 to 20.65 GB on net2040 0.11 to 0.16 GB on net2040 0.11 to 0.16 GB on net2040 22.23 to 22.79 GB on net2040 xOne team measurement, 2026-11-15 01:50 UTC
Fastest start About 95 minutes from genesis to the tip (net2040) About 20 s from start to the tip (net2040) 13 s to follow to the tip after the import (net2040). The file transfer is extra From genesis. No start time is recorded net2040 sync modes, snapshot guide
No trusted pin or peer list Yes. It runs every block from genesis Yes with --snap.pins unset: two peers must serve the same epoch-switch header. Pins are recommended beyond test networks No. The import is refused without --pins Yes. Same as full flags (--syncmode, --snap.pins), snapshot guide

Notes on the table:

  • The start times come from single runs on net2040, which has a small state. The Apothem import target of 15 minutes is not measured yet.
  • Snap from a geth-XDC peer needs --snap.gap-rpc, an archive RPC that serves eth_getProof. Every proof is checked against the header, so the RPC is not trusted. Without an xOne peer and without that flag, the start fails with a typed error.
  • A minimal node keeps the window that the chain rules derive. On Apothem at pivot 84,000,000 that is 4,500 headers, 1,799 bodies, no receipts and 3,149 gap snapshots (retention).
  • The archive store does not serve eth_getProof below the window, snap/1 at old roots or the tracers yet.

How much disk does each mode use?

On net2040, snap and minimal nodes hold about 0.1 to 0.2 GB. Full nodes hold 18 to 21 GB and archive nodes hold 22 to 23 GB.

REFERENCE TABLEScroll to explore all columns →
Client full snap / fast minimal archive
xOneRS 20.65 GB 0.16 GB (fast row) 0.16 GB 22.79 GB
xOneTS 19.58 GB not in the sample not in the sample not in the sample
xOnePy not in the sample 0.11 GB 0.11 GB not in the sample
xOneC 18.00 GB 0.15 GB 0.15 GB 22.23 GB

Source: xOne team measurement, 2026-11-15 01:50 UTC, net2040 at head 846,739 (fleet snapshot). The xOnePy snap node was 2 blocks behind. The other nodes in the table were at the head.

Do not carry these sizes to Apothem. The net2040 state is small. In the same sample, the Apothem snap nodes held 31.22 GB (xOnePy), 52.62 GB (xOneC) and 75.21 GB (xOneRS) at head 85,396,805. The xOnePy Apothem build had no git data, so it was a follower and not a release. The sample has no xOne full or archive node on Apothem.

Which modes does each client have?

All four clients accept --syncmode full|snap|fast, --minimal and --gcmode archive. No mode is missing. fast is an alias of snap in every client, as in geth-XDC.

REFERENCE TABLEScroll to explore all columns →
Client --syncmode snap --syncmode fast --minimal --gcmode archive
xOneRS Yes Alias of snap Yes Yes. Merged in PR #416 on 2026-11-14
xOneTS Yes Alias of snap, logged as such Yes Yes. The tracker node was still syncing from genesis
xOnePy Yes Alias of snap. No node deployed Yes Yes. Node at the tip, 124 of 124 historical reads equal
xOneC Yes Alias of snap. No node deployed Yes Yes. Node at the tip, 245 of 245 historical reads equal

Sources: xOneRS flags, xOneTS config.ts, xOnePy config.py, xOneC config.cpp, and the tracker comment of 2026-11-15 01:30 UTC. All four refuse --gcmode archive with snap, fast or --minimal, and it needs an empty datadir.

Which networks are qualified?

The xOneRS support matrix marks mainnet as not qualified for any role, and signing on chain 50 is refused. Sync modes and archive show working on net2040 and on a private network. They show not-qualified on Apothem. Signing on Apothem and net2040 needs the owner's approval first (support matrix). The sample above shows xOne snap nodes at the Apothem head, so the matrix records evidence pages, not what runs.

Frequently asked questions

Which mode gives the smallest disk?

Snap and minimal. On net2040 they held 0.11 to 0.16 GB. Apothem snap nodes held 31.22 to 75.21 GB, so test on your network.

Can I add archive history to a snap node later?

No. --gcmode archive needs an empty datadir and a full sync from genesis. A snap or minimal datadir has no history below its anchor.

Do I need a pin file for snap sync?

Not to start. With --snap.pins unset, two peers must serve the same epoch-switch header. The flag reference recommends pins beyond test networks. A minimal import always needs --pins.

Can a validator run on a minimal node?

On net2040, minimal nodes of all four clients sealed 3 of 3 turns on a borrowed seat. Signing on mainnet is refused, and on Apothem and net2040 it needs owner approval.

Sources