net2040's V2 config sets a mine period of 2 seconds, and with all 14 seats sealing on time a block comes every 2 seconds. On 2026-11-15 the chain was slower: from block 845,272 to 852,472 it averaged 4.0 to 4.6 seconds per block. The cause is not timeouts. Two xOne seats, the Python one and the C++ one, sealed their blocks long after their parent, and every late seal delays the whole chain. We filed xOnePy#109 and xOneC#98 (private repositories). The data is read-only and comes from the geth-XDC reference node.

How slow was the chain?

From block timestamps and XDPoS rounds (eth_getBlockByNumber, XDPoS_getV2BlockByNumber):

REFERENCE TABLEScroll to explore all columns →
Blocks Time Seconds per block Rounds without a block
845,272 to 848,872 00:04 to 04:39 UTC 4.57 5
848,872 to 850,672 04:39 to 06:39 UTC 4.02 0
850,672 to 852,472 06:39 to 08:55 UTC 4.51 0

Almost every round made a block, so the time is not spent in round timeouts (see what a timeout looks like). Rounds simply took longer.

Which seats were slow?

The gap between a block's timestamp and its parent's, by the seat that sealed it, over the last 280 blocks before about 09:00 UTC (20 blocks per seat):

REFERENCE TABLEScroll to explore all columns →
Seat Client Average gap Largest gap
0xc33a xOnePy 27.3 s 31 s
0x00ce xOneC 13.55 s 25 s
0xfC71 xOneTS 3.8 s 8 s
five other seats geth-XDC and the xOneRS seat 2.25 to 2.9 s 3 to 7 s
six other seats geth-XDC 2.0 s 2 s

A block's timestamp is set when its producer builds it, so the gap shows when the producer started, not network delay. Two seats out of 14 that add 25 and 11 seconds each lengthen the average block by about 2.6 seconds, which matches the table above. The seat-to-client mapping is the one in four clients minting fair share.

Why are those seats late?

We do not know yet. Both producers run on the host that also runs builds, and its load average was 40 to 96 that day; the Python validator has missed turns under load before. But a late seal is not a missed seal: both seats still sealed every turn in this window, which is why the fair-mint share looked normal. The issues ask each client to log, per sealed block, how long it waited, built, executed and signed, so the slow phase can be found.

What does this mean for net2040 users?

  • Blocks come about every 4 to 4.5 seconds instead of 2, and two blocks in every 14 take on average 13.6 and 27.3 seconds.
  • Finality (the 3-chain QC rule) moves with the blocks, so it is slower too. See finality for exchanges and bridges.
  • This measurement covers net2040 only.

Frequently asked questions

Why is net2040 block time above 2 seconds?

On 2026-11-15, two xOne seats (Python and C++) sealed 13 to 27 seconds after their parent on average. No round timed out.

Did the Python validator miss turns?

Not in this 280-block window: it sealed each of its 20 turns, but on average 27 seconds after the parent.

How was the seal delay measured?

From block timestamps on a geth-XDC reference node: each block's timestamp minus its parent's, grouped by the sealing seat.

Sources

  • Read-only reads of block timestamps, miners and XDPoS rounds from a geth-XDC reference node and an xOneRS archive node, 2026-11-15.
  • xOnePy#109 and xOneC#98 (private repositories); net2040 V2 parameters in docs/spec/fork-table.md.