StakeStone Vault

The `OracleConfigurator` contract allows the `ORACLE_MANAGER_ROLE` to update oracles for tokens, but there is no validation to ensure that the price data returned by these oracles has the expected decimal precision (e.g., 18 decimals). If an oracle provides price data with different precision, it could lead to incorrect calculations for LP amount in `AssetVault`.

The `ASSET_MANAGEMENT_ROLE` can call `AssetVault.withdrawFromVault()` and `AssetVault.repayVault()` to transfer the deposited underlying tokens to asset managers and accrue yield. However, there is no restriction to how much of the reserves can be transferred, as the contract allows withdrawing the entire underlying token balance. We would like to note that the protocol maintaining solvency relies on the asset managers used by the StakeStone team. These asset managers are outside the scope of this audit.

The `removeUnderlyingToken()` function ensures that the contract's balance for a specific token is zero before removing it from the token list. However, since it relies on the `IERC20.balanceOf()` function, an attacker can disrupt this function by donating a very small amount of the token to the contract. This will cause the balance check to fail, preventing the token from being removed.

The `queueWithdrawal()` function allows anyone to enqueue a withdrawal request for any amount, regardless of their actual holdings of LP tokens. This leads to fragmentation of the withdrawal queue and can later disrupt the operations of the `processWithdrawals()` and `cancelWithdrawals()` functions. Although it is possible to simply ignore these fake requests while calling these functions, this would still make management of the queue harder.

During the very first deposit to the vault, a malicious actor could front-run legitimate deposits and donate additional funds to inflate the LP token price. This manipulation may prevent subsequent depositors from receiving the correct amount of LP tokens, effectively reducing their share. Without the Proof of Reserve (PoR) oracle implementation within the scope, we cannot assess whether this inflation attack is feasible. However, this is a known vulnerability in typical vault designs if not properly addressed.

The `processWithdrawals()` function always pays users the `minReceiveAmount` specified at the time of their withdrawal request, regardless of the actual value of their LP tokens at the time of withdrawal. During periods of high market volatility, significant price fluctuations can occur between the time a withdrawal is requested and when it is processed. As a result, users may receive less than the fair value of their LP tokens, effectively losing money and making the protocol appear unfair. While the naming of `minReceiveAmount` might suggest it is intended solely as slippage protection, the client has explicitly stated that it is meant to function as a limit order. The current implementation allows withdrawal processors to pocket any excess value if the LP tokens are worth more at the time of withdrawal. This design incentivizes processors to fulfill withdrawals when they can profit the most from the price difference, potentially at the expense of users. This is a concern if the vault contains assets with varying volatility. For example, if the `AssetVault` holds both `USDC` and `wBTC`, and a user requests a USDC withdrawal, an increase in BTC's value will raise the overall LP token price. Consequently, the user may receive less in USDC during withdrawal because the `minReceiveAmount` was set based on a lower LP token valuation.