How to run and verify xOneTS, the TypeScript XDC client

What is xOneTS?

xOneTS is one of the four xOne clients. It is one binary, xonets, built from a Bun workspace of packages: chainspec, EVM, consensus, db, net, sync, builder, signer, node and others (CHANGELOG). The overview is in xOneTS: the protocol, in a familiar language. To pick between clients, read which xOne client.

The release is v0.1.0, published on 2026-11-12. The documented live network is net2040.

How do I get the binary?

Build it from a clean checkout, or take the release asset.

git clone https://github.com/XDCIndia/xOneTS.git
cd xOneTS
bun install --frozen-lockfile
bun bin/build.ts dist/xonets

The first argument of bin/build.ts is the output path. The default is dist/xonets (release rulebook).

The v0.1.0 release holds two files: xonets-v0.1.0-linux-amd64 and SHA256SUMS. The release is in the private repository. Check the binary against SHA256SUMS before you run it.

How do I follow net2040?

Start the binary with --network net2040. The default network is mainnet. This is the node command line from the net2040 node record, with placeholders for paths and names:

xonets --network net2040 --datadir <datadir> --port 30340 \
  --http --http.addr 127.0.0.1 --http.port 8575 --http.api eth,net,web3,XDPoS \
  --ws --ws.addr 127.0.0.1 --ws.port 8576 --identity <node-name> \
  --metrics --metrics.addr 127.0.0.1 --metrics.port 6075

The node does not mine or sign unless you pass --mine. The --ethstats flag takes name:secret@host:port. Keep the secret in an environment variable.

Which sync modes does xOneTS run?

It runs full, snap, fast, minimal and archive. Full is the default. The sync modes post compares all four clients.

Snap sync on an empty datadir:

xonets --network net2040 --datadir <datadir> --bootnodes <enode-url> --syncmode snap

If no peer serves xpre/1, snap refuses with NoXpre after 120 s. It does not fall back to full sync (sync modes record). A datadir that already holds a chain continues that chain.

For minimal mode, export from a snap node and import on the new node:

xonets snapshot export --network net2040 --datadir <datadir> --out <snapshot-file>
xonets snapshot import --network net2040 --datadir <new-datadir> --in <snapshot-file> --pins <pins-file>

The pins file holds one <number> <0x hash> pair per line. On 2026-11-12 (build 56141480), a resync from empty took 17.8 s for snap, 40.2 s for fast and 17.1 s for minimal. The fast run waited 20 s for the second pivot witness to connect.

How the flags compare, as the other projects document them:

How do I verify the node?

Check four things in order.

1. The version stamp. Run xonets --version. It prints the stamp:

xOneTS/v<semver>-<commit8>[-dirty]-<DDMMYYYY>/<os>-<arch>/bun<version>

A release binary shows the tag, the commit of the tag and the UTC build date. A -dirty suffix or 00000000 means a failed build. The startup self-test line must show impl=native on linux-x64. The same stamp goes to web3_clientVersion, the P2P hello, ethstats and xone_build_info (release rulebook). See also how xOne releases are made.

2. The stats board. The clientVersion of the node's entry on https://skynet.xdcindia.com/old/stats?net=2040 must equal the stamp. The entry also shows syncMode and gcMode. The board can lag: on 2026-11-12 it showed an old stamp for a while after a restart.

3. Head against a reference. Poll eth_blockNumber on your node and on a reference node of the same network.

curl -s -H 'content-type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' http://127.0.0.1:8575

The recorded bar was lag of 1 block or less in at least 95 % of samples taken every 2 s over 15 min. The run of 2026-11-12 (build e87ab35e) gave 450 samples, 100 % at 1 block or less, maximum 1.

4. Parity records. On 2026-11-12 the same node returned whole eth_getBlockByNumber(n, true) objects equal to the archive at 7 of 7 heights, and equal XDPoS_getMasternodesByNumber at the head. The replay runner, xonets-replay, executes archive blocks on its own state and compares roots (RUNS.md):

The replay gate post explains the method.

What are the known gaps?

• XDPoS_getMasternodesByNumber below the retained window returns a plain error string, not the typed unsupported history error (#52, open).
• The native secp256k1 addon is embedded for linux-x64 glibc only. Other builds use the pure-JS path, which the node logs at start.
• eth_getProof is out of scope, and eth_call refuses state overrides.
• The archive node serves snap roots of the last 4,096 blocks only.
• --mine is refused on chain id 50 until Gate D. The borrowed-seat test on net2040 sealed 12 blocks in 13 eligible turns. The CHANGELOG calls it a smoke test, not reliability evidence.

Frequently asked questions

Is the xOneTS repository public?

No. The xOneTS repository is private. Links to it need access. The release v0.1.0 is in the same repository.

Which command prints the xOneTS version?

xonets --version prints the stamp. The stamp format is xOneTS/v<semver>-<commit8>[-dirty]-<DDMMYYYY>/<os>-<arch>/bun<version>.

Does --syncmode fast differ from snap?

No. fast is an alias of snap, as in geth-XDC.

Can a snap sync fall back to full sync?

No. If no peer serves xpre/1, snap sync refuses after 120 s with NoXpre.

How do I know the node follows the chain?

Compare eth_blockNumber with a reference node on the same network. Check that clientVersion on the stats board equals xonets --version.