Ensuro Strategy Vault security record

The function `_maxWithdrawable()` sums up the maximum withdrawal amount of each strategy related to the vault and returns the sum up to a `limit`. However, depending on the strategies, the sum may evaluate to greater than `type(uint256).max` before a `return` statement is reached, resulting in the function reverting. The same principle applies to `_maxDepositable()` which is implemented similarly.

In the `CompoundV3InvestStrategy.disconnect()` function, the logic verifies that the `cToken` balance is zero before allowing a disconnect. However, the function does not account for any claimable rewards that may be pending in the rewards manager, potentially leaving yield unclaimed.

In the `getForwardToStrategySelector()` function, the selector for forwarding calls to strategies is constructed using a combination of the strategy index, method ID, and the first four bytes of the strategy’s address. This approach introduces two key issues: 1. Potential Collisions: The use of XOR to combine truncated values is not a secure method of generating unique identifiers. XOR operations are commutative and linear, meaning different combinations of inputs can result in identical outputs, leading to unintended access control overlaps. 2. Selector Instability: Since the strategy index is included in the selector, any change to the order of strategies in the `_strategies` array will change the computed selector. This means that modifying the strategy list (such as calling `MSVBase.removeStrategy()`) will require resetting access control permissions, leading to operational friction and potential misconfigurations.

In the `MSVBase.removeStrategy()` function, there is an early check that reverts if `strategy.totalAssets() != 0` without considering the `force` parameter. The function should allow removal by letting the strategy handle asset checks in `strategy.dcDisconnect(force)`.