# Validator cannot set new address if more than 300 unstakes in it's array

OperationalStaking's setValidatorAddress reverts when a validator's Unstaking array exceeds 300 entries, letting a griefer permanently lock a validator's address.

- Payout: Contest reward
- Severity: medium
- Program: Covalent
- Credited: PUSH0
- Disclosed: 2023-11-10
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-11-covalent-judging/issues/25
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-11-covalent%3AM-1
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:access-control vuln:business-logic vuln:dos

**Target:** OperationalStaking.sol staking contract (setValidatorAddress / _unstake)
**Root cause:** setValidatorAddress() requires the validator's Unstaking array length to be under 300 and is the only path that clears the array; _unstake() pushes a new entry each call, so the array can be inflated past the limit and the function reverts permanently.
**Steps:**
1. Attacker stakes a small amount (e.g. 1000 tokens) as a delegator to a target validator.
2. Call _unstake() 301 times with tiny amounts; each call pushes a new Unstaking entry for that validator.
3. Validator now calls setValidatorAddress(newAddr); the length check at line 702 reverts because array > 300.
4. No other in-scope function reduces the Unstaking array, so the validator is stuck with the old address.
**How found:** Code review of setValidatorAddress() length check and array deletion, cross-checked against README claim of an option to transfer address without unstakings; found no such function in scope.
**Exploitation:** Griefing: a malicious delegator (or validator) inflates the victim validator's Unstaking array past 300 entries via repeated small unstakes, permanently blocking the victim from rotating its staking address (e.g. during a key-leak response).
**Insight:** When a function both enforces a length cap and is the sole path that shrinks an attacker-growable array, the cap becomes a griefing lever; check whether any other function can reduce the array before trusting the cap.