Honor World Token security record

In the contract `CrystalFarming` 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.  In the contract `CrystalFarming` the role `devaddr` has authority over the functions shown in the diagram below. Any compromise to the `devaddr` account may allow the hacker to take advantage of this authority. 

`CrystalFarming` is an upgradeable contract, the owner can upgrade the contract without the community's commitment. If an attacker compromises the account, he can change the implementation of the contract and drain tokens from the contract.

In the contract `HWTToken` 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 and set the mainPool address.  In the contract `HWTToken` the role `mainPool` has authority over the functions shown in the diagram below. Any compromise to the `mainPool` account may allow the hacker to take advantage of this authority and mint HWT to an arbitrary address. 

In the contract `LPStaking` 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 and add new liquidity pools and modify the allocation points of the existing ones.  In the contract `LPStaking` the role `devAddress` has authority over the functions shown in the diagram below. Any compromise to the `devAddress` account may allow the hacker to take advantage of this authority to change the `devAddress` address, which receives fees when a withdrawal takes place. 

In the contract `NFTStaking` 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 and arbitrarily set `ApprovedMinter` and `ApprovedOperator` roles, as well as the AuraRule address.  -------------------------------- The role `ApprovedMinter` has the authority to function `directStake()` to stake token on other user's behalf. The role `ApprovedOperator` has the authority to the following functions to manage NFT tokens' ownership: - `escrowOwnership()` - `restoreOwnership()` - `transferOwnership()` Any compromise to the `ApprovedMinter` or `ApprovedOperator` account may allow the hacker to take advantage of this authority and stake or lock user's NFT tokens without their consent.

In the contract `StrategyPSC` the role `devAddress` has authority over the functions shown in the diagram below. Any compromise to the `devAddress` account may allow the hacker to take advantage of this authority and arbitrarily set `devAddress`, which receives the dev fees.  In the contract `StrategyPSC` the role `govAddress` has authority over the functions shown in the diagram below. Any compromise to the `govAddress` account may allow the hacker to take advantage of this authority and arbitrarily set multiple important addresses and disrupt normal contract process by pause/unpause.  In the contract `StrategyPSC` the role `harvestAddress` has authority over the functions shown in the diagram below. Any compromise to the `harvestAddress` account may allow the hacker to take advantage of this authority and take control over harvest and earn process. 

The variable `boostToken` is always `address(0)`, and the function `boostReachMax()` always returns 0.

When transferring standard ERC20 deflationary tokens, the input amount may not be equal to the received amount due to the charged transaction fee. For example, if a user stakes 100 deflationary tokens (with a 10% transaction fee) in a MasterChef contract, only 90 tokens actually arrive in the contract. However, the user can still withdraw 100 tokens from the contract, which causes the contract to lose 10 tokens in such a transaction. Reference: https://thoreum-finance.medium.com/what-exploit-happened-today-for-gocerberus-and-garuda-also-for-lokum-ybear-piggy-caramelswap-3943ee23a39f

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 assume 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=46 IERC1155Upgradeable public rewardToken; ``` - The contract `CrystalFarming` interacts with third party contract with `IERC1155Upgradeable` interface via `rewardToken`. --- ```solidity=47 IRewardSupplierMultiPool public rewardSupplier; ``` - The contract `CrystalFarming` interacts with third party contract with `IRewardSupplierMultiPool` interface via `rewardSupplier`. --- ```solidity=240 function deposit(address _token, uint256 _amount) ``` - The function `CrystalFarming.deposit` interacts with third party contract with `IERC20Upgradeable` interface via `_token`. --- ```solidity=276 function withdraw(address _token, uint256 _amount) ``` - The function `CrystalFarming.withdraw` interacts with third party contract with `IERC20Upgradeable` interface via `_token`. --- ```solidity=365 function _distributeFee(address _token, uint256 _fee) internal { ``` - The function `CrystalFarming._distributeFee` interacts with third party contract with `IERC20Upgradeable` interface via `_token`.

One or more state variables are used without being initialized in the constructor. ```solidity=53 address[] public registeredTokens; ``` - `registeredTokens` is never initialized, but used in `CrystalFarming.poolLength`.