StakeStone security record

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 `StoneBTCVault` assumes that different wrapped BTC tokens maintain an exchange rate of 1:1. However, if any asset depegs, an attacker can drain the asset pool of value. This effect is aggravated since there are no delays between staking and unstaking. Such an attack is profitable if one asset is worth more than another minus deposit and withdraw fees. At present, WBTC, FBTC, and BTCB are expected to be used to back StoneBTC. However, WBTC in particular is not a safe asset, one reason being the delay for unwrapping^{[\[1\]](https://flagship.fyi/outposts/market-insights/wbtcs-recent-depeg-and-what-you-need-to-know-to-protect-yourself/)}. Furthermore, due to the current restructuring^{[\[2\]](https://cointelegraph.com/news/defi-protocol-threshold-proposes-bitcoin-wrapper-merger-wbtc)} of the WBTC token, it may become even less stable in the future. Token-specific considerations aside primary concern is the ability of users to leverage this vault as a 1:1 exchange platform, possibly using flash loans to exploit any depegged asset. This could result in the entire vault being drained of the more valuable BTC assets, with the less valuable tokens remaining, leading to a significant loss in value.

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.

The `Proposal` contract allows `StoneBTC` holders to vote on protocol decisions for the `StoneBTCVault` and either support or reject the proposals made by the `PROPOSE_ROLE`. However, the `EXECUTE_ROLE` has a veto right on any passed proposal in that the role can decide to never execute the proposal.

The `StoneBTCVault.removeSupportedTokens()` function includes a check that reverts if `ERC20(_token).balanceOf(address(this)) != 0`. However, there are a few risks: 1. Not everyone may withdraw the token to be deprecated. 2. Someone might accidentally transfer tokens to the contract without using the `deposit()` function, leading to a balance mismatch between the minted stoneBTC tokens and their collateral tokens. 3. An attacker could front-run and repeatedly transfer small amounts (dust) of tokens to prevent the removal from taking place. On the other hand, `StoneBTCVault` allows depositing one token and withdrawing another. As a result, the operating team, if desired, can withdraw the token they plan to remove support for, perform the exchange, and re-deposit another token to clean up the remaining balance. With this in mind, the first risk can be mitigated, and the second risk can also be addressed, as long as there is at least one supported token that is not planned for removal. However, the third risk remains, although the attacker's incentive is low.

In the `Proposal` contract, the `getProposals()` and `retrieveAllToken()` functions both loop through all proposals. Since proposal data is never removed, the size of the `proposals` variable will continuously grow, potentially leading to the risk of breaching the block gas limit. If the block gas limit is exceeded, these functions may no longer be accessible. However, the impact is likely very low, as these functions are not directly used by any contracts within the scope of this audit and are likely only used by off-chain components.