Read the findings of the 2022 Web3 Security Report

Assigning the contract `address(this)` to the `antiSnipe` will incur an error when invoking functions of the interface `AntiSnipe` on the contract `address(this)` since `address(this)` does not implement the interface `AntiSnipe`.

```solidity=601
    function _checkLiquidityAdd(address from, address to) private {
        ...
              if(address(antiSnipe) == address(0)){
                antiSnipe = AntiSnipe(address(this));
              }
        ...
    }
```

The current contract does not implement the `AntiSnipe` interface.

```solidity=391
    function setLpPair(address pair, bool enabled) external onlyOwner {
        if (enabled == false) {
            lpPairs[pair] = false;
            antiSnipe.setLpPair(pair, false);
        } else {
            if (timeSinceLastPair != 0) {
                require(block.timestamp - timeSinceLastPair > 3 days, "3 Day cooldown.!");
            }
            lpPairs[pair] = true;
            timeSinceLastPair = block.timestamp;
            antiSnipe.setLpPair(pair, true);
        }
    }
```
When the owner calls the function `setLpPair`, the `antiSnipe.setLpPair(pair, false)` statement will generate an error if the passed-in `enabled` is false, because the current contract does not have a `setLpPair` function.

Wrong Contract Assigned to `antiSnipe`

In the contract `MuscleX` the role `_owner` has authority over the functions shown in the diagram below.

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

![](https://accelerator-tasks-prod.s3.amazonaws.com/04674d8c14d04e4ca6cdc0bb9c1da50d/diagrams/centralization-MuscleX-_owner.svg)

Centralization Risk in MuscleX.sol

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

Initial Token Distribution

Over time, the code snippet below will lead that these accounts in `_taxWallets` will accumulate a significant amount of eth.
```solidity=
_taxWallets.buyback.transfer(buybackBalance);
_taxWallets.lottery.transfer(stakingBalance);
_taxWallets.marketing.transfer(marketingBalance);
```


Centralization risk in `taxWallets` 

The implementation of the `AntiSnipe` interface is unknown. The contract is also serving as the underlying entity to interact with third-party protocols. The scope of the audit would treat those 3rd party entities as black boxes and assume their functional correctness. However, in the real world, 3rd parties may be compromised that led to assets being lost or stolen.

3rd party dependencies

The function `transferFrom` does not check whether the value of `_allowances` is greater than or equal to `amount` unless the Solidity version 0.8.0 or above is used.

`_allowances` Not Checked in `transferFrom()`

The target version of the contract `MuscleX` solidity compiler varies too much. From version `0.8.0`, the solidity language has built-in methods related to SafeMath. But for the versions less than `0.8.0`, SafeMath or a similar library should be used to prevent the unexcepted calculation.

Potential risk in calculation

Not check the balance of `from` greater than or equal to `amount` before transfer tokens unless the Solidity version 0.8.0 or above is used.

Check Balance Before Transfer

In the constructor, when the variable `lpPair` is assigned a new value, the variable `lpPairs` is updated synchronously. But in the function `setNewRouter`, `lpPairs` is not updated when `lpPair` is changed.

Inconsistent Logic When Updating Router

The contract has unlocked compiler version. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to different compiler versions. This can lead to an ambiguity when debugging as compiler specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.

The global variable `block.chainid` is available since `0.8.0`. [Block and Transaction Properties](https://docs.soliditylang.org/en/v0.8.0/units-and-global-variables.html#block-and-transaction-properties)

Unlocked Compiler Version

The **require** can be used to check for conditions and throw an exception if the condition is not met. It is better to provide a string message containing details about the error that will be passed back to the caller.
The **revert** lacks the message also.

Missing Error Messages

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

```solidity=
        dexRouter.addLiquidityETH{value: liquidityBalance}(
                address(this),
                toLiquify,
                0,
                0,
                DEAD,
                block.timestamp
            );
```

Return value not handled

The variable `blacklistedBlocks` is never used in this contract.

MuscleX

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

13

0

12

1

0