Four xOne clients minting fair share on XDC net2040

Did the four xOne clients mint a fair share on net2040?

Yes, in one 14-seat era. The Rust client sealed 7.24% of blocks, C++ 7.13%, Python 7.12% and TypeScript 7.11%, against a fair share of 7.14%.

Source: the fair-mint comment on xOneRS#140, posted 2026-11-14T17:55Z. An earlier comment of 16:55Z says these counts come from the Rust archive node, which reads the miner of every canonical block.

Window: the whole 14-seat era, blocks 814,798 to 840,174. That is 25,377 blocks in 14.1 hours. Fair share is 1,813 blocks, or 7.14%.

The last column is the block count minus 1,813. We computed it from the source numbers.

The same comment says the two geth seats at 7.24% took the turns the Python seat lost in its 27-minute outage.

What do seat, fair share, seal and miss mean?

A seat is one slot in the masternode list. Fair share is the blocks in a window divided by the seats. A seal is a block that a client signed on its seat. A miss is an eligible leader turn without a seal.

• Seat: one slot in the masternode list. Leader turns follow round % 900 % N, where N is the list size. One epoch is 900 rounds on net2040 (mint gate, xOneTS).
• Fair share: the blocks in a window divided by the seats. Here that is 25,377 blocks over 14 seats, which the comment states as 1,813.
• Seal: a block that a client signed on its seat. The mint gate checks each seal three ways: the block is stamped after the flip, the next block links to it as its child on an independent node, and the client's own log shows the same number and hash.
• Miss: an eligible leader turn without a seal from that seat. The rulebook asks for every miss to be recorded with a cause.

What does the latest tracker show?

The hourly tracker on xOneRS#140 is the live record. Its newest comment of 2026-11-14T18:30Z lists seals and misses for each seat.

The hourly tracker on the same issue is the live record. Newest comment: 2026-11-14T18:30Z, net2040 tip 840,762. Seals and misses count from the date in the "Seat held since" column.

Three notes on this table:

• The Python count starts at 13:03Z, after the outage. The 314 seals do not cover the earlier part of the era.
• The tracker lists 0 misses for the Rust seat. A comment on xOneRS#47 of 2026-11-13T04:27Z records one miss, at round 801002. The cause was a planned restart at an epoch boundary. The team classed it as host or environment, not a candidate fault.
• The 7,000-block window in the 16:55Z comment (ending at block 839,216) shows the same pattern: Rust 507, TypeScript 500, C++ 499 and Python 487 blocks, against a fair share of 500.

How does a client take a seat?

A client takes a borrowed seat for three leader turns, then returns it. A client with its own seat continues into a soak. Each test needs owner approval.

The tracker records a borrowed-seat test of 3 of 3 seals for Rust, C++, Python and TypeScript. Each test needs owner approval. The rules in the mint gate include:

• One signer per key across the whole fleet.
• The candidate is at tip with 8 or more peers before the switch.
• On the first missed turn, stop within 45-60 s and return the seat.
• Mainnet minting is out of scope.

The TypeScript seat 0xfC71 is its own seat. The tracker says it has held it since 2026-11-13T12:24Z, and the seat joined the set at epoch 814,798 (#140, 2026-11-14T16:55Z comment).

What does this result not show?

It does not show mainnet behaviour, long-run stability, or block-building speed. It is a devnet, and the window is 14.1 hours.

• It is a devnet. The result says nothing about mainnet. The Rust producer refuses --mine on chain id 50 (producer.rs). The mint gate says mainnet minting is out of scope.
• It is a short window. The era is 14.1 hours, and fair share is 1,813 blocks per seat. The proposed soak minimums are 200 eligible turns, 72 hours, 3 epoch changes and 5 restarts. The owner has not confirmed them (reconciliation, row G5).
• Zero misses is not a guarantee. With n eligible turns and no misses, the 95% upper bound on the miss rate is about 3/n (mint gate).
• Fair share measures turn-taking. It does not measure block-building speed or load. The net2040 state is small: 72 MB in the sync-mode measurements (reconciliation, row G3).
• No gate is closed. The reconciliation, written against main at dd5548f on 2026-11-14, lists no milestone M0-M8 and no gate A-E as done. The Gate E soak is open on xOneRS#47. Apothem soak has not started, although --mine is allowed on chain id 51 after PR #142.

How do other clients report fair share?

The XDC geth fork and erigon-xdc published fair-share results for their mint releases. Both used a 7-member set, not 14 seats, so the percentages are not like for like.

A share on a 7-member set is about twice a share on 14 seats. Compare each result with the ideal share for its own set.

The geth fork row counts 900 blocks. The xOne row counts 25,377 blocks.

For the client details, see the four xOne clients and which xOne client to use. For the networks, see the network list.

Frequently asked questions

What fair share did the xOne clients get on net2040?

Over blocks 814,798 to 840,174, the Rust client sealed 7.24%, C++ 7.13%, Python 7.12% and TypeScript 7.11%. Fair share was 1,813 blocks, or 7.14%.

What is fair share in block production?

Fair share is the blocks in a window divided by the seats. Here that is 25,377 blocks over 14 seats, which the tracker comment states as 1,813.

Does this result apply to XDC mainnet?

No. net2040 is a devnet. The Rust producer refuses --mine on chain id 50, and the mint gate says mainnet minting is out of scope.

How do the xOne results compare with the XDC geth fork?

The XDC geth fork reports 128 of 900 blocks (14.2%) on a 7-member private net. The sets differ in size, so the percentages are not like for like. xOne measured 7.11% to 7.24% against a fair share of 7.14% on 14 seats.