Committee Election: The Random Draw Picks a Leader, Not the Committee, and the Committee Came From Genesis

The premise in the title is wrong, and that is the finding

The verifiable random draw does not select the committee. It selects which member of an existing committee proposes in a given round, which is a different question with its own page.

There is no code that selects the set. A search across the consensus crate for committee-selection functions returns exactly one match, and it is a throwaway helper inside the test module, used to build a fake committee for tests.

CONTROL: the same search finds the leader-election functions ten times in their own file. So the random-draw machinery exists and works. It is pointed at the leader, not at the membership.

Which sharpens what "not deployed" means

The protocol's target design is a committee of twenty-one drawn from a pool of up to a hundred registered validators. That design is a specification and it is not deployed.

And the two halves of it are not in the same state. The part that picks a leader from a set is implemented and runs. The part that draws twenty-one from a hundred has no implementation at all, in production code.

So "not deployed" is not one fact. One half is built and running at a smaller size. The other half is not built. A reader deciding how far this is from the specified design deserves that distinction rather than a single phrase covering both.

How membership actually works in the code

Staking is the admission path. A stake transaction creates or updates a validator record and moves the amount out of the sender's ordinary balance into that record.

There is a matching path out, so membership is not permanent.

That is a coherent design: entry is a transaction anybody can send, rather than an administrative act.

And that is not how this committee arrived

The registry returns five entries. Four of them are producing blocks.

Those four report a stake of zero.

So the validators actually running this network did not enter through the staking path. They were present from the beginning, which is ordinary for a development network and is worth stating because the code implies a different story.

The one entry that does carry a stake figure proposes nothing in any sample this estate has taken.

What none of this can be checked against

The draw's proof is not on the read surface, and neither is a certificate or a lock. Three pages in a row have hit the same wall.

So an outsider cannot verify that any leader was entitled to propose, and cannot audit membership beyond the listing the endpoint chooses to return.

CORRECTION, 2026-08-02: the draw is implemented, and this deployment does not use it

So the machinery described below is real and is not what orders proposals here.

That sharpens rather than reverses this page: the drawing half of the specified design has no implementation at all, and the leader half is implemented and switched off in this mode. The proposer page carries the same correction.

What is genuinely right about the draw itself

The draw is unbiasable by the winner. Its inputs are a shared seed and the round number, so a would-be leader has nothing to grind.

The verification is on the receiving side. A proposal with a bad proof is rejected by whoever receives it, rather than trusted because it arrived.

And entry and exit both exist as transactions, so the membership design does not depend on somebody editing a file.

What you can check yourself

solidus_getValidators, then solidus_getBlock across a dozen heights and collect proposer

Compare the two lists. The set that appears in the listing and the set that appears as proposers are not the same, and neither is labelled to say so.