Pegasus

The code comment in line 551 indicates that the `swapAndLiquify()` function is used to "add liquidity". However, the implementation of the `swapAndLiquify()` function swaps the token to BNB and sends it to the privileged `marketingaddress`. ```solidity=587 function swapAndLiquify(uint256 contractTokenBalance) private lockTheSwap { // swap tokens for ETH swapTokensForEth(contractTokenBalance); // <- this breaks the ETH -> HATE swap when swap+liquify is triggered payable(marketingaddress).transfer(address(this).balance); emit SwapAndLiquify(contractTokenBalance, address(this).balance); } ```

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

There are many hardcode addresses in this codebase.

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

A sandwich attack might happen when an attacker observes a transaction swapping tokens without setting restrictions on slippage or minimum output amount. The attacker can manipulate the exchange rate by front-running (before the transaction is attacked) a transaction to purchase one of the assets and make profits by back-running (after the transaction is attacked) 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: - `uniswapV2Router.swapExactTokensForETHSupportingFeeOnTransferTokens()`

The owner is exempt from fees and transaction limits by default. Yet when ownership is reset through `renounceOwnership()` or `transferOwnership()`, the exemptions are not granted to the new owner nor are they revoked from the previous owner.

The `SafeMath` library is used unnecessarily. With Solidity compiler versions 0.8.0 or newer, arithmetic operations will automatically revert in case of integer overflow or underflow. ```solidity=21 library SafeMath { ``` - An implementation of `SafeMath` library is found. --- ```solidity=180 using SafeMath for uint; ``` - `SafeMath` library is used for `uint256` type in `SafeBEP20` contract. --- ```solidity=401 using SafeMath for uint256; ``` - `SafeMath` library is used for `uint256` type in `PEG` contract. ```solidity=477 _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "BEP20: transfer amount exceeds allowance")); ``` - `SafeMath.sub` is called in `transferFrom` function of `PEG` contract. *Note: Only a sample of 2 `SafeMath` library usage in this contract (out of 12) are shown above.*

```solidity=422 event MinTokensBeforeSwapUpdated(uint256 minTokensBeforeSwap); ``` - `MinTokensBeforeSwapUpdated` is declared in `PEG` but never emitted.

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.