# Usage of HSG for existing safe can brick safe

Attaching a HatsSignerGate with maxSigners below the Safe's existing valid signer count makes checkTransaction revert, bricking the Safe.

- Payout: Contest reward
- Severity: medium
- Program: Hats
- Credited: cducrest-brainbot
- Disclosed: 2023-02-15
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-02-hats-judging/issues/93
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-hats%3AM-5
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:dos vuln:misconfiguration

**Target:** HatsSignerGate/MHSG Zodiac module wired to an existing Gnosis Safe
**Root cause:** maxSigners is set once at setup and immutable, but reconcileSignerCount reverts when validSignerCount > maxSigners; wiring an HSG to an existing Safe with more valid hat-wearing owners than maxSigners makes every checkTransaction revert.
**Steps:**
1. Deploy HSG/MHSG via HatsSignerGateFactory with `maxSigners` less than the Safe's current valid hat-wearing owner count (e.g. 10 owners, maxSigners=5).
2. On the existing Safe call `enableModule(HSG)` and `setGuard(HSG)`.
3. Any Safe transaction now calls `checkTransaction()` -> `reconcileSignerCount()`, which reverts on `validSignerCount <= maxSigners`.
4. Safe cannot execute transactions until enough signers renounce/are revoked to drop validSignerCount to maxSigners.
**How found:** Code reading of HatsSignerGateBase: noticed maxSigners is fixed at setup while reconcileSignerCount enforces it on every checkTransaction, and the factory permits attaching to pre-existing Safes whose owner set is not validated against maxSigners.
**Insight:** When a module enforces an immutable config bound against pre-existing external state (Safe owners, token supply), check the bound at attach/enable time, not just at deploy; a deploy-time-only check leaves a window where minting or existing owners exceed it and bricks the guarded contract.