StakeStone StoneBTC and Vault

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 `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.

The `Proposal` contract allows users to vote their stoneBTC for only one poll at a time. Only after the vote is closed can the user retrieve the tokens they used and allocate them to another vote. At the same time, it is possible for the `PROPOSE_ROLE` to create several polls at a time, effectively diluting the voting power across these polls.