Solv Protocol - SolvBTC

The `admin` of the `SftWrappedTokenFactory` contract can upgrade the implementation contract for a given `productType_` by calling `setImplementation()` followed by a call to `upgradeBeacon()`. However, if `upgradeBeacon()` is not called, the `productTypes` mapping in the `SftWrappedTokenFactory` contract will have a mismatched `implementation` address than what is set in the beacon contract.

When the contract admin attempts to remove an SFT slot from the `SolvBTCMultiAssetPool`, the pool contract must have a zero balance of the given SFT slot before removal. Therefore, if even one user fails to withdraw their SFT, the admin will be unable to remove the slot, which allows other users to deposit the SFT slot continually into the contract.

When executing `stake()` in the `SftWrapRouter` contract, the SFT wrapped token registered for the SFT slot in the `SftWrappedTokenFactory` contract is obtained via a call to `SftWrappedTokenFactory.sftWrappedTokens()`. If the returned `sftWrappedToken` address is the zero address, execution will fail, and staking cannot occur for the given SFT slot. This check prevents users from staking SFT slots that are only registered in the `SolvBTVMultiAssetPool` and not registered in `SftWrappedTokenFactory`. Further, the function `_stakeSft()`, which is executed after the `SftWrapRouter` contract receives the SFT, only deposits into the legacy `SftWrappedToken` contract if the `SolvBTCMultiAssetPool` contract disallows the SFT slot. Therefore, the zero address check in `stake()` will prevent non-legacy-supported SFT slots from being staked.