Solv Protocol security record

The `SftWrapRouter` contract inherits upgradeable contracts, indicating that it is part of an upgradeable system. Upgradeable contracts often pair with a proxy contract that is responsible for managing contract upgrades. The privileged roles of the proxy often have the authority to update the implementation contract. Any compromise to the privileged 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 report gives no description here.

The report gives no description here.

The `getNav()` function of `SolvBTCYieldTokenOracleForSFT` returns the latest NAV of the specified ERC-20 token but ignores the latest set NAV time. Without validating that the returned NAV time is within a reasonable range, there may be risks of using outdated information. An outdated NAV value may affect the conversion rate between shares and assets of a `SolvBTCYieldToken`.

When calling `importProductProxy()`, the `productTypes[productType_].beacon` may be different from the beacon address used by the imported proxy. Therefore, the imported proxy may not upgrade since it is pointing to a different beacon.

According to the protocol design, the `SolvBTCMultiAssetPool` contract may receive ERC-3525 tokens. Therefore, it is best practice to implement the ERC-165 interface and define the `onERC721Received()` and `onERC3525Received()` functions to return the corresponding magic values. Some SFT implementations, such as `OpenFundShareDelegate`, allow the ERC-3525 receiver to revert on the ERC-165 `supportsInterface()` call and consider the receiver capable of receiving ERC-3525 tokens. However, this behavior is not guaranteed in other SFT implementations.

The `FunctionAuthorization._checkSingleTx()` of the Solv Vault Guardian relies on a static mapping of function selectors before proceeding with ACL checks to validate transactions. This design does not accommodate the mutable design of upgradeable contracts, where function selectors might change after upgrades. Particularly for upgradeable contracts with payable fallback functions, this static mapping approach can lead to erroneous behavior, as the guardian may authorize or block transactions based on outdated information. Additionally, if an upgradeable contract were approved, the implementation of the approved function is subject to change.

The Solv Vault Guardian implements a mechanism to validate native token transfers, through the `_checkNativeTransfer()` function to validate transactions based on a list of approved receivers `nativeTokenReceiver`. This check is invoked only when the transaction's calldata is empty. However, this approach does not account for payable functions where the calldata is non empty, thereby bypassing the `_checkNativeTransfer()` validation when `msg.value` is sent alongside calldata. This design choice introduces a discrepancy in how native token transfers are validated, potentially allowing for native token disbursements without proper authorization checks when calldata is present.

The Solv protocol introduces guardian checks through the Authorization mechanism before transactions of the Safe are executed. These checks, depending on the protocol the Safe is interacting with, primarily focus on assessing tokens in, tokens out, and the recipients of swapped funds. The aim is to ensure transactions comply with the allowed types and adhere to the rules set by the Authorization contract. However, the framework does not effectively guard against slippage attacks. It allows Safe owners to set potentially exploitative transaction parameters, such as a zero minimum for tokens out during swaps, potentially bypassing the protective intent of the Authorization checks.

Currently, some of the ACL implementations that allow token whitelisting only allow them to be added via `_addTokenWhitelist()` during deployment. There is no way to modify this token whitelist following deployment. This could be an issue if one of the tokens becomes compromised or is no longer supported, or, if there are additional tokens that would want to be supported by Solv in the future.