PepeAI CEO

One or more declarations do not conform to the Solidity style guide with regards to its [naming convention](https://docs.soliditylang.org/en/latest/style-guide.html#naming-conventions). Particularly: * camelCase: Should be applied to function names, argument names, local and state variable names, modifiers * UPPER_CASE: Should be applied to constant variables * CapWords: Should be applied to contract names, struct names, event names and enums ```solidity=69 function WETH() external pure returns (address); ``` - Function `WETH` is not in `camelCase`. --- ```solidity=178 string constant private _name = "PEPEAICEO"; ``` - Constant variable `_name` is not in `UPPER_CASE`. --- ```solidity=179 string constant private _symbol = "PEPEAICEO"; ``` - Constant variable `_symbol` is not in `UPPER_CASE`. --- ```solidity=180 uint8 constant private _decimals = 18; ``` - Constant variable `_decimals` is not in `UPPER_CASE`. --- ```solidity=193 event _enableTrading(); ``` - Event `_enableTrading` is not in `CapWords`. --- ```solidity=194 event _setPresaleAddress(address account, bool enabled); ``` - Event `_setPresaleAddress` is not in `CapWords`. --- ```solidity=195 event _toggleCanSwapFees(bool enabled); ``` - Event `_toggleCanSwapFees` is not in `CapWords`. --- ```solidity=196 event _changePair(address newLpPair); ``` - Event `_changePair` is not in `CapWords`. --- ```solidity=197 event _changeThreshold(uint256 newThreshold); ``` - Event `_changeThreshold` is not in `CapWords`. --- ```solidity=198 event _changeWallets(address marketing); ``` - Event `_changeWallets` is not in `CapWords`. --- ```solidity=271 function is_buy(address ins, address out) internal view returns (bool) { ``` - Function `is_buy` is not in `camelCase`. --- ```solidity=276 function is_sell(address ins, address out) internal view returns (bool) { ``` - Function `is_sell` is not in `camelCase`. --- ```solidity=281 function is_transfer(address ins, address out) internal view returns (bool) { ``` - Function `is_transfer` is not in `camelCase`.

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

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=330 marketingAddress = payable(marketing); ``` - `marketing` is not zero-checked before being used.

A sandwich attack may 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 (executing before the target) a transaction to purchase one of the assets and make profits by back running (executing after the target) a transaction to sell the asset. The following function is called without setting restrictions on slippage or minimum output amount, so transactions triggering the function is vulnerable to sandwich attacks, especially when the input amount is large: - `swapRouter.swapExactTokensForETHSupportingFeeOnTransferTokens()`

In the function `internalSwap()`, the following code: ```solidity function internalSwap(uint256 contractTokenBalance) internal inSwapFlag { ... if (_allowances[address(this)][address(swapRouter)] != type(uint256).max) { _allowances[address(this)][address(swapRouter)] = type(uint256).max; } ``` is redundant. Because the allowance of the `_allowances[address(this)][address(swapRouter)]` has already been set to `type(uint256).max` in the constructor, and the `transferFrom()` function would not change the allowance.

The linked statements do not affect the functionality of the codebase and appear to be either leftovers from test code or older functionality.

State variables that never change should be declared as `constant` to save gas. ```solidity=168 uint256 private swapThreshold = _totalSupply / 7_000; ``` - `swapThreshold` should be declared `constant`.

According to the following code in the constructor: ```solidity _approve(msg.sender, address(swapRouter), type(uint256).max); ``` The contract approves the max value from the `msg.sender` to `address(swapRouter)` which seems to serve no purpose but have potential risks, we would like to confirm with the client the design of the code and whether it is redundant.

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 assumes 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=177 IRouter02 public swapRouter; ``` - The contract `PEPEAICEO` interacts with third party contract with `IRouter02` interface via `swapRouter`.

Some events are never emitted, which can lead to confusion and code maintainability issues. ```solidity=197 event _changeThreshold(uint256 newThreshold); ``` - `_changeThreshold` is declared in `PEPEAICEO` but never emitted.