# StakerVault.unstake(), StakerVault.unstakeFor() would revert with a uint underflow error of StakerVault.strategiesTotalStaked, StakerVault._poolTotalStaked.

StakerVault tracks strategy vs pool totals separately; unstake/transfer between strategy and non-strategy misattributes amounts, causing uint underflow that reverts and permanently locks funds.

- Payout: Contest reward
- Severity: medium
- Program: Backd
- Credited: hansfriese
- Disclosed: 2022-07-19
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-05-backd-findings/issues/87
- Library page: https://bugbountylibrary.com/r/c4%3A2022-05-backd%3AM-14
- Tags: domain:web3 impact:dos impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:dos

**Target:** StakerVault.sol staking vault contract (unstake, transfer, addStrategy)
**Root cause:** strategiesTotalStaked and _poolTotalStaked are tracked separately but addStrategy, transfer, and transferFrom never migrate balances between the two counters when an address's strategy status changes.
**Steps:**
1. Non-strategy A stakes x; x added to _poolTotalStaked.
2. inflationManager approves A as strategy via addStrategy; balances[strategy] not moved to strategiesTotalStaked.
3. A calls unstake(x); x deducted from strategiesTotalStaked, which is smaller than the true strategy total.
4. Subsequent strategy unstakes revert on uint underflow; alternatively transfer/transferFrom between strategy and non-strategy never adjusts the two counters, corrupting them.
**How found:** Code reading of StakerVault's separate strategy/pool total accounting; noticed addStrategy and transfer paths don't reconcile the two counters when strategy status differs between sender and recipient.
**Exploitation:** Griefing: frontrun addStrategy for an address holding a stake, or trigger by mistake, so the strategy counter underflows and strategy withdrawals revert; since strategies cannot be removed, stuck tokens are permanent.
**Insight:** When a contract keeps parallel aggregate counters (per-category totals), audit every state transition that changes an account's category membership—approval, transfer, role grant—for missing migration of the existing balance between counters.