Solv Protocol stUSD - Audit

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

When a user calls `mint()` and the passed amount equals the balance of `sftId_`, the ownership of `sftId_` transfers to the contract. The initial assignment is to `holdingValueSftId`, and the remainder is inserted into `_holdingEmptySftIds`. Subsequently, when a user calls `burn()`, and if `_holdingEmptySftIds` is empty, a new ID regenerates, and ownership remains with the current user. No ownership of `holdingValueSftId` is reclaimed. However, if `_holdingEmptySftIds` is not empty, the last ID is taken and removed. This results in the ownership of the contract transferring to the user. Nevertheless, the number of contracts may not match those initially transferred. Consequently, there will be a discrepancy in the token IDs between the `burn()` and `mint()` operations. Different ERC-3225 token IDs may exhibit varying value differences, potentially leading to losses.