# Exodus Round6 proof cap sized by threshold count, production-scale sparse validator index silently fails

**URL:** https://ghostforum.org/t/exodus-round6-proof-cap-sized-by-threshold-count-production-scale-sparse-validator-index-silently-fails/93
**Category:** Bug Bounty
**Tags:** exodus-pallet
**Created:** [October 2, 2026, 9:04am UTC](https://ghostforum.org/t/exodus-round6-proof-cap-sized-by-threshold-count-production-scale-sparse-validator-index-silently-fails/93 "2026-10-02T09:04:42Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![Sands](https://ghostforum.org/letter_avatar_proxy/v4/letter/s/22d042/32.png) [@Sands](https://ghostforum.org/u/Sands)
#### Post date: [October 2, 2026, 9:04am UTC](https://ghostforum.org/t/exodus-round6-proof-cap-sized-by-threshold-count-production-scale-sparse-validator-index-silently-fails/93/1 "2026-10-02T09:04:45Z")

</div>

Hi team

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.

```auto
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

---

<div class="post-metadata">

### Author: ![VoidDragon](https://ghostforum.org/user_avatar/ghostforum.org/voiddragon/32/16_2.png) [@VoidDragon](https://ghostforum.org/u/VoidDragon)
#### Post date: [October 3, 2026, 10:38pm UTC](https://ghostforum.org/t/exodus-round6-proof-cap-sized-by-threshold-count-production-scale-sparse-validator-index-silently-fails/93/2 "2026-10-03T22:38:31Z")

</div>

Thank you for your report!

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](https://git.ghostchain.io/ghostchain/ghost-node/src/commit/0162da4604d9931c16d12a0cec40dd85951368c5/pallets/exodus/src/types/packages.rs#L228).

You can verify that it is used only there:

```auto
$ grep -rnw BindingFactorsProof pallets/
pallets/exodus/src/types/packages.rs:228: pub binding_factors_proof: BoundedVec<ExodusHash, crate::BindingFactorsProof<T>>,
pallets/exodus/src/types/packages.rs:346: BoundedVec::<ExodusHash, crate::BindingFactorsProof<T>>::try_from(binding_factors_proof_vec)
pallets/exodus/src/lib.rs:313:pub struct BindingFactorsProof<T>(sp_std::marker::PhantomData<T>);
pallets/exodus/src/lib.rs:314:impl<T: Config> Get<u32> for BindingFactorsProof<T> {

```

So `BindingFactorsProof` caps the binding-factors proof in the signature-share flow - not the Round6 verifying-share package.

Could you clarify whether I misunderstood you, or whether you are referring to something else?