HyperonChain security record

In the contract `HyperonChain`, the role `owner` has authority over the following functions that include `onlyOwner` modifier: - `transferOwner()` - `renounceOwnership()` - `approveContractContingency()` - `setNewRouter()` - `setLpPair()` - `setInitializers()` - `setExcludedFromLimits()` - `setDividendExcluded()` - `setExcludedFromFees()` - `setExcludedFromProtection()` - `removeSniper()` - `setProtectionSettings()` - `setWallets()` - `setTaxes()` - `setRatios()` - `setMaxTxPercent()` - `setMaxWalletSize()` - `setSwapSettings()` - `setPriceImpactSwapAmount()` - `setContractSwapEnabled()` - `setRewardsProperties()` - `setReflectorSettings()` - `excludePresaleAddresses()` - `enableTrading()` - `multiSendTokens()` - `manualDeposit()` - `sweepContingency()` Additionally to this, other functions are also restricted to `originalDeployer` address, which by default is set to `msg.owner` and thus, can be considered as an alias of `onlyOwner`. - `setOperator()` - `renounceOriginalDeployer()` In both previous cases, the following required statement is used ```solidity=289 require(msg.sender == originalDeployer, "Can only be called by original deployer."); ``` Any compromise to the `owner` account may allow a hacker to take advantage of this authority and execute privileged functions. Besides, in the contract HyperonChain, the function `_transfer()` includes the following limitations on transfers: * transfers can be enabled or disabled depending on the configuration set by the development team. * there is a maximum amount control, that once exceeded, further transfers will be reverted. * privileged roles are excluded from previous constraints.

All of the **HyperonChain** tokens are sent to the contract deployer when deploying the contract. This could be a centralization risk as the deployer can distribute **HyperonChain** tokens without obtaining the consensus of the community.

In function `setLpPair()` there is an inconsistency in the **require()** declaration below. ```solidity=368 require(block.timestamp - timeSinceLastPair > 3 days, "Cannot set a new pair this week!"); ``` We understand that the period considered as a week should be at least of 5 days, with at most 7 days. However, the blocking period is set to 3 days.

Current token transfer approval implementations are vulnerable to [a known ERC20 race condition issue](https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729), which could lead to token theft. When a user calls `approve()` for a second time on a spender that has already been allowed, the spender could call `transferFrom()` to transfer the previous value and still receive the authorization to transfer the new value. Exploit scenario: 1. Alice calls `approve(Bob, 100)` to allow Bob to spend 100 tokens. 2. Alice changes her mind and calls `approve(Bob, 50)`. 3. Bob observes the second `approve(Bob, 50)` function call and calls `transferFrom(Alice, Bob, 100)` before the second `approve(Bob, 50)` call. 4. The above scenario can be achieved by front-running. In this case, Bob can transfer another 50 tokens from Alice and in total, he transferred 150 tokens from Alice.

A sandwich attack might happen when an attacker observes a transaction swapping tokens or adding liquidity without setting restrictions on slippage or minimum output amount. The attacker can manipulate the exchange rate by frontrunning (before the transaction being attacked) a transaction to purchase one of the assets and make profits by back running (after the transaction being attacked) a transaction to sell the asset. At some point during the call to `_transfer()`function the following code will be eventually executed ```solidity=601 try dexRouter.swapExactTokensForETHSupportingFeeOnTransferTokens( contractTokenBalance, 0, path, address(this), block.timestamp ) {} catch { return; } ``` As a consequence, when no setting restrictions on slippage or minimum output amount, transactions triggering these functions are vulnerable to sandwich attacks, especially when the input amount is large.