<username>{{ maskedUsername }}</username><space /><text>just voted for</text><space /><projectButton />

<username>{{ maskedUsername }}</username><space /><text>just voted for</text><space /><projectLogo /><space /><projectName>{{ projectName }}</projectName>

Bug Bounty rewards are grouped by severity and the impact of the vulnerability. Examples and descriptions of the type of vulnerabilities that correspond to each severity level can be found below. The payout amount has a 5 tier structure with separate scalesfor website/apps and smart contracts.

Description of vulnerability and your proof of concept or validation steps

Name

Please input a title

Short description of the vulnerability and the affected asset.

The core team is situated in country(ies) that received low aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests an increased difficulty and complexity in preventing and mitigating fraud.

The core team is situated in country(ies) that received medium aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests a medium level of geographic accountability, thus reducing and mitigating the risk of fraud.

The core team is situated in country(ies) that received the best aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests the highest level of geographic accountability, thus maximizing the risk reduction and mitigation.

Vulnerability Title

transfer

transferFrom

totalSupply

balanceOf

allowance

approve

PEPEAICEO

In the contract `Ownable` the role `_owner` has authority over the functions shown in the diagram below.
![](https://accelerator-tasks-prod.s3.amazonaws.com/86d2c64fe6944866b870a560e7bc806a/diagrams/centralization_PEPEAICEO-Ownable-_owner.svg)

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and:
- function `transferOwnership`: to change the `owner` to another address.
- function `renounceOwnership`: to set the `owner` address to zero.


In the contract `PEPEAICEO` the role `_owner` has authority over the functions shown in the diagram below.
![](https://accelerator-tasks-prod.s3.amazonaws.com/86d2c64fe6944866b870a560e7bc806a/diagrams/centralization_PEPEAICEO-PEPEAICEO-_owner.svg)

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and:
- function `setNoFeeWallet`: to make an `address` included or excluded from fees.
- function `changeLpPair`: to add a `newPair` address as Lp pair addresses.
- function `toggleCanSwapFees`: to set the `canSwapFees` to `true` or `false`.
- function `changeWallets`: to set the new `marketingAddress` to receive all the fees in the contract which have been converted to BNBs in the `internalSwap()`.
- function `setPresaleAddress`: to set an address out of or in the presale addresses list and include or exclude from the fees.
- function `enableTrading`: to enable the trading process.


Centralization Risks in PEPEAICEO.sol

Tokens are sent to the contract deployer when deploying the contract, and according to the whitepaper available on the official website (https://whitepaper.pepeaiceo.com/tokenomics), the token allocation plan is as follows:

`Burn: 50%` 

`Presale: 25%`

`Liquidity: 14.24%` 

`CEX & Marketing: 10.75%`

While we have confirmed that the `Burn: 50%` distribution aligns with the plan, we kindly request the team to provide us with the precise transaction hashes for the other distribution plans. This will enable us to verify if the token allocation is in accordance with the outlined plan. 

Initial Token Distribution

```solidity=698
    function internalSwap(uint256 contractTokenBalance) internal inSwapFlag {
        
        address[] memory path = new address[](2);
        path[0] = address(this);
        path[1] = swapRouter.WETH();

        if (_allowances[address(this)][address(swapRouter)] != type(uint256).max) {
            _allowances[address(this)][address(swapRouter)] = type(uint256).max;
        }

        try swapRouter.swapExactTokensForETHSupportingFeeOnTransferTokens(
            contractTokenBalance,
            0,
            path,
            address(this),
            block.timestamp
        ) {} catch {
            return;
        }
        bool success;

        if(address(this).balance > 0) {(success,) = marketingAddress.call{value: address(this).balance, gas: 35000}("");}

    }
```

The `internalSwap()` function calls the `uniswapV2Router.swapExactTokensForETHSupportingFeeOnTransferTokens()` function to swap the `PEPEAICEO` tokens to BNB and send the BNB to the `marketingAddress` address.

As a result, over time the `marketingAddress` address will accumulate a significant portion of BNB. If the `marketingAddress` is an EOA (Externally Owned Account), the mishandling of its private key can have devastating consequences for the project as a whole.

For the common deflationary token, the entire tokenomic requires certain liquidity to support. However, in the current implementation, the swapped BNB is transferred to `marketingAddress` and is not being used for adding liquidity. Therefore, the entire tokenomic may crash due to lacking enough liquidity in the BNB-PEPEAICEO pool.
 

Sending Ether to Arbitrary Destinations

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`.

 

Third-Party Dependency Usage

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.

 

Missing Zero Address Validation

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`.



State Variable Should Be Declared Constant

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.

Variables That Could Be Declared as Immutable

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()` 

Potential Sandwich Attacks

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 redundant approval

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

Missing Emit Events

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

Redundant Code Components

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.



Unused Event

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`.



Declaration Naming Convention Violation

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.

Redundant allowances modification

PepeAI CEO

PEPEAICEO.sol

PEPE AI CEO aims to leverage the concepts of Pepe, AI, and CEO to create a unique and valuable crypto currency token that is backed by AI algorithms and supported by their team of visionary leaders.

Leaderboards

Due Diligence Tools

Resources

KYC Status

Bug Bounty Program