# Owners of linkedin tophats cannot have eligibility revoked

Linked tophats in Hats Protocol keep eligibility set to address(0), so admins cannot revoke badStanding or punish misbehaving wearers.

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

**Target:** Hats.sol smart contract (tophat linking/eligibility)
**Root cause:** Tophats are created with toggle and eligibility forced to address(0) and are immutable; linking a tophat to a tree does not update these fields, so _processHatWearerStatus cannot be invoked to set badStanding.
**Steps:**
1. Create a tophat (eligibility and toggle are address(0)).
2. Link the tophat to a new admin tree via approveLinkTopHatToTree.
3. Observe the linked hat still has eligibility == address(0).
4. Attempt to call setHatWearerStatus / revoke eligibility as admin: no IHatsEligibility contract exists and no EOA path is configured, so badStanding cannot be set.
**How found:** Code reading of createHat() zero-address checks versus tophat creation, noticing tophats bypass the eligibility/toggle validation and are immutable, then tracing _processHatWearerStatus to confirm badStanding requires a non-zero eligibility.
**Insight:** When a contract special-cases an object type (tophat) to skip validation, check whether later state transitions (linking) assume those skipped fields were set; immutability plus skipped init leaves permanent gaps.