Read the findings of the 2022 Web3 Security Report

In the contract `AtEM` the role `owner` has authority over the functions listed below:
- `setMaxWalletPercent_base1000`: manage the state variable `_maxWalletToken`
- `setMaxTxPercent_base1000`: manage the state variable `_maxTxAmount`
- `clearStuckBalance`: transfer the BNBs stuck in the contract to `msg.sender`
- `clearStuckToken`: transfer tokens stuck in the contract to the specified address
- `tradingStatus`: manage the state variables `tradingOpen` and `antibot`
- `tradingStatus_launchmode`: manage the state variable `launchMode`
- `manage_blacklist_status`: manage the state variable `blacklistMode`
- `manage_blacklist`: manage the state variable `isBlacklisted`
- `setFees`: manage the state variables `liquidityFee`, `marketingFee`, `teamFee`, `gamingFee`, `utilityFee` and `totalFee`
- `setFeeReceivers`: manage the state variables `autoLiquidityReceiver`, `marketingFeeReceiver`, `teamFeeReceiver`, `gamingFeeReceiver` and `utilityFeeReceiver`
- `setSwapBackSettings`: managet state variables `swapEnabled` and `swapThreshold`

Any compromise to the `owner` account may allow the hacker to take advantage of this authority, change the configuration of this contract, and transfer tokens/BNB in the contract.

In the contract `AtEM` the role `devFeeReceiver` has authority over the functions listed below:
- `setFeeReceivers_dev`: manage the state variable `devFeeReceiver`

Any compromise to the `devFeeReceiver` account may allow the hacker to take advantage of this authority and update the `devFeeReceiver` address.

In the contract `AtEM` the role `authorizations` has authority over the functions listed below:
- `manage_FeeExempt`: manage the state variable `isFeeExempt`
- `manage_TxLimitExempt`: manage the state variable `isTxLimitExempt`
- `manage_WalletLimitExempt`: manage the state variable `isWalletLimitExempt`
- `setMultipliers`: manage the state variables `sellMultiplier`, `buyMultiplier` and `transferMultiplier`
- `multiTransfer`: transfer the AtEM tokens to some addresses

Any compromise to the `authorizations` account may allow the hacker to take advantage of this authority, change the configuration of this contract, and transfer tokens in the contract.

This protocol has a special model, namely the launch model, the launch model could not be reset after the `launchMode` is set `false`.
During the launch model, the authorized account could transfer tokens from arbitrary users to specified users by invoking the `multiTransfer` function.
Out of the launch model, the authorized account could transfer tokens from users who in the blacklist by invoking the `multiTransfer` function. 
We understand this design of the protocol, but it is a centralization risk for the authorized account.


In the contract `Auth` the role `owner` has authority over the functions listed below:
- `authorize`: manage the state variable `authorizations`
- `unauthorize`: manage the state variable `authorizations`
- `transferOwnership`: manage the state variable `potentialOwner`

Any compromise to the `owner` account may allow the hacker to take advantage of this authority.


Centralization Risks in AtEM.sol

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

Initial Token Distribution

The `swapBack` function calls the `router.addLiquidityETH` function with the `to` address specified as `autoLiquidityReceiver` for acquiring the generated LP tokens from the `AtEM-BNB` pool. As a result, over time the `autoLiquidityReceiver` address will accumulate a significant portion of LP tokens. If the `autoLiquidityReceiver` is an EOA (Externally Owned Account), mishandling of its private key can have devastating consequences for the project as a whole. 
```solidity=406
            router.addLiquidityETH{value: amountBNBLiquidity}(
                address(this),
                amountToLiquify,
                0,
                0,
                autoLiquidityReceiver,
                block.timestamp
            );
```

Centralized Risk In `swapBack`

In the `swapBack` function, the contract transfers the `BNB` to the related Fee Receiver. As a result, over time these accounts will accumulate a significant portion of `BNB`. If these accounts are EOA (Externally Owned Account), mishandling their private key can have unpredictable consequences for the project as a whole.
```solidity=400
        payable(marketingFeeReceiver).transfer(amountBNBMarketing);
        payable(teamFeeReceiver).transfer(amountBNBteam);
        payable(devFeeReceiver).transfer(amountBNBDev);
        payable(gamingFeeReceiver).transfer(amountBNBGaming);
```

Centralization Risk in Fee Receiver

The state variable `totalFee` is composed of six fees:
```solidity
uint256 public totalFee = marketingFee + liquidityFee + teamFee + devFee + utilityFee + gamingFee;
```
So the `totalETHFee` is composed of six fees per of the below statement:
```solidity
uint256 totalETHFee = totalFee.sub(liquidityFee.div(2));
```
When distributing the fee, the `utilityFee` part is not distributed to the `utilityFeeReceiver` account. All BNBs from the `router` only distributed to `marketingFeeReceiver`, `teamFeeReceiver`, `devFeeReceiver`, `gamingFeeReceiver` and `address(this)`. 
```solidity
        payable(marketingFeeReceiver).transfer(amountBNBMarketing);
        payable(teamFeeReceiver).transfer(amountBNBteam);
        payable(devFeeReceiver).transfer(amountBNBDev);
        payable(gamingFeeReceiver).transfer(amountBNBGaming);
```

In the function `takeFee`, We find that the `utilityFeeReceiver` address has already received the `AtEM` tokens from the transfer fee.
```solidity=321
        uint256 utilityTokens = feeAmount.mul(utilityFee).div(totalFee);
        uint256 contractTokens = feeAmount.sub(utilityTokens);

        if(contractTokens > 0){
            balanceOf[address(this)] = balanceOf[address(this)].add(contractTokens);
            emit Transfer(sender, address(this), contractTokens);
        }
        
        if(utilityTokens > 0){
            balanceOf[utilityFeeReceiver] = balanceOf[utilityFeeReceiver].add(utilityTokens);
            emit Transfer(sender, utilityFeeReceiver, utilityTokens);    
        }
```

Are all of the above the intended design?


Discussion for  Calculation of Fee Amount

The contract is serving as the underlying entity to interact with third-party PancakeSwap protocols for adding liquidity to the AtEM-BNB pool and swapping tokens. The scope of the audit treats 3rd party entities as black boxes and assume their functional correctness. However, in the real world, 3rd parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of 3rd parties can possibly create severe impacts, such as increasing fees of 3rd parties, migrating to new LP pools, etc.

Third Party Dependencies

The function `clearStuckToken` could clear all tokens in this contract, however, to prevent the owner from mistakenly transferring the `AtEM` token, which is used to add liquidity and distribute fees, the function `clearStuckToken` should revert if the `tokenAddress` is `AtEM`.

Lack of Token Check

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

Missing Emit Events

`public` functions that are never called by the contract could be declared as `external`. `external` functions are more efficient than `public` functions.

Improper Usage of `public` and `external` Type

The return values of function  `addLiquidityETH` are not properly handled.

```solidity=406
            router.addLiquidityETH{value: amountBNBLiquidity}(
                address(this),
                amountToLiquify,
                0,
                0,
                autoLiquidityReceiver,
                block.timestamp
            );
```

Return value not handled

AtEM

AtEM.sol

AtEM

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

10

0

4

2

4