# [Medium][Outdated State] `_removeSigner` incorrectly updates `signerCount` and safe `threshold`

_removeSigner in HatsSignerGateBase miscounts signerCount when a previously inactive signer reactivates, corrupting the safe threshold and required signature count.

- Payout: Contest reward
- Severity: medium
- Program: Hats
- Credited: Allarious
- Disclosed: 2023-02-15
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-02-hats-judging/issues/79
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-hats%3AM-7
- Tags: domain:web3 impact:integrity kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** HatsSignerGateBase Solidity contract (signer management)
**Root cause:** _removeSigner decrements signerCount whenever validSignerCount != currentSignerCount, assuming any mismatch means a signer was deactivated; it ignores the case where an inactive signer reactivated, so validSignerCount can exceed currentSignerCount and still be decremented.
**Steps:**
1. Set up 5 signers where signers 0,1,2 are active and 3,4 inactive; signerCount=3.
2. Signer 3 regains its hat and becomes active (validSignerCount now 4).
3. Call _removeSigner to remove signer 4; loop finds validSignerCount=4 != currentSignerCount=3.
4. Function takes else branch and sets newSignerCount = currentSignerCount - 1 = 2, incorrectly reducing signerCount and safe threshold.
**How found:** Code reading of the validSignerCount == currentSignerCount branch; noticed the equality check assumes mismatch only means deactivation, missing the reactivation case.
**Insight:** When a cached count is reconciled against a freshly computed count, test for direction of change (>= vs ==) rather than equality; reactivation of previously inactive members breaks equality-based decrement logic.