bug(genesis): ValidatorManager schema allows zero-address roles and negative voting power bounds #491

Activity

1. github-actions

   added

   need-triage

   on Oct 11, 2026
2. osr21 commented on Oct 11, 2026

   

   osr21

   on Oct 11, 2026

   More actions

   I checked the current genesis builder and the core validation gaps described here appear real. In particular, the builder writes Ownable._owner and the pauser directly into proxy storage, so the runtime initialize() zero-address checks do not protect this genesis-config path. schemaAddress is format-only, and schemaBigInt.max(UINT64_MAX) still accepts negative bigint values; the later toBytes32 conversion is where those values fail.

   A few points that may help make the fix and regression coverage precise:

   • Test safeParse rejection for zero owner, pauser, validator registerers, and controller addresses, plus negative validators[].votingPower and controllers[].votingPowerLimit. Assert validation fails at the schema boundary rather than later during storage encoding.
   • Use a non-negative lower bound (0n), not a positive one, unless the contract semantics require otherwise: the current schema permits zero-power entries and separately requires at least one validator with positive power.
   • Normalize addresses to the same 20-byte identity before duplicate checks. Two strings with different hex casing represent the same EVM address; duplicate controller entries can collide in the address-keyed registration mapping, so test that mixed-case duplicates are rejected before storage generation.
   • Please describe the threat boundary explicitly: these values come from genesis/operator configuration, so this is an initialization-time misconfiguration/build-validation issue, not a permissionless remote input. The zero-owner case can still brick governance if such a genesis is accepted, but severity should reflect who controls the config and when validation runs.
3. Lesnak1 commented on Oct 11, 2026

   

   Lesnak1

   on Oct 11, 2026

   Last edited by Lesnak1

   Author

   More actions

   Thank you @osr21 for the detailed review and guidance!

   We completely agree with all four points:

   1. Schema Boundary Rejection: All validations are enforced strictly at the Zod schemaValidatorManager schema boundary via safeParse. Rejections for zero-address roles (owner, pauser, validatorRegisterers, and controllers) and negative bounds fail upfront before storage encoding.
   2. Non-Negative Lower Bound (0n): We enforce schemaBigInt.min(0n).max(UINT64_MAX) on both votingPower and votingPowerLimit, maintaining contract semantics where 0-power entries are valid provided the existing non-empty positive total power requirement is met.
   3. Address Identity Normalization: Addresses are normalized to lower-case 20-byte identity before duplicate checks for both validatorRegisterers and controllers, and we have specific regression tests ensuring mixed-case duplicate entries are caught and rejected.
   4. Threat Boundary Context: The PR description will explicitly frame this as an initialization-time configuration validation / defense-in-depth fix preventing governance bricking and build crashes during genesis compilation.

   We have the fix implemented along with 12 regression tests passing locally (12 passing in 7ms) and verified with ESLint.

   cc @ZhiyuCircle @romac : The validation gaps are confirmed and aligned above. Could you please assign this issue so we can submit the PR in accordance with the contributing guidelines?
4. Lesnak1 commented on Oct 13, 2026

   

   Lesnak1

   on Oct 13, 2026

   Author

   More actions

   Hi @ZhiyuCircle @romac ,following up on the validation confirmation above with @osr21, we have the complete fix and 12 passing regression tests ready locally. Could you please assign this issue so we can submit the PR in accordance with the contributing guidelines?