# Safe threshold can be set above target threshold, causing transactions to revert

HatsSignerGate reconcileSignerCount fails to lower Safe threshold when targetThreshold drops below current threshold, causing all transactions to revert.

- 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/44
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-hats%3AM-9
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:business-logic vuln:dos

**Target:** HatsSignerGateBase.sol Safe threshold reconciliation logic
**Root cause:** reconcileSignerCount only lowers the Safe threshold when currentThreshold < target; when target < current <= validSignerCount, newThreshold stays 0 and the Safe threshold is never lowered.
**Steps:**
1. Set valid signers, targetThreshold, and Safe threshold all to 10.
2. Toggle the hat off so signerCount < 2, preventing setTargetThreshold from auto-lowering the Safe threshold.
3. Lower targetThreshold to 9.
4. Toggle the hat back on.
5. Process a transaction: reconcileSignerCount sees validSignerCount(10) > target(9) and currentThreshold(10) > target(9), so newThreshold remains 0.
6. checkAfterExecution compares safe.getThreshold()(10) to _getCorrectThreshold()(9) and reverts SignersCannotChangeThreshold, blocking all transactions.
**How found:** Code review of reconcileSignerCount branch conditions against _getCorrectThreshold bounds, noticing the else-if only handles currentThreshold < target and misses the target < current case.
**Insight:** When auditing threshold/limit reconciliation, enumerate all orderings of current vs target vs count; a two-branch if/else-if often misses the case where current already exceeds target and must be lowered.