WaifuTv

In the contract `LiquidityManager` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority, set the price range, enable the sale, and withdraw token/ETH. 

`initialize()` Is Unprotected The function `initialize()` is `public` and can be called by anyone as long as the contract is deployed.

In the contract `PresaleHelper`, we could know the `price` & `earlyPrice` are used as the unit prices from the context. The variable name `price` & `earlyPrice` could be improved to be like `unitPrice` & `earlyUnitPrice`.

In the functions `payee` and `release`, shares are logged by `tokenId`. But in the function `shares` and `released` , the variable name _shares[**account**] , _released[**account**] and _erc20Released[token][**account**] are inconsistent with the context.

```solidity=99 }else if (mainTokenPrice > maxPrice) { // price is higher than threshold, send more tokens to LP uint256 mainReserveShouldBe = ((1 ether) * usdTokenReserve) / maxPrice; uint256 addMainTokenAmount = mainReserveShouldBe - mainTokenReserve; _sendMainTokensToLP(addMainTokenAmount); direction = StablizationDirection.DOWN; } ``` To stabilize the token price down, liquidity manager need to tranfer more token to pancake swap pair and update the reserves in pair. It would be failed, if the liquidity manager do not have enough token.

`public` functions that are never called by the contract could be declared as `external`. `external` functions are more efficient than `public` functions.

In the contract `waifuToken`, the list named `walletLimitDisabled` is only used to disable the limitation of the token sender's accumulated token transfer in the `transferLimitDuration` as the restriction of `walletTransferLimits`. By the literal understanding of `walletLimitDisabled`, the receiver's balance limitation checking might be controlled by this statement as well in the function `_afterTokenTransfer`. Raise this issue to confirm if the current implementation is by design.

As the stabilization methodology: 1. The selling of the main token takes the USD token out of the liquid pool, which makes the token price go down. 2. When the main token price is lower than the min price, the liquidity manager will remove the main token from the liquid pool. Thus, there is more liquidity removed from the pool by the stabilization, the Liquidity would dry up as its USD token balance run out.

In the functiona `upgradeNodes` and `upgradeNodesBatch`, the contract receives payment from the caller and upgrades the waifu Node from `fromTier` to `toTier`. It is assumed that the `toTier` Price must greater or equal to `fromTier` in the current implementation: ```solidity=263 address account = _msgSender(); uint256 totalPrice = (nodePrices[toTier] - nodePrices[fromTier]) * amount; waifuCashier.getPaymentFrom(account, totalPrice); ``` If a caller wants to upgrade the node to a cheaper tier, this function will revert because of the negative spread.

```solidity=179 return defaultClaimTax - taxRelief; ``` Function `getClaimTaxOf` reverts when defaultClaimTax < taxRelief;