What a timeout looks like on net2040: reading a skipped round over RPC

What does XDPoS_getV2BlockByNumber return?

For a V2 block: hash, number, round, masternodes (the epoch's list) and encodedQC, the block's QC as RLP in base64.

curl -s -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"XDPoS_getV2BlockByNumber","params":["0xcc258"]}' \
  http://127.0.0.1:8545

0xcc258 is block 836,184. We read these blocks from an xOneRS net2040 archive node on 2026-11-15.

Which round has no block?

Block 836,184 certifies round 829,629 but has round 829,631. Round 829,630 ended without a block. The block time jumps 61 seconds, from 12:35:48 to 12:36:49. On net2040 the V2 timeout period is 60 seconds and the block period 2 seconds (fork table).

Whose turn was round 829,630?

The leader of round r is masternodes[r % epoch % len(masternodes)] (v2-masternodes-and-leader.md). On net2040 the epoch is 900 rounds and this epoch had 14 masternodes.

• Round 829,629: 829,629 % 900 = 729, 729 % 14 = 1, so 0x042b…a5f8. It mined block 836,183.
• Round 829,630: 730 % 14 = 2, so 0xc33a…f976.
• Round 829,631: 731 % 14 = 3, so 0xa0ea…4ed0. It mined block 836,184.

The formula gives the actual miner of the blocks on both sides. Seat 0xc33a is the Python validator's seat. Its node had stopped at 12:35:26 UTC, 22 seconds before block 836,183. See the week 46 incident log.

How do I decode the QC?

encodedQC is base64 of the RLP list [[hash, round, number], [signatures...], gapNumber]. This short Python decoder needs no library:

import base64

def rlp(b, i=0):
    x = b[i]
    if x < 0x80: return b[i:i+1], i + 1
    if x < 0xb8: n = x - 0x80; return b[i+1:i+1+n], i + 1 + n
    if x < 0xc0:
        k = x - 0xb7; n = int.from_bytes(b[i+1:i+1+k], "big"); s = i + 1 + k
        return b[s:s+n], s + n
    if x < 0xf8: n, s = x - 0xc0, i + 1
    else:
        k = x - 0xf7; n = int.from_bytes(b[i+1:i+1+k], "big"); s = i + 1 + k
    out, j = [], s
    while j < s + n:
        v, j = rlp(b, j); out.append(v)
    return out, s + n

(info, sigs, gap), _ = rlp(base64.b64decode(encoded_qc))
print("block", int.from_bytes(info[2], "big"), "round", int.from_bytes(info[1], "big"),
      "signatures", len(sigs), "gap", int.from_bytes(gap, "big"))

For block 836,184 it prints: block 836,183, round 829,629, 10 signatures, gap number 834,750. The QC is 722 bytes.

Is 10 signatures enough?

Yes. The certificate threshold on net2040 is 0.667 and the epoch has 14 masternodes. 14 × 0.667 = 9.34, so 10 distinct signers pass. The comparison is a float comparison with no rounding step (v2-certificates.md).

How many rounds in that epoch ended without a block?

13. The epoch that holds these blocks starts at block 835,454 and the next at 836,341, so it holds 887 blocks for 900 rounds. On builds of current main, XDPoS_getMissedRoundsInEpochByBlockNum lists such rounds with their leader. The archive node we read runs an older build and answers that method with "not served yet", so we found the round by comparing the round and the block number.

Frequently asked questions

Can I get a timeout certificate over RPC?

Not from a block. A header carries a QC and a round, not a TC. The TC's effect shows as a round that is more than one above the QC's round.

How do I find rounds without a block?

Compare round - number across blocks from XDPoS_getV2BlockByNumber. Each time it grows, rounds passed without a block. On current builds, XDPoS_getMissedRoundsInEpochByBlockNum lists them.

Why did the next block come 61 seconds later?

The net2040 timeout period is 60 seconds. The round had to time out before the next leader could propose.

What is the gap number in the QC?

The block number of the gap snapshot that holds the masternode list of the epoch. Here it is 834,750.