X1 Blockchain's network health metrics remain strong, with block skip rates holding below 0.5% and the delinquent validator rate at 0.17%. Those two figures are the most direct available read on whether a proof-of-stake network is actually working — and they are worth understanding properly rather than taking on trust.

How block production works on X1

Skip rate only makes sense once you know how X1 assigns the right to produce blocks, and the mechanism is inherited from Solana rather than invented here.

Time is divided into slots, each a fixed short interval. Before every epoch begins, the network computes a leader schedule: a deterministic, stake-weighted assignment of which validator is the leader for which slot. The schedule is known in advance by everyone. A validator with more delegated stake is assigned proportionally more slots.

Being leader means it is your turn — and only your turn — to produce a block for that slot. This is a deliberate design choice. Because leadership is pre-assigned rather than competed for, there is no race, no wasted work, and no need for the probabilistic finality that proof-of-work requires. The cost is that when the assigned leader fails to deliver, nobody else steps in for that slot. It is simply lost.

What skip rate measures

A skipped slot is one where the assigned leader did not produce a block that the network accepted. The skip rate is the proportion of scheduled slots that ended this way.

A skip rate below 0.5% means more than 99.5% of scheduled blocks were produced on time. Slots are not retried — the chain moves on — so a skipped slot is permanently lost capacity. In practice a handful of causes account for nearly all of them:

  • Hardware that cannot keep up. Monolithic SVM validators are demanding. A node short on CPU, memory or disk throughput falls behind and misses its window.
  • Network latency and propagation. A leader must receive the previous block, build on it, and propagate its own in a very short interval. A poorly connected node runs out of time even with adequate hardware.
  • Restarts and upgrades. A validator restarting for a client upgrade will skip any slots it was assigned during the restart. This is routine and benign, and it is why skip rate briefly rises across the network during coordinated upgrades such as a Tachyon client release.
  • Genuine failure. A node that has crashed or lost connectivity skips every slot it is assigned until it recovers.
Skip rate is not evenly distributed, and the average conceals this. A network-wide 0.5% is compatible with most validators skipping almost nothing while a small number skip heavily. When choosing where to delegate, the number that affects your rewards is that specific validator's skip rate, not the network average.

What delinquency measures — and why it is the more serious signal

Delinquency is a different and more consequential condition. A validator is delinquent when it has stopped voting on recent blocks — it has fallen far enough behind the chain tip, or gone offline entirely, that it is no longer participating in consensus.

The distinction is one of degree and duration. A skipped slot is a single missed opportunity; a healthy validator skips occasionally and it barely registers. Delinquency means the node is not contributing to consensus at all, and it persists until the operator intervenes.

A 0.17% delinquent rate across a validator set of several hundred nodes means only a small handful are non-participating at any given moment — normal operational churn rather than distress. It is worth noting that some delinquency is expected and healthy: a permanently zero rate across a large set would be slightly suspicious, suggesting either a very small set or one that is unusually homogeneous.

What these metrics do not tell you

Both figures describe liveness — whether the network is producing blocks reliably. Neither describes decentralisation, and conflating the two is the most common error in reading validator statistics.

A network with five validators in one datacentre could post a perfect skip rate and zero delinquency. It would be extremely reliable and almost entirely centralised. Liveness metrics measure operational competence, not distribution of control.

The questions that actually address decentralisation are separate:

  • Stake concentration. How much stake sits with the largest operators, and how many would need to collude to halt or censor the chain?
  • Independence of operators. Are the nodes run by genuinely distinct parties, or several by one entity?
  • Geographic and infrastructure diversity. Distribution across countries matters, but so does distribution across hosting providers — nodes in different countries on the same cloud provider share a correlated failure mode.
  • Client diversity. A single validator client means a single bug can affect the entire network at once.

X1's community validator program supports a large set of independent nodes and block producers distributed across many countries, which is a meaningful contributor to genuine decentralisation. Our X1 validators page tracks the live count, stake distribution and delinquency, and the staking guide covers how delegation choices affect both your rewards and the network's distribution.

How to check for yourself

These are directly verifiable. The public RPC endpoint https://rpc.mainnet.x1.xyz answers getVoteAccounts, which returns current and delinquent validators as two separate lists, and getBlockProduction, which returns slots assigned versus blocks produced per validator — skip rate computed from source. explorer.x1.xyz presents the same data without requiring you to make RPC calls.

If you are delegating stake, check the individual validator's block production record before choosing. A validator with a persistently high skip rate produces fewer blocks, earns fewer rewards, and passes that shortfall directly to you.