Solv Yield - Bearing Tokens

The `swtAddress_` parameter of `unstake()` function is missing a check to ensure it is deployed by the `SftWrappedTokenFactory`, allowing users to specify an arbitrary address as the `swtAddress_`. Calling a user provided address is not safe, especially in a public function with no access control restriction. For example, if a non-standard ERC3525 token is transferred to the router without triggering `onERC3525Received` or `onERC721Received`, a malicious `swtAddress_` contract could be used to transfer the token to the attacker (L149).

The `createSubscription()` is a payable function, indicating it allows users to transfer native tokens to the router. Line 164 of the contract calls the function `ERC20TransferHelper.doTransferIn()` to transfer native tokens to the router if `poolInfo.currency` being equal to `ETH_ADDRESS`. However, the router contact does not deposit the received native tokens to the designated contract `IOpenFundMarket(openFundMarket)` (L167), and the `IOpenFundMarket::subscribe()` is not a payable function.

Contract `SftWrapRouter` extends `ReentrancyGuardUpgradeable`, but the extended contract is not initialized by the current contract. Generally, the initializer function of a contract should always call all the initializer functions of the contracts that it extends.

The `stake()` function ensures the token amount to be wrapped cannot be zero: ```solidity=117 require(amount_ > 0, "SftWrapRouter: stake amount cannot be 0"); ``` Users can transfer tokens directly to the router without triggering the `stake()` function, thereby bypassing the zero-amount check.

Test code should be removed prior to on-chain deployment: ```solidity=15 import "../lib/forge-std/src/console. Sol"; ```

The `SftWrapRouter` contract does not protect their initializers. An attacker can call the initializer and assume ownership of the logic contract, whereby she can perform privileged operations that trick unsuspecting users into believing that she is the owner of the upgradeable contract.