StakeStone enables users to deposit underlying assets, such as wrapped BTC tokens or stablecoins, and receive LP tokens in return. These LP tokens represent the user's share of the underlying assets held by the `AssetVault` and are valued based on Chainlink's Proof of Reserve (PoR) oracle. Based on discussions with the client, the StakeStone protocol will support two main asset types: wrapped BTC and stablecoins. This means two separate sets of contracts will be deployed: 1. Wrapped BTC Vault: users deposit wrapped BTC tokens such LBTC (Lombard BTC) and SBTC (StakeStone BTC) to mint STONEBTC. 2. Stablecoins Vault: users deposit stablecoins such as USDT, USDC, DAI to mint StakeStone USD. <br> While deposits and minting of LP tokens are handled permissionlessly through the smart contracts, withdrawals are managed via the `WithdrawalQueue` or market makers. Users submit withdrawal requests specifying a `minReceive` value, and withdrawals can be fulfilled by anyone who sends the requested amount to the user. The party fulfilling the withdrawal receives STONEBTC (LP tokens) as compensation. Furthermore, whitelisted market makers can interact directly with `AssetVault` to submit withdrawal requests. They can burn LP tokens to redeem the underlying collateral without going through the `WithdrawalQueue`. Only entities with the `WITHDRAWAL_PROCESS_ROLE` can process these submitted requests. Although StakeStone allows for decentralized deposits and withdrawals, the repayment of borrowed assets and the management of underlying funds depend on the `ASSETS_MANAGEMENT_ROLE`. This role can borrow and repay assets within the vault, so users rely on it to ensure liquidity for withdrawals and the proper handling of assets. The valuation of LP tokens is determined by the [Chainlink Proof of Reserve](https://chain.link/proof-of-reserve) oracle, which is outside the scope of this audit. The audit uncovered 11 findings and 6 auditor suggestions for code improvement. The issues involve vulnerabilities in the withdrawal mechanisms—such as transaction order dependence and the potential for users to receive an incorrect amount during withdrawal—as well as concerns about the accuracy and validation of Oracle data, which could impact LP token calculations. We recommend the client to consider all identified issues. **Fix Review**: During the fix review, the client addressed all issues from STONE-1 to STONE-11 by either implementing fixes or acknowledging them. The client also updated the test suite, which significantly improved the overall code coverage.
Low | Medium | High | Critical | Total | |
---|---|---|---|---|---|
Not fixed | 5 | 1 | - | - | 6 |
Fixed | 2 | 3 | - | - | 5 |
Total | 7 | 4 | 0 | 0 | 11 |
# | File Name |
---|---|
1 | src/oracle/OracleConfigurator.sol |
2 | src/withdrawal/WithdrawalProcessor.sol |
3 | src/vault/AssetVault.sol |
4 | src/oracle/BTCPeggedOracle.sol |
5 | src/token/Token.sol |
6 | src/withdrawal/WithdrawalQueue.sol |
7 | src/utils/Errors.sol |
8 | src/oracle/Oracle.sol |
9 | src/interfaces/IWithdrawalQueue.sol |
10 | src/interfaces/IWithdrawalProcessor.sol |