We sampled the head of a reth-xdc minimal node on Apothem nine times from 2026-11-14 19:20 UTC to 2026-11-15 04:16 UTC, against a geth-XDC reference node. For the first seven samples, over almost seven hours, the gap stayed between 48,719 and 48,989 blocks: the node kept pace with the chain but did not gain. From 02:05 UTC it began to gain, and at 04:16 UTC it was 44,604 blocks behind. If the last rate holds, it reaches the tip in about 22 hours. That estimate rests on two hours of data.
The measurement is read-only: eth_blockNumber on each node's local RPC. The reth-xdc node runs on host C, the geth-XDC reference on host B. For the method of the fleet probe, see the fleet snapshot of 2026-11-15.
What do the samples show?
| Time (UTC) | reth-xdc head | geth-XDC head | Gap (blocks) |
|---|---|---|---|
| 11-14 19:20 | 85,336,632 | 85,385,427 | 48,795 |
| 11-14 19:33 | 85,336,888 | 85,385,812 | 48,924 |
| 11-14 19:43 | 85,337,400 | 85,386,119 | 48,719 |
| 11-14 19:57 | 85,337,528 | 85,386,513 | 48,985 |
| 11-15 01:50 | 85,347,991 | 85,396,805 | 48,814 |
| 11-15 01:56 | 85,348,119 | 85,396,990 | 48,871 |
| 11-15 02:05 | 85,348,247 | 85,397,236 | 48,989 |
| 11-15 04:07 | 85,355,927 | 85,400,782 | 44,855 |
| 11-15 04:16 | 85,356,439 | 85,401,043 | 44,604 |
The two nodes are read a fraction of a second apart, so one sample can be off by a block or two.
How fast is it catching up?
- 19:20 to 02:05 (6 h 45 min): reth-xdc advanced 11,615 blocks and the chain 11,809. The gap grew by 194 blocks. Both moved at about 29 blocks a minute, the chain's own rate at its 2-second block time.
- 02:05 to 04:16 (2 h 11 min): reth-xdc advanced 8,192 blocks and the chain 3,807. The gap fell by 4,385 blocks, about 33.5 blocks a minute.
- 04:07 to 04:16 (9 min): the gap fell by 251 blocks, about 28 blocks a minute.
When will it reach the tip?
At 33.5 blocks a minute, 44,604 blocks take about 22 hours, so around 2026-11-16 02:30 UTC. Read this with care:
- The rate comes from the last two hours only. Before that the node did not gain at all for almost seven hours.
- The samples do not show why the rate changed at about 02:00 UTC. The process was not restarted: it had run for about 88.7 hours at the last sample.
- Host C also runs other nodes. Its load changes over the day, and the samples do not record it.
We will add the next fleet samples to the series and check the estimate against them.
Does the node use more memory or disk while it catches up?
Not much in this window. Resident memory (VmRSS) stayed between 5,632,736 and 5,701,076 kB, about 5.4 GiB, in all nine samples. The datadir grew from 123.64 GB to 123.81 GB between the first and the eighth sample (the ninth sample did not measure disk).
Frequently asked questions
Is reth-xdc stuck on Apothem?
No. It kept pace with the chain for seven hours and has gained on it since about 02:00 UTC on 2026-11-15. It was 44,604 blocks behind at 04:16 UTC.
When will the reth-xdc node reach the Apothem tip?
At the last measured rate, in about 22 hours, around 2026-11-16 02:30 UTC. The rate is from two hours of data.
How was the gap measured?
eth_blockNumber on the reth-xdc node and on a geth-XDC reference node, read at the same time.
Why is the gap not exact?
The two reads are a fraction of a second apart, and Apothem makes a block about every 2 seconds.
Sources
- Fleet probe time series, 2026-11-14 19:20 UTC to 2026-11-15 04:16 UTC (read-only,
eth_blockNumber,/procRSS,du). - Fleet snapshot of 2026-11-15, xOne vs reth-xdc.
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/reth-xdc-apothem-catch-up/index.md). GitHub may ask you to sign in. Report a correction opens a prefilled GitHub issue for this page.