Every hour, one script reads the head of every xOne node on net2040, compares it with the tip of the Rust archive node, checks whether the node is active on the network's stats board, adds its mint status, and posts the table as a comment on XDCIndia/xOneRS#140. The four clients (Rust, TypeScript, Python, C++) and every sync type (full, snap, fast, minimal, archive) appear in one table. This post explains each column and its limits.
The block-share numbers posted on the same issue use a different count; see how fair mint is measured.
What does one row show?
| Column | Where it comes from |
|---|---|
| Client, Type, Node | a fixed list of nodes in the script; one row per node, also for a sync type that is "not built" |
| Head | eth_blockNumber on the node's RPC; down when there is no answer in a few seconds |
| Lag | the tip minus the head; the tip is the head of the Rust archive node at that moment |
| Board | yes when the network's stats board lists the node name as active |
| Mint on net2040 | a status line per client and type, from a status file |
The issue body describes the same flow: heads over RPC, board flags, mint rows, a markdown table, an issue comment.
How should the lag be read?
Lag is measured against one node, the Rust archive node, so it is relative: a negative lag means the node reported a higher head than the archive node at that second. A full node with a lag in the hundreds of thousands is syncing from genesis, as the table footer says. One sample per hour does not show short stalls.
Where does the mint column come from?
From a status file, not from a live check. The issue body says the file is edited when a seat test passes, and the next hourly comment carries it. Entries record results such as "3/3" verified seals on a borrowed seat (the Gate E smoke test), or a seat held since a time with its seal and miss counts. For the seat that the TypeScript client holds as its own validator, the script refreshes the seal and miss counts from that node's seat-watch log each hour. How a seal is verified is in the net2040 validator guide.
What does the board flag tell me?
Whether the stats board shows the node as active. Nodes report to the board through their ethstats client; see monitoring an xOne node. A node can be at the tip and still show no if its ethstats connection is down.
What rules come with the tracker?
The issue body sets them: do not post the table by hand; edit the node list when a node is added or a port changes; and a node that is down two hours in a row is a defect, so open an issue on that client's repository.
What does the tracker not show?
- Block share per seat: that is a separate count from the archive node's miner of every block, posted as its own comment.
- Memory, disk or RPC correctness: those are in the fleet snapshot.
- Anything between two hourly samples.
The collected competitor articles state no claim about a multi-client tracker, so this post has no comparison table.
Frequently asked questions
Where is the hourly net2040 tracker?
As comments on XDCIndia/xOneRS#140. The newest comment is the current state.
What does "down" mean in the tracker?
The node's RPC did not answer eth_blockNumber within a few seconds when the script ran. Two hours in a row is treated as a defect.
Is the mint column a live verification?
No. It comes from a status file that is updated when a seat test passes. Only the TypeScript validator row is refreshed from its seat-watch log each hour.
Why can the lag be negative?
The tip is the head of one reference node at that moment. A node that has already imported the next block reports a higher head, so its lag is negative.
Sources
- XDCIndia/xOneRS#140: issue body (What, Prompt, Workflow, Loop, Flow) and the hourly comments
- How fair mint is measured on net2040
This article describes the source and evidence at its review date. Check the linked repository for current implementation and qualification status.
Explore the engineering evidenceEdit this page on GitHub opens the Markdown source (content/blog/net2040-hourly-tracker/index.md). GitHub may ask you to sign in. Report a correction opens a prefilled GitHub issue for this page.