Wemix Retainer 137 HSPFE

In the contract `SPBase`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set vault addresses, set the base fee percentages, set the end block, and set the compounder address.  In the contract `SPMineSchedule`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set pre-stake period information, set the reward schedule, toggle allow pre-stake status.  In the contract `SPBridgeClaim`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set the bridge claim fee percent, set the destination chain, set the token bridge ID, and set the bridge address.  In the contract `SPCoolTime`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set the cool time force fee percent, set the unstake cool time, set the claim cooldown time, and set the stake cool time.  In the contract `HSPFactory`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and end all processes at specified block, deploy HSPforGOD contract and handle outcomes, and set the end block for `HSPforGOD`, after which users can no longer stake/unstake/claim tokens.  In the contract `HSPforGOD`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and pause the function with a specified id which prevents staking, unstaking, or claiming reward, shutdown and transfer token balances, or unpause a specified id.  In the contract `HSPforGOD`, the role `_signer` has authority over the functions shown in the diagram below. Any compromise to the `_signer` account may allow the hacker to take advantage of this authority and set the end block.  In the contract `SignerRole`, the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and add or remove a signer account.  For protocol fees, the fee cap is < 100%, which means that theoretically protocol fees can constitute the vast majority of users' staked tokens or reward tokens.

In the `unstake()` function, the `_claim()` function is called. In order for the `_claim()` function to execute successfully, there needs to be sufficient `rt` token balance in the `rtVault` contract or `address(this)`, depending on the setup of the contract. There is no guarantee that there is always sufficient `rt` token balance, in which case users would be unable to withdraw their staked token balance. Note that while the `onlyMining` modifier used in the `stake()` function enforces that `totalMinedRT() < amountMax` which mitigates the situation in which users stake into the pool when reward has already run out, there's no enforcement that the `rt` token balance in the `rtVault` contract or `address(this)` is consistent with `amountMax` when the pool is set up initially, and as such insufficient reward token balance could still happen.

Not all `IERC20` implementations `revert` when there's a failure in `approve`. The function signature has a `boolean` return value and they indicate errors that way instead. By not checking the return value, operations that should have been marked as failed may potentially go through without actually approving anything.

The in-scope contracts interact with one or more out of scope contracts, such as `recipientRoleV6`, `WemixBridge`, `stVault`, `rtVault`, `rt` and `st` tokens etc. The scope of the audit treats those entities as black boxes and assumes their functional correctness. However, in the real world, those contracts can be compromised and this may lead to lost or stolen assets. In addition, `rt` and `st` tokens cannot be deflationary or fee-on-transfer tokens, and upgrades of any out-of-scope contract can potentially create severe impacts.