Pepa Inu security record

All initial `PEPA` tokens are sent to the address `_owner` by the following statement when deploying the contract. This is a potential centralization risk as the deployer can distribute `Golteum` tokens without the consensus of the community. ```solidity=1042 _rOwned[owner()] = _rTotal; ```

The error message in the function `includeInReward()` does not describe the error correctly. ```solidity=1225 require(_isExcluded[account], "Account is already excluded") ```

Functions that update state variables should emit relevant events as notifications. For example: setEnableAntiBot(), deliver(), excludeFromReward(), includeInReward(), excludeFromFee(), setTaxFeePercent(), setLiquidityFeePercent(), setCharityFeePercent(), etc.

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=1065 payable(serviceFeeReceiver_).transfer(serviceFee_); ``` - `serviceFeeReceiver_` is not zero-checked before being used.

Generally, deflationary tokens are incompatible with DEX and special rules need to be coded for DEX addresses eg. excluding them from reward.

When the contract is deployed the following addresses are exempted from fees: - the address `_owner` If ownership is transferred or renounced with `transferOwnership()` or `renounceOwnership()`, the exemptions are not granted to the new owner nor are they revoked from the previous owner.

The condition `!_isExcluded[sender] && !_isExcluded[recipient]` can be included in `else` .

The function `constructor()` is payable and sends an arbitrary amount of Ether to an arbitrary address(`serviceFeeReceiver_`). The destination `serviceFeeReceiver_` and Ether amount `serviceFee_` are both passed in as inputs. We want to confirm with the client the purpose of this implementation. ```solidity=1065 payable(serviceFeeReceiver_).transfer(serviceFee_); ```

The function `deliver()` can be called by anyone. It accepts an uint256 number parameter `tAmount`. The function reduces the METT token balance of the caller by `rAmount`, which is `tAmount` reduces the transaction fee. Then, the function adds `tAmount` to variable `_tFeeTotal`, which represents the contract's total transaction fee. We wish the team could explain more on the purpose of having such functionality.

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=201 library SafeMath { ``` - An implementation of `SafeMath` library is found. --- ```solidity=934 using SafeMath for uint256; ``` - `SafeMath` library is used for `uint256` type in `AntiBotLiquidityGeneratorToken` contract. ```solidity=1038 numTokensSellToAddToLiquidity = totalSupply_.div(10**3); // 0.1% ``` - `SafeMath.div` is called in `constructor` function of `AntiBotLiquidityGeneratorToken` contract. *Note: Only a sample of 2 `SafeMath` library usage in this contract (out of 54) are shown above.*