How to run and verify xOneRS, the Rust XDC client

What is xOneRS?

xOneRS is the Rust client of the xOne family. It is an XDC execution client rebuilt in Rust. The binary is xone. Read the introduction to xOneRS for the design. This post covers operation.

How do I install xOneRS?

You have two options: build from source, or download the release binary.

Build from source. The toolchain is pinned in rust-toolchain.toml (channel 1.94.0):

git clone https://github.com/XDCIndia/xOneRS.git
cd xOneRS
cargo build --locked --release -p xone
./target/release/xone --version

Or use the v0.1.0 release, published on 2026-11-12. It has two assets: xone-v0.1.0-linux-amd64 and SHA256SUMS.

V=https://github.com/XDCIndia/xOneRS/releases/download/v0.1.0
curl -fLO $V/xone-v0.1.0-linux-amd64
curl -fLO $V/SHA256SUMS
sha256sum -c SHA256SUMS
chmod +x xone-v0.1.0-linux-amd64
./xone-v0.1.0-linux-amd64 --version

Both files come from the same release page. The check finds a damaged download. It does not prove who built the file. The release has no signature file, and the release key is an open owner decision in the release guide. The release process post explains the stamp format.

How do I follow Apothem or net2040?

Start the node with a network name and a datadir. The node imports every block on its own state and serves JSON-RPC.

Apothem (chain 51). Builds from main embed the Apothem boot list and use it when no --bootnodes is given (bootnodes/mod.rs). The v0.1.0 binary has no built-in list, so pass the bootnodes from ops/bootnodes/apothem.txt in the repository:

./target/release/xone --network apothem --datadir ./apothem-data \
    --bootnodes "$(paste -sd, ops/bootnodes/apothem.txt)" --http

net2040 (chain 2040). The repository commits no public bootnode list for it. Use the enode of a net2040 peer:

./target/release/xone --network net2040 --datadir ./net2040-data \
    --bootnodes <enode-url> \
    --http --http.api eth,net,web3,XDPoS \
    --metrics --metrics.addr 127.0.0.1 --metrics.port 6060

To use the checks below on Apothem, add --metrics and --http.api eth,net,web3,XDPoS to its command. The Apothem guide and the net2040 guide give the full commands. For sync modes other than the default full, see sync modes in xOne. For systemd and Docker, see ops/install.md.

How do I check that the node is correct?

Run five checks. The follow guides use the first three.

1. Version stamp equals the tag. xone --version prints xOne/v0.1.0-9465ddb4-12112026/linux-x86_64/rustc1.94.0 for the v0.1.0 binary. 9465ddb4 is the first 8 characters of the commit that the v0.1.0 tag points to. The stamp must not contain unknown or -dirty. web3_clientVersion returns the same string. Code on main now builds the name xOneRS/ instead of xOne/.
2. Head against a reference node. Call eth_blockNumber on your node and on a geth-XDC node of the same network. The guides print local N archive M lag.
3. Block hashes equal. The guides call eth_getBlockByNumber with [h, false] on both nodes and compare the whole JSON. They also compare XDPoS_getMasternodesByNumber.

LOCAL=http://127.0.0.1:8545
REF=<reference-rpc-url>
h=0x4650   # block 18000; use a height your node has imported (needs jq)
q() { curl -s -H 'content-type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["'$h'",false]}' "$1" | jq -S .result; }
diff <(q $LOCAL) <(q $REF) && echo equal

In the net2040 guide, block 18,000 has hash 0x68e72f4b8a1b61aab2872966088a8383917721da51e27b3fc009fc56d5caf907. In the Apothem guide, block 1,064,000 has hash 0x1d6b0852cb097f36ff3e902cec5aaa4e37222c3fd55be28655bc0240bf4ce1e1. Both were equal to the archive node in those runs.

4. No refused block. The node refuses a block that differs from its header and sets the peer aside. The release guide's pass rule is grep -c "refused" <log> equal to 0, eth_syncing false, and a head within 10 minutes of the tip.
5. Host and health. Run xone doctor before a long sync. It is read-only and checks open-file and address-space limits, vm.max_map_count, the cgroup memory limit and disk headroom. It exits 1 when a check fails. This subcommand is on main. The v0.1.0 binary does not have it (unrecognized subcommand). Then read the metrics port: curl -i http://127.0.0.1:6060/readyz.

/readyz answers 200 ready only when the node has a head that is not too old, is not syncing, is not degraded and is not shutting down. Otherwise it answers 503 and names the causes, for example not ready: syncing. /livez answers 200 while the process runs.

How do other clients expose health and metrics?

What is not qualified?

The README, the Apothem guide and ops/install.md state the open items. Do not rely on xOneRS for these yet:

• A mainnet follow or mint.
• A 72 h producer soak.
• Full-history replay on real disk.
• Apothem from genesis to its head. The Apothem guide says it takes days at the measured rates. The recorded follow reached block 1,091,600.
• A timed install by a second person (issue #46).

--mine is allowed on Apothem and refused on mainnet (chain 50). A mint on a public network needs the owner's approval.

Frequently asked questions

Which Rust version builds xOneRS?

The version in rust-toolchain.toml: channel 1.94.0, with rustfmt and clippy. Build with cargo build --locked --release -p xone.

Does the release binary have a signature?

No. The v0.1.0 release has the binary and SHA256SUMS. The guide in ops/install.md describes a signed SHA256SUMS.sig, but the release key is an open owner decision.

How do I know the node did not accept a wrong block?

The node recomputes the state root, receipts root, bloom and gas used for each block and compares them with the header. It refuses a block that differs. You can also compare eth_getBlockByNumber with a geth-XDC node.

Is xone doctor in the v0.1.0 binary?

No. It is on main. The v0.1.0 binary answers unrecognized subcommand 'doctor'.