How the Committee Is Chosen: It Is a List in the Genesis File, and No Transaction Can Add You To It

The question this page is really about

Not "how does the protocol sample a committee". "Could I be in it."

The answer is no, and the reason is mechanical rather than political, which is the useful kind of answer.

Where the committee comes from, exactly

A list in the genesis file. Each entry carries an address, an Ed25519 public key and a BLS public key, which are the three things a committee member is.

That list is read once, when the process starts, into a field on the consensus engine. Nothing writes that field again. Every other reference in the engine reads it.

So the committee is fixed for the lifetime of the running process, and changing it means changing a file and restarting.

And the chain's own validator registry cannot feed it

There is a validator record in chain state, and a staking transaction creates or updates one.

It holds an address, a staked amount, an unbonding amount, a reputation figure and a flag. It holds no keys.

But a committee member is identified by two keys. So the registry could not populate a committee even if something consulted it, and nothing does.

This is why the distinction the software makes matters. Installing and running the node software is not becoming a validator, and the gap is not a missing permission or an unfinished form: there is no transaction anybody can send that adds them to the committee.

And two of our own sources disagree about the same four validators

The genesis file declares, for each of its four validators, a stake and a reputation.

The chain's registry reports zero for both, for those same four addresses.

CONTROL: the four genesis addresses match four of the five entries the public registry returns, character for character. The two sources are describing the same validators, so the disagreement is about values rather than about identity.

The registry is what the protocol acts on. Genesis is a declaration that did not reach it. A reader who quotes the genesis figure is quoting an intention, and a reader who quotes the endpoint is quoting the state. Those are different numbers and this page will not average them.

One thing the two sources agree on, and it is worth having

Genesis states a committee size of four and a quorum of three.

The source computes the quorum as two thirds of the committee, rounded down, plus one, which for four is three.

Two independent places, one answer. When configuration and code agree about a number, that number is much more likely to be the one in force, and this is the only figure on this page that enjoys that.

The specified design, and which half of it exists

The target is a committee of twenty-one drawn from a pool of up to a hundred.

That is a specification and it is not deployed. And the two halves are not in the same state: the part that picks a leader from an existing set is implemented, while the part that would draw twenty-one from a hundred has no implementation in production code at all.

"Not deployed" is doing a lot of work in one phrase, and the distinction is worth keeping sharp.

A smaller thing worth noticing in the genesis file

The seed that feeds the leader draw is a genesis constant.

It does not rotate. So a participant can compute its own draw score for every future round right now, though not anybody else's, because each score needs that validator's own secret key.

The usual practice is to rotate the seed periodically, so that no participant holds a permanent view of its own future position. It is not urgent while the draw is switched off, and it belongs on the list of things to settle before a committee opens.

What you can check yourself

solidus_getValidators against the public endpoint

Five entries come back and four of them produce blocks. The staked and reputation columns for those four read zero, and no interface anywhere will show you the genesis file they came from.