HyperonChain security record

The report gives no description here.

During contract creation, the initialized `lpPair` is excluded from dividends as defined in ```solidity=244 _isExcludedFromDividends[lpPair] = true; ``` Then, in function `function setLpPair(address pair, bool enabled) external onlyOwner` the contract has the ability to setup a new LP pair address. However, the new LP pair address is not excluded from dividends. As a consequence, user's might get less token as reward or if wallet limit is not set, users might not able to trade properly.

In function `contractswap()` there is a calculation error that does not check the balance change after check swap, but instead directly uses the contract's balance. Therefore if someone directly transfers ETH or BNB to the current contract, it could lead to a dividend calculation error.

Since current contract can be compiled with Solidity versions from 0.6.0 to 0.9.0, it exists the possibility to be compiled with a version that does not add checks for overflows and underflows at compilation time. This could lead to overflow and underflow errors in those math operations defined in the contract, leading to unexpected bugs and errors.

The following dependencies are missing from the codebase and only their interface is known: - Cashier contract - AntiSnipe contract Additional, 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=162 IRouter02 public dexRouter; ``` - The contract `HyperonChain` interacts with third party contract with `IRouter02` interface via `dexRouter`. --- ```solidity=179 Cashier reflector; ``` - The contract `HyperonChain` interacts with third party contract with `Cashier` interface via `reflector`. --- ```solidity=193 AntiSnipe antiSnipe; ``` - The contract `HyperonChain` interacts with third party contract with `AntiSnipe` interface via `antiSnipe`.

The report gives no description here.

The function `transferFrom` does not check whether the value of `_allowances` is greater than or equal to `amount` unless the Solidity version 0.8.0 or above is used.

There are many Router hardcode addresses in this codebase. At deploy time, an address is selected depending on detected chain Id value. Hardcoded router related addresses are listed below: - `0x10ED43C718714eb63d5aA57B78B54704E256024E` - `0xD99D1c33F9fC3444f8101754aBC46c52416550D1` - `0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D` - `0x60aE616a2155Ee3d9A68541Ba4544862310933d4` - `0xF491e7B69E4244ad4002BC14e878a34207E38c29`

Function `setDividendExcluded()` does not take into consideration the check for `DEAD` address. ```solidity=403 function setDividendExcluded(address holder, bool enabled) public onlyOwner { require(holder != address(this) && holder != lpPair); _isExcludedFromDividends[holder] = enabled; ... } ``` According to contract logic, `DEAD` is the address for token destruction and it is set to not participate in dividends in the constructor, but the check for `DEAD` is not included in the `setDividendExcluded` function.

In function `multiSendTokens` exists an iteration over an externally defined array `accounts`. The error remains in following for loop definition: ```solidity=729 for (uint8 i = 0; i < accounts.length; i++) ``` Note how the `i` variable gets incremented by one until reaches its limit or reaches the `accounts.length` value. In case of having more than 255 input elements in the `accounts` variable, the execution will be reverted.