Sherlock

The following functions contain parameters, which are not used: 1. The `_token` parameter in the `getCooldownFee` function from `PoolBase.sol` 2. The `_token` parameter in the `getSherXWeight` function from `PoolBase.sol` 3. The `_token` parameter in the `getGovPool` function from `PoolBase.sol` 4. The `_token` parameter in the `isPremium` function from `PoolBase.sol` 5. The `_token` parameter in the `isStake` function from `PoolBase.sol` 6. The `_token` parameter in the `getProtocolBalance` function from `PoolBase.sol` 7. The `_token` parameter in the `getProtocolPremium` function from `PoolBase.sol` 8. The `_token` parameter in the `getLockToken` function from `PoolBase.sol` 9. The `_token` parameter in the `isProtocol` function from `PoolBase.sol` 10. The `_token` parameter in the `getProtocols` function from `PoolBase.sol` 11. The `_token` parameter in the `getUnstakeEntry` function from `PoolBase.sol` 12. The `_token` parameter in the `getFirstMoneyOut` function from `PoolBase.sol` 13. The `_token` parameter in the `getTotalPremiumPerBlock` function from `PoolBase.sol` 14. The `_token` parameter in the `getPremiumLastPaid` function from `PoolBase.sol` 15. The `_token` parameter in the `getSherXUnderlying` function from `PoolBase.sol` 16. The `_token` parameter in the `getUnstakeEntrySize` function from `PoolBase.sol` 17. The `_token` parameter in the `getInitialUnstakeEntry` function from `PoolBase.sol` 18. The `_token` parameter in the `getUnactivatedStakersPoolBalance` function from `PoolBase.sol` 19. The `_token` parameter in the `getStakersPoolBalance` function from `PoolBase.sol` 20. The `_token` parameter in the `getUnallocatedSherXStored` function from `PoolBase.sol` 21. The `_token` parameter in the `getTotalSherXPerBlock` function from `PoolBase.sol` 22. The `_token` parameter in the `getSherXLastAccrued` function from `PoolBase.sol` 23. The `_token` parameter in the `LockToToken` function from `PoolBase.sol` 24. The `_token` parameter in the `TokenToLock` function from `PoolBase.sol` 25. The `_token` parameter in the `setCooldownFee` function from `PoolBase.sol` 26. The `_token` parameter in the `activateCooldown` function from `PoolBase.sol` 27. The `_token` parameter in the `cancelCooldown` function from `PoolBase.sol` 28. The `_token` parameter in the `cancelCooldown` function from `PoolBase.sol` 29. The `_token` parameter in the `unstakeWindowExpiry` function from `PoolBase.sol`. Additionally, there are several functions in `PoolBase.sol`, which use both `_token` and `baseData()`. The latter uses the `bps()`, which is used to retrieve the value of `_token`. This function is overly complex containing inline assembly and assuming that the last parameter of the function where `bps()` is called, is always the `_token`. An attacker could break this assumption by simply passing an arbitrary token when calling any of the aforementioned functions (see enumeration above). The `bps()` function is also cloned in `PoolOpen.sol` and `PoolStrategy.sol`. Same recommendation applies to those contracts.

As described in one comment of `strategyRemove()` that says that this function `don't check if the current strategy balance = 0`, in case of faulty strategies there can be financial loss of strategy has tokens.

This would re-instantiate `name` and `symbol`. It is not clear why this is allowed.

The `_watsons` and `_weights` input parameters of the `SherX.setWeights` function are `uint256` and `uint256[]` respectively. However, both input parameters are cast to `uint16` on L221 and L215, respectively. This can cause an integer overflow/truncation of the actual value passed in as input.

The `LibPool.payOffDebtAll(tokens[i])` function is called on L80 in `Payout.sol` if `amounts[i] > ps.sherXUnderlying`. The assumption here is that the following condition will hold after this function call: `amounts[i] <= ps.sherXUnderlying`. However, there is no proof or clear guarantee that it will hold. This is partially handled by the .sub in the else branch below (ps.sherXUnderlying = ps.sherXUnderlying.sub(amounts[i]);), but missed in the if-branch.

All affected contracts have an unlocked pragma, but removing the `^` is not sufficient to fix the problem, because different files use different versions. The following versions were observed: * 0.7.0 * 0.7.1 * 0.7.4 * 0.7.6