Liquid Protocol security record

In the contract `Ownable` 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 transfer ownership to any address and renounce ownership.  In the contract `liquidprotocol` 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 `tradingEnabled`, `swapEnabled`, and `genesis_block`, exclude the account from the reward, include the account in reward, exclude the account from fee, include the account in fee, set taxes, airdrop tokens to any address, bulk exclude accounts from the fee, set `marketingWallet`, `donationWallet`, `coolDownTime`, `coolDownEnabled`, `swapTokensAtAmount`, `swapEnabled`, `_isBlacklisted`, `allowedTransfer`, `maxBuyLimit`, `maxSellLimit`, `router`, `pair`, transfer ETH to the owner and transfer any tokens to any address. 

```solidity=824 // add the liquidity router.addLiquidityETH{value: bnbAmount}( address(this), tokenAmount, 0, // slippage is unavoidable 0, // slippage is unavoidable owner(), block.timestamp ); ``` The `addLiquidity()` function calls the `router.addLiquidityETH` function with the `to` address specified as `owner()` for acquiring the generated LP tokens from the `LP-ETH` pool. As a result, over time the `_owner` address will accumulate a significant portion of LP tokens. If the `_owner` is an EOA (Externally Owned Account), mishandling of its private key can have devastating consequences to the project as a whole.

There is no upper limit restricting parameters `_rfi`,`_marketing`,`_liquidity`, and `_donation` of `setSellTaxes()`/`setTaxes()`. This lack of limitation potentially allows for fees on transactions of up to 100%.

Variable `_rOwned[account]` is not updated in the function `includeInReward()`, which will make the accounts included siphon off the tokens out of the balances of all token holders. The Rate was higher at the moment of the `excludeFromReward(account)` call, so the `_rOwned[account] / _tOwned[account]` ratio is bigger than expected for accounts included in the reward. ```solidity =331 function includeInReward(address account) external onlyOwner() { require(_isExcluded[account], "Account is not excluded"); for (uint256 i = 0; i < _excluded.length; i++) { if (_excluded[i] == account) { _excluded[i] = _excluded[_excluded.length - 1]; _tOwned[account] = 0; _isExcluded[account] = false; _excluded.pop(); break; } } } ```

Addresses are not validated before assignment or external calls, potentially allowing the use of zero addresses and leading to unexpected behavior or vulnerabilities. For example, transferring tokens to a zero address can result in a permanent loss of those tokens. ```solidity=628 marketingWallet = newWallet; ``` - `newWallet` is not zero-checked before being used. --- ```solidity=632 donationWallet = newWallet; ``` - `newWallet` is not zero-checked before being used. --- ```solidity=675 pair = newPair; ``` - `newPair` is not zero-checked before being used.

In the `constructor`, the pair is excluded from rewards. However, the new pair is not excluded from rewards in the function `updateRouterAndPair()`.