6. Committee Selection & VRF Rotation

6.1 Committee Model​

consensus/committee.rs stores validators, stake, activity and jail status and exposes committee selection and quorum accounting. Committee count, size, shard topology and thresholds are configuration choices. The repository contains reference values, but they are not universal mainnet parameters and have not been demonstrated at the advertised validator scale.

6.2 Selection Inputs​

The official repository describes stake-weighted committee selection using a Rescue-Prime + STARK hash-based VRF path. The concrete selection distribution, proof soundness, rejection sampling and adversarial multi-validator behavior must still be validated against the implementation and benchmarked before a production security claim.

6.3 Rotation and Activation​

Committee rotation is driven by consensus and configuration state. Validator registration, activation, exit, and jailing are separate lifecycle concerns. Any activation delay or beacon chaining used by a particular network must be stated in that network's genesis/configuration rather than treated as an immutable protocol constant.

6.4 Stake and Quorum​

Validator stake is used in committee and finality accounting. The code checks validator activity, duplicate signers, and stake thresholds. A generic >2/3 BFT statement is a protocol assumption for configured committees, not evidence that every deployed configuration has the same threshold or fault tolerance.

6.5 Open Validation Work​

A mainnet committee specification still needs to fix the validator cap, committee sizing, selection distribution, activation delay, epoch cadence, quorum rule, and behavior during churn. It also needs multi-node tests covering adaptive targeting, stake concentration, delayed messages, equivocation and reconfiguration.