UNO.farm security record

Line 238 in `UnoFarmBalancer` rewards should be the changes of lp token balance in the farm contract before and after staking tokens to vault.

When the user calls the `deposit()` method to deposit assets to the vault, the contract only accumulates liquidity for the user and does not transfer the remaining token back to the user. The remaining token will be stayed in the balancer farm contract, while other farm contracts would transfer those remaining tokens back to user.

If the user calls the `transfer()` function to transfer `UNO-LP` more than `blockedLiquidty[user][lastMoveInfo.block]`, then the remaining leftover tokens corresponding to that `UNO-LP` can not be retrieved when calling `withdraw()`. For example, if A has 40 lp tokens and the `blockedLiquidty[A][lastMoveInfo.block]` is 10, the multiplier in line 187- 188 should be 30. If A transfers 15 lp tokens to B, the multiplier would be 25 and A will never be able to retrieve those leftover tokens.

The code in line 97 of contract UnoAutoStrategy returns two addresses, but the contract `UnoAssetRouterBalancer` method `getTokens()` returns an array. In UnoAssetRouterBalancer.sol ```solidity=159 function getTokens(address lpPool) external view returns(IERC20[] memory tokens){ bytes32 poolId = IBasePool(lpPool).getPoolId(); (tokens, , ) = Vault.getPoolTokens(poolId); } ``` The code in line 141 of contract UnoAutoStrategy mentions the two variables, sentA and sentB, receiving from `pool.assetRouter.deposit`, but the contract `UnoAssetRouterBalancer` only returns one. ```solidity=159 function deposit(address lpPool, uint256[] memory amounts, address[] memory tokens, uint256 minAmountLP, uint256 amountLP, address recipient) external whenNotPaused returns(uint256 liquidity){ ```

Addresses should be checked before assignment or external calls to make sure they are not zero addresses.

It's recommended the team verify the UUPS implementation contract is initialized correctly. Besides initializing the contract, another way to prevent the implementation contract from being used is to invoke the "_disableInitializers" function in the constructor to automatically lock it when it is deployed. For more information, please refer to: https://docs.openzeppelin.com/upgrades-plugins/1.x/writing-upgradeable#initializing_the_implementation_contract

The interface `IWMATIC.sol` is imported, but not used.

Line 124 code is basically the same as line 125 code, just different error message. ```solidity=124 require ((amounts.length == poolTokens.length) && (tokens.length == poolTokens.length), 'BAD_AMOUNTS_LENGTH'); require ((amounts.length == poolTokens.length) && (tokens.length == poolTokens.length), 'BAD_TOKENS_LENGTH'); ```

The return value of the transfer()/transferFrom() call is not checked. ```solidity=176 IERC20(lpPool).transfer(recipient, amount); ```

The linked variables assigned in the constructor can be declared as `immutable`. Immutable state variables can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they will not be stored in storage.