# The Vault Manager is unable to delete the last strategy from MultiStrategyVault

Removing the last strategy in MultiStrategyVault zeroes _totalWeight before _allocateAssets, causing division-by-zero revert and locking vault funds.

- Payout: Audit contest
- Severity: medium
- Program: BakerFi
- Credited: pfapostol
- Disclosed: 2025-02-26
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2024-12-bakerfi-invitational#m-13
- Library page: https://bugbountylibrary.com/r/c4%3A2024-12-bakerfi-invitational%3AM-13
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:dos

**Target:** MultiStrategyVault.removeStrategy / _allocateAssets
**Root cause:** removeStrategy subtracts the removed strategy's weight from _totalWeight and zeroes it before calling _allocateAssets, which divides by _totalWeight; removing the last strategy makes _totalWeight zero.
**Steps:**
1. Deploy a strategy (e.g. StrategyUniV3SwapAnd) and initialize MultiStrategyVault with a single strategy at weight 100.
2. Deposit WETH into the vault via `msVault.deposit(10 ether, DEPLOYER)`.
3. As VAULT_MANAGER_ROLE call `msVault.removeStrategy(0)`.
4. Observe revert `panic: division or modulo by zero (0x12)` from `_allocateAssets` computing `(amount * _weights[i]) / _totalWeight`.
**How found:** Code reading of removeStrategy ordering: weight subtraction/zeroing happens before _allocateAssets, so the last-strategy case divides by zero.
**Escalation:** Warden notes removing the last strategy also DoSes withdrawals since _deallocateAssets returns 0, but author treats it as separate.
**Insight:** When auditing weight-based allocation vaults, check the order of state mutation vs. redistribution: zeroing total weight before reallocating reverts on the final element.