Verifiable Randomness Is Not Unmanipulable Randomness, and the Difference Is Where the Attack Lives

The mechanism here is implemented and the network it runs on is too small to exercise it.

What the mechanism proves

A function that produces a random-looking output plus a proof that the output was derived correctly from a given input and a given key. Anyone holding the public key can check the proof. Nobody can produce a different valid output for the same input.

So the mechanism gives you verifiability. Given the input, the result was computed honestly, and everybody can confirm it independently without trusting the party who computed it.

For selecting a committee from a validator set, that is exactly the property you want. No coordinator, no trusted dealer, and every participant can confirm the selection was fair.

What it does not prove

That nobody influenced the input.

The output is determined by the input. Verifiability says the derivation was honest. It says nothing about where the input came from, and if a participant can influence that value, they can influence who gets selected while producing a perfectly valid proof at every step.

The attack is not on the function. It is upstream of it. A party who can nudge the seed, or who can choose whether to publish a block that changes the seed, is choosing among outcomes without ever computing anything dishonestly.

This is the standard trap in this construction, and a system that describes its selection as "provably fair" without saying where the seed comes from has answered the easier half of the question.

The right question is never "is your randomness verifiable" but "who can influence the input, and what can they do by declining to act?"

What to ask any chain about committee selection

"Where does the seed come from, and who can influence it?" The question the verifiability claim does not answer. Ask it second, after they explain the proof.

"What can a participant gain by withholding a block?" Influence over the next selection, in most designs. A team that has not considered it has not modelled the adversary.

"How large is the set being selected from, today?" For us: 4. The specified 21-of-100 is a design and is not deployed.

"Who operates those nodes?" If the answer is one party, selection is a formality regardless of the mathematics.

Where this leaves a decision

If you need demonstrated decentralised committee selection, ours has never selected from a population worth the name, and the correctness of the mechanism does not substitute for the absence of participants.

If you are evaluating whether the design is sound and the team knows what would attack it, the mechanism is standard and implemented, the seed question is the real one and we have named it against ourselves, and the gap between the specification and the deployment is stated on every page where it is relevant rather than in a footnote.