Solv Protocol security record

In the contract `GovernorControl` the role `governor` has authority over the functions shown in the diagram below. Any compromise to the `governor` account may allow the hacker to take advantage of this authority and set the pending governor's address.  In the contract `GovernorControl` the role `pendinggovernor` has authority over the functions shown in the diagram below. Any compromise to the `pendinggovernor` account may allow the hacker to take advantage of this authority and set the governor's address.  ----- In the contract `AdminControl` the role `admin` has authority over the functions shown in the diagram below. Any compromise to the `admin` account may allow the hacker to take advantage of this authority and set the pending admin's address.  In the contract `AdminControl` the role `pendingAdmin` has authority over the functions shown in the diagram below. Any compromise to the `pendingAdmin` account may allow the hacker to take advantage of this authority and set the admin's address.  ----- In the contract `SftWrappedTokenFactory` the role `admin` has authority over the functions shown in the diagram below. Any compromise to the `admin` account may allow the hacker to take advantage of this authority and - set the implementation address - deploy the Beacon proxy - upgrade the implementation of the Beacon proxy - transfer the ownership of the Beacon proxy to the new owner  In the contract `SftWrappedTokenFactory` the role `governor` has authority over the functions shown in the diagram below. Any compromise to the `governor` account may allow the hacker to take advantage of this authority and deploy/remove product proxy. 

In the contract `SftWrappedToken`, the role `admin` of the proxy has the authority to update the implementation contract behind the proxy contract. Any compromise to the `admin` account may allow a hacker to take advantage of this authority and change the implementation contract which is pointed by proxy and therefore execute potential malicious functionality in the implementation contract.

The asset pools assume that different slots of a specific semi-fungible token contract maintain an exchange rate of 1:1. However, if any asset/slot depegs, an attacker can drain the respective asset pool of value. This effect is aggravated since there are only implicit delays between staking and unstaking. Particularly, wBTC is not a safe asset since it frequently depegs as it implements a delay for unwrapping.

Safe can add modules that introduce additional functionalities beyond the core Safe capabilities. While these modules enhance the utility of Safe by allowing custom features, they also carry the ability to execute arbitrary transactions once installed. Currently, transactions initiated by these modules do not undergo guardian checks, presenting a loophole if the `enableModule()` function is permitted by the guardian settings. This lack of guardian oversight for module-executed transactions can be used to bypass Solv vault guardian checks.

The contract is serving as the underlying entity to interact with one or more third party protocols. The scope of the audit treats third party entities as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. ```solidity=43 address public wrappedSftAddress; ``` - The contract `SftWrappedToken` interacts with third party contract with `IERC3525` interface via `wrappedSftAddress`. --- ```solidity=45 address public navOracle; ``` - The contract `SftWrappedToken` interacts with third party contract with `INavOracle` interface via `navOracle`.

The `withdrawFeeRate` is an admin-controlled parameter that can be updated at any time and is applied immediately when users call the `withdrawBTCPlus()` function. Since users typically estimate their expected net `solvBTC` output off-chain before submitting a transaction, a fee update occurring shortly before execution may result in users receiving less value than anticipated. This creates a front-running-style risk where a legitimate admin fee update, applied between a user’s transaction submission and execution, may lead to reduced `solvBTC` output. Although the admin is assumed to operate in good faith, users who are unaware of recent parameter changes or rely on stale off-chain data have no on-chain protection against this behavior due to the absence of a minimum output check.

This contract acts as a rate limited redeem mechanism, imposing both total limits per time period and limits for single withdrawal actions. However, a single user could submit multiple calls to `withdrawBTCPlus()` within a single transaction to exhaust the entire total limit, which can be retrieved from `remainingWithdrawAmount()`.

The `withdrawBTCPlus()` function relies on `getValueByShares()`, which depends on the external NAV of `BTC+`. Since the NAV can legitimately increase or decrease over time, a deviation between transaction submission and execution may result in users receiving less solvBTC than expected, even without any malicious behavior.

The report gives no description here.

The contract is serving as the underlying entity to interact with the out-of-scope contracts `IOpenFundMarket` and deposit tokens to the `IOpenFundMarket`. The scope of the audit treats these entities as black boxes and assumes their functional correctness. However, in the real world, external dependencies and out-of-scope contracts can be compromised and this may lead to lost or stolen assets.