The Validator Committee: The Spec Says Twenty-One, the Registry Says Five, and Four Actually Propose

The spec, and it is only a spec

The protocol's target design is a 21-of-100 committee, elected by verifiable random function from a pool of registered validators.

That design is not deployed. No committee of that size has ever run, and no VRF election has ever selected one on this network. The finality mechanism itself is a separate subject; this page is about the gap between the specified committee and the running one.

What the live chain returns, and why the answer has two numbers

Ask the endpoint for validators and you get five entries. Five distinct addresses, every one flagged active.

Sample recent blocks and you find four distinct proposers. Across twenty-five readable blocks near the tip, the proposals divided roughly evenly between four addresses.

The fifth proposed nothing in the sample.

So "how many validators are there" has two true answers: five are registered, four are producing. The word carries a registry meaning and a committee meaning, and the endpoint does not distinguish them for you.

And the fifth is the interesting one

Of the five entries, exactly one carries a non-zero stake field and a non-zero reputation field. The other four report zero in both.

The one with those fields populated is the one that proposed nothing. The four with zeroes are the four producing blocks.

Treating a number in that column as an economic quantity would be reading a placeholder as a fact, which is exactly the mistake this estate exists to avoid.

SOLVED, 2026-08-02: the thing we measured and could not explain

This section reported that some heights return a null result with no error, and said we did not know why. We do now, and the answer was in the interface's own documentation.

Block height on this chain is not one value per block. Three chained blocks share a single height, confirmed by their distinct hashes forming a parent chain. So the heights that returned null were never blocks: they are values the chain does not assign, and asking for one is asking for something that does not exist.

There is a contiguous index and it is documented as the authoritative chain position. Fetching by canonical sequence returns every block with no gaps at all, and the interface's own comment recommends it specifically for callers iterating every block.

So this page's measurement was correct and its framing was wrong. It was not a defect in the endpoint. It was us iterating the wrong index, and a later page of this estate published a transaction count that had to be corrected for the same reason.

The original section is kept below, because the measurement was sound and eliminating rate limiting was the right first move.

The original section, kept: something we measured and could not explain

Some recent heights return a null result with no error.

Ten consecutive heights below the tip were requested one at a time, a quarter-second apart. Three returned null. The pace rules out rate limiting, which was the first explanation worth eliminating.

What it does not rule out: heights genuinely skipped by the consensus round structure, blocks present but not retrievable through this particular method, or a read-path defect.

We do not know which, and we are not going to pick the flattering one. It is reported here because an explorer that hides a gap in its own reads is not an explorer, and because somebody with the node's internals can settle in minutes what we could only observe from outside.

What you can check yourself

Ask for the chain identifier and the tip:

solidus_chainInfo and solidus_blockNumber

Ask for the validator set:

solidus_getValidators

Then read a handful of blocks and collect the proposer field:

solidus_getBlock with a height

Count the distinct proposers. If your count and ours differ, ours was taken on 2026-08-02 at tip height 83,685, and the honest expectation is that a set this small changes when its operator changes it.

Why the smaller number is the one to quote

Four independently-signed certificates and twenty-one independently-signed certificates prove the same thing mathematically. Only the first has actually happened here.

And all four are operated by the same team, so what is demonstrated today is that the mechanism runs, not that it survives adversarial or independently-operated conditions.

Rounding four up to five because the registry says five, or up to twenty-one because the specification says twenty-one, would each be a different way of overstating the same thing.