How the Next Proposer Is Picked: A Lottery in the Specification, a Rotation on the Wire

What the protocol says

Each round is a lottery with a verifiable result.

Every validator computes a random-looking output from two inputs: a shared round seed and the round number. The output is produced with the validator's own key, so nobody else can compute it for them, and it comes with a proof that anybody can check.

The lowest output wins. Interpreted as a number, whichever validator's output is smallest is the leader for that round.

And a proposal can carry its proof. CORRECTED 2026-08-02: this previously said a receiving participant verifies that the claimed leader really did win. That overstated what the check establishes. What it establishes is narrower and worth stating exactly: that the proposer is in the validator set, and that the proof accompanying the block is a valid one for that round under that proposer's key. Ranking the round's outputs against each other is a separate step, and this page should not have described the two as one.

Why that design is a good one

The leader cannot choose to win. The output depends on the seed and the round, not on anything the proposer picks, so there is nothing to grind.

And the result is checkable rather than trusted. Anybody with the proof can confirm the leader was entitled to propose, which is what makes the mechanism useful in a set that does not trust itself.

And here is what the chain actually shows

Fourteen readable blocks were fetched. Labelling the four proposers A, B, C and D, twelve of them run:

A B C D A B C D A B C D A

That is an unbroken rotation, not a lottery.

With four validators, an exact rotation sustained over twelve draws is on the order of one in four million by chance. A random election does not behave this way.

The obvious objection, and why it does not explain it

Only every third height resolves on this endpoint, so the sequence above is a subsequence rather than every block. UPDATED 2026-08-02: the reason is now known and it is not a defect. Three chained blocks share one height value, so two blocks in three are simply not addressable by height.

But sampling a random sequence every third element gives a random subsequence, not a rotation. Periodicity is not manufactured by regular sampling of an unpredictable process, so the pattern is real in what can be observed.

CORRECTION, 2026-08-02: it is the first one, and here is the line that says so

So the lottery is inactive on this deployment. The rotation is not a suspicious pattern in a random process; it is round-robin, by configuration, exactly as it appears.

The original reasoning is left below, because the measurement that produced it was correct and only the conclusion was withheld. What resolved it was reading the deployment's own configuration, which is a different source from the one this page had been searching.

What we could not tell you from outside

Whether the lottery is inactive on this deployment, or active with something else ordering proposals.

The proof that would settle it is not on the read surface. No block carries a leader proof, a certificate or a lock, so the one artefact that would distinguish the two cannot be fetched.

That remains true of the read surface, and it is why the answer had to come from the source.

And one block departs from the pattern

The most recent block in the sample breaks it: its round advances by one rather than three, and its proposer is out of turn.

So the rotation is not absolute, and a reader repeating this measurement later may see something different. One departure in fourteen is reported rather than smoothed away, because a pattern with an exception is a different claim from a pattern without one.

Why it matters, sized honestly

Unpredictable leadership is what makes a leader hard to target. If the next proposer is knowable in advance, anybody who wants to disrupt a specific round knows exactly which participant to reach.

On this network the cost is close to nothing: four proposers, all operated by the same team, no value at stake and no external participant to attack. It is a property that matters when the set is open, not while it is four machines in one place.

What you can check yourself

solidus_canonHead, then solidus_getBlockBySeq downward, listing proposer in sequence order

UPDATED 2026-08-02: use the sequence, not the height. Iterating heights shows one block in three, because three chained blocks share a height value, and the interface's own documentation recommends the sequence for exactly this. Compare round alongside, because the two do not always move together.