How to run an XDC validator on net2040 with xOne

How do I follow net2040 before I validate?

Start the node as a follower and let it reach the tip. A producer must be at the tip with peers before it signs.

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

Details:

• The repository commits no public net2040 bootnode list. Pass an enode you trust.
• The node recomputes every block. It refuses a block that differs from its own result and sets the peer aside (net2040-follow.md).

How do I import the signer key?

Run xone account import with a key file and a password file. xOneRS reads a geth keystore v3 file (scrypt light, scrypt standard or pbkdf2). It does not read version 1 or presale files. Convert those with geth first (keys.md).

xone account import key.hex --datadir ./net2040-data --password pw.txt
xone account list   --datadir ./net2040-data

• A password comes from a file only. There is no prompt and no environment variable.
• The keystore, the password file and nodekey need mode 0600 or narrower. A wider mode is refused.
• The reader reads at most 64 KiB and checks every field before it derives a key. It refuses an address field that differs from the key (keystore-intake.md).

What is the mint gate?

The mint gate is the rule set for the first signatures of a client on a live network. xOneTS, xOnePy and xOneC each keep a copy in docs/process/mint-gate.md. The main rules:

• One signer at a time. A key runs in one process on the whole fleet. Stop the old signer, confirm that no process holds the key, then start the next.
• Peer in first. The candidate is at the tip with 8 or more peers.
• Fast abort. On the first missed leader turn, stop within 45 to 60 seconds and return the seat.
• net2040 before Apothem. Mainnet minting is out of scope.

A borrowed seat is a seat that another signer holds. The candidate takes it for three leader turns, then gives it back. Three verified seals are a smoke test. An own seat is your validator. It continues into a soak. The proposed minimums, which the owner confirms, are 200 eligible turns, 72 hours, 3 epoch changes and 5 restarts (mint-gate.md).

Verify each seal with three checks:

1. The block timestamp is after the flip.
2. The next block names it as parent, and it is canonical on an independent node.
3. The candidate's own log has a line producer block N <hash> sealed and sent.

The V2 leader of round r is masternodes[r % epoch % len] (schedule.md).

How do I start the producer?

Restart the follower command with the key flags added:

--mine --keystore <keystore-file> --password <password-file> \
--miner.etherbase 0x<validator-address>

--keystore names one keystore file. --mine needs --keystore and --password. It does not pick a key from the datadir (flags.md).

Which chains allow --mine?

The xOneRS producer allows --mine on net2040 (2040) and Apothem (51). It refuses mainnet (chain id 50) with a typed error.

Commit ebe34ef (on main) changed plan() in producer.rs. It now refuses only chain id 50. Mainnet is refused with a typed error. net2040 (2040) and Apothem (51) are allowed (producer.rs).

How does the signer avoid a double sign?

The signer keeps a safety record that is written and synced before each signature exists, and it waits for a quiet window at every start. The record is proposed, not final.

ADR-010 describes the rules against a double sign. Its status is "proposed". The producer opens its record under <datadir>/xone/safety.

• The record is written and synced before the signature exists.
• Every field only rises. Unwind, SetHead and a restore of chain data do not touch it.
• One directory holds one key. A new key needs a new directory.
• At every start the signer waits for a quiet window: 120 s on net2040. In that time it counts only seconds with valid gossip from a peer. It looks for signatures of its own key from another process. It raises its record to what it sees and restarts the wait. Log line when the wait ends: fence open: the quiet window passed, signing starts. --miner.quietwindow can only raise the window.
• Do not copy safety back from a backup. A signature that reached no peer leaves no trace, and a restore from before it can sign another block for that round (ADR-010, residual risk R1).

After a kill -9, the producer finds pending.rlp, signs the same bytes again and sends one block. The local devnet run sealed 59 heights, each one time (first-mint-local.md).

How do I stop or hand off a seat?

Stop the old signer with SIGTERM, confirm that no process holds the key, wait one block, then start the new one. Do not run one key in two processes.

• Stop with SIGTERM. The node writes a checkpoint and syncs its files.
• To move the seat: stop the old signer, confirm that no process holds the key, wait one block, then start the new one (keys.md, mint-gate.md).
• Do not leave a seat idle across an epoch boundary. A masternode that seals no block in a whole epoch is penalised and leaves the list. An epoch is 900 rounds on net2040.
• A restart costs turns, because the node must peer and catch up before it seals. The devnet rehearsal advises a restart right after one of the seat's own seals (gate-d-rehearsal.md).

How do the four clients differ?

xOneRS needs a restart with --mine. xOneTS and xOnePy start as followers with the key encrypted in standby, and xOneC accepts --mine at launch or miner_start. The table lists each client.

Sources: net2040-ts-mint.md, net2040-py-mint.md, apothem-snap.md. The xOnePy and xOneC copies of the mint gate do not mention the hot switch. The xOneTS copy does.

A cross-host fence for one key is an open item in the xOneTS and xOnePy records. The xOneC devnet run does not exercise it. The quiet window is a wait with observation. It is not a lock (ADR-010 section 8). Keep to the one-signer rule.

Which seats do the four clients hold on net2040?

All four clients hold seats on net2040, per the hourly tracker. The tracker is the live record.

The hourly tracker of 2026-11-14T18:30Z (xOneRS#140) lists seats held on net2040. Rust: since 2026-11-12 03:28Z, 0 misses. xOneTS own seat: since 2026-11-13T12:24Z, 1847 seals, 4 misses. xOnePy: since 2026-11-14T13:03Z, 314 seals, 0 misses. xOneC: since 2026-11-13T15:06Z, 908 seals, 0 misses.

What do other XDC validator guides say?

The XDC masternode docs and the other client docs describe validators in their own terms. The table puts each claim beside the xOne fact. The networks and consensus engines differ, so read each row as a description, not as a test result.

For a client choice, see which xOne client to use and the node operations guide.

Frequently asked questions

How do I start an XDC validator on net2040 with xOne?

Follow net2040 to the tip, import a geth keystore v3 signer key with xone account import, then restart with --mine, --keystore, --password and --miner.etherbase. A borrowed seat runs three leader turns first. An own seat continues into a soak.

Which chains allow --mine in xOneRS?

net2040 (2040) and Apothem (51) allow it. Mainnet (chain id 50) is refused with a typed error.

Can two processes sign with the same key?

No. A key runs in one process on the whole fleet. Stop the old signer, confirm that no process holds the key, then start the next. The quiet window is a wait with observation, not a lock.

What happens if a seat sits idle for an epoch?

A masternode that seals no block in a whole epoch is penalised and leaves the list. An epoch is 900 rounds on net2040.