Finding: the Round6 proof size estimate is sized by participant count while the production BindingFactorsProof cap is 8, and the authority set is a sparse bitmap. With validators at indices 0 through 200 plus 299, the generated proof length is 9 against the cap of 8, so the honest Round6 package is rejected by the real dispatch with Round6PackageInvalidProof before signature verification. The full 300-authority production drive was not executed; the sparse bitmap shape was confirmed line for line in source and the rejection was executed through the real dispatch path.
generated proof length 9 vs production cap 8 -> Round6PackageInvalidProof
Impact: silent DKG liveness death at production scale. The honest-input constraint that triggers it is a sparse authority set, which rotation produces naturally.
Suggested fix: size the Round6 estimate by highest index and size the share proof cap by MaxAuthorities, not by threshold.
Shahmeer, that was a good take - it really made me think. But then I realized that BindingFactorsProof is associated with signature shares only. It is used in the BoundedVec to limit the number of entries for binding_factors_proof, as you can see here.