We2net security record

Performing integer division before multiplication truncates the low bits, losing the precision of calculation. ```solidity=1116 uint256 topReward = totalReward.mul(_topRewardRate).div(_rewardBase); ``` ```solidity=1118 uint256 nodeReward = topReward.mul(rewardRate[nodeLevel]).div(_rewardBase); ``` --- ```solidity=1140 uint256 topReward = totalReward.mul(_topRewardRate).div(_rewardBase); ``` ```solidity=1142 uint256 nodeReward = topReward.mul(rewardRate[nodeLevel]).div(_rewardBase); ``` --- ```solidity=916 uint256 topReward = totalReward.mul(_topRewardRate).div(_rewardBase); ``` ```solidity=918 uint256 nodeReward = topReward.mul(levelInfo[nodeLevel].rewardRate).div(_rewardBase); ``` --- ```solidity=940 uint256 topReward = totalReward.mul(_topRewardRate).div(_rewardBase); ``` ```solidity=942 uint256 nodeReward = topReward.mul(levelInfo[nodeLevel].rewardRate).div(_rewardBase); ```

The functions in` TransferHelper` is missing a sanity check to ensure the parameter `token` is a contract. If the `token` is an EOA, the function call `token.call()` will always return true.

In the contract `LiquidityHub`, functions that update state variables should emit relevant events as notifications. - function setEndTime - function setManger - function setTaxRate - function setTaxAndRewardBase - function setTopRewardRate - function setRewardRate ____ In the `we2net`, functions that update state variables should emit relevant events as notifications. - function setManger - function setMinter - function setStartTime - function setTaxAndFeeManger - function setTaxAndRewardBase - function excludedFromTax - function setTaxFrom - function setTaxTo - function setRootNode - function setParentNodeByManager - function setLevelsCountAndRewardRate - function setLevelInfo - function setClaimAmount

In the contract `LiquidityHub`, `setEndTime` do not check if new endtime > block.timestamp

Addresses should be checked before assignment or external call to make sure they are not zero addresses. ```solidity=904 we2netToken = _we2netToken; ``` - `_we2netToken` is not zero-checked before being used. --- ```solidity=905 usdtToken = _usdtToken; ``` - `_usdtToken` is not zero-checked before being used. --- ```solidity=906 pair = _pair; ``` - `_pair` is not zero-checked before being used. --- ```solidity=907 wbnb = _wbnb; ``` - `_wbnb` is not zero-checked before being used. --- ```solidity=908 pairWbnbUsdt = _pairWbnbUsdt; ``` - `_pairWbnbUsdt` is not zero-checked before being used. --- ```solidity=1077 _taxManager = taxManager; ``` - `taxManager` is not zero-checked before being used. --- ```solidity=1078 _feeManager = feeManager; ``` - `feeManager` is not zero-checked before being used. --- ```solidity=1079 _recycleManager = recycleManager; ``` - `recycleManager` is not zero-checked before being used. --- ```solidity=810 _taxManager = taxManager; ``` - `taxManager` is not zero-checked before being used. --- ```solidity=811 _feeManager = feeManager; ``` - `feeManager` is not zero-checked before being used. --- ```solidity=840 rootNode = _rootNode; ``` - `_rootNode` is not zero-checked before being used.

A sandwich attack may happen when an attacker observes a transaction swapping tokens or adding/removing liquidity without setting restrictions on slippage or minimum output amount. The attacker can manipulate the exchange rate by frontrunning (executing before the target) a transaction to purchase one of the assets and make profits by backrunning (executing after the target) a transaction to sell the asset. The following functions are called without setting restrictions on slippage or minimum output amount, so transactions triggering these functions are vulnerable to sandwich attacks, especially when the input amount is large: - removeLiquidity - addLiquidity - addBnbLiquidity

The change of `_owner` by function `transferOwnership()` overrides the previously set `_owner` with the new one without guaranteeing the new `_owner` is able to actuate transactions on-chain.

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=872 address public pair; ``` - The contract `LiquidityHub` interacts with third-party contract with `IPancakePair` interface via `pair`. --- ```solidity=873 address public wbnb; ``` - The contract `LiquidityHub` interacts with third-party contract with `IWETH` interface via `wbnb`. --- ```solidity=874 address public pairWbnbUsdt; ``` - The contract `LiquidityHub` interacts with third-party contract with `IPancakePair` interface via `pairWbnbUsdt`.

In the contract `we2net`, everytime a childNode set a parent, totalNodesCount++. If the same _parent address is set by two childNode. It will be double counted. ## Imapct As the `totalNodesCount` is only used as a rootNode initialable flag in the function `setRootNode`, It does not impact the contract functionalities.

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.