Sign Up for a Code Audit Today and Get 3 Months of Skynet for Free

In the contract `MetaDogeSwapv2` 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/192d3463dad84231b0ab8b8b50b4c320/diagrams/centralization-MetaDogeSwapv2-_owner.svg)

In the contract `Ownable` 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/192d3463dad84231b0ab8b8b50b4c320/diagrams/centralization-Ownable-_owner.svg)

In the contract `Ownable` the role `_previousOwner` has authority over the functions shown in the diagram below.

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

![](https://accelerator-tasks-prod.s3.amazonaws.com/192d3463dad84231b0ab8b8b50b4c320/diagrams/centralization-Ownable-_previousOwner.svg)

In the contract `MetaDogeSwap` the role `_owner` has authority over the following functions:

- function `withdraw`: to withdraw an amount of BNBs from the contract.
- function `withdrawall`: to withdraw all of the BNBs from the contract.

Centralization Related Risks

The state variables `_taxFee`, `_liquidityFee`,  `_percentageOfLiquidityForMarketing` and `_maxTxAmount` can be changed and have no limitations. So they can be set to an arbitrary number.

More seriously, setting `_percentageOfLiquidityForMarketing` to `100` can transfer almost all BNBs in the current contract to the `_marketingWallet`.

Key Metrics can be Changed without Limitations

A reentrancy attack can occur when the contract creates a function that makes an external call to another untrusted contract before resolving any effects. If the attacker can control the untrusted contract, they can make a recursive call back to the original function, repeating interactions that would have otherwise not run after the external call resolved the effects. 

Function `_transfer()` is risky to reentrancy attack. The function call of `swapAndLiquify()` would eventually send `ethAmount` via `_uniswapV2Router.addLiquidityETH()`, and state variable `_rOwned` is massively changed later in the function call of `_tokenTransfer()`. Since the real implementation of the external function is unclear, and the address behind the interface is not clear, reentrancy is possible to take place.

Potential Reentrancy Attack

The function `setTokenOwner` and  `onPreTransferCheck` are unknown implementations. The scope of the audit treats 3rd party entities as black boxes and assumes their functional correctness. However, in the real world, 3rd parties can be compromised and this may lead to lost or stolen assets. The codes related to these unknown implementations are not in the scope of this audit.

Unknown implementations

An owner is possible to gain ownership of the contract even if he calls function `renounceOwnership` to renounce the ownership. This can be achieved by performing the following operations:
1. Call `lock` to lock the contract. The variable `_previousOwner` is set to the current owner.
2. Call `unlock` to unlock the contract.
3. Call `renounceOwnership` to leave the contract without an owner. 
4. Call `unlock` to regain ownership.

Possible to gain ownership after renouncing the contract ownership

A sandwich attack might 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 (before the transaction being attacked) a transaction to purchase one of the assets and make profits by back running (after the transaction being attacked) a transaction to sell the asset.

Potential sandwich attacks could happen if calling `_uniswapV2Router.swapExactTokensForETHSupportingFeeOnTransferTokens` and `_uniswapV2Router.addLiquidityETH` without setting restrictions on slippage.

For example, when we want to make a transaction of swapping 100 AToken for 1 ETH, an attacker could raise the price of ETH by adding AToken into the pool before the transaction so we might only get 0.1 ETH. After the transaction, the attacker would be able to withdraw more than he deposited because the total value of the pool increases by 0.9 ETH.

Potential Sandwich Attacks

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

3rd party dependencies

According to the following code:
```solidity
    function swapAndLiquify(uint256 contractTokenBalance) private lockTheSwap {
        ...
        uint256 half      = contractTokenBalance.div(2);
        uint256 otherHalf = contractTokenBalance.sub(half);
...
        swapTokensForBnb(half);
...
        uint256 newBalance = address(this).balance.sub(initialBalance);
...
        uint256 marketingFee    = newBalance.mul(_percentageOfLiquidityForMarketing).div(100);
        uint256 bnbForLiquidity = newBalance.sub(marketingFee);
        if (marketingFee > 0) {
            payable(_marketingWallet).transfer(marketingFee);
            emit MarketingFeeSent(_marketingWallet, marketingFee);
        }
...
        addLiquidity(otherHalf, bnbForLiquidity);
...
}
```
, half of the MDSV2 tokens in the contract would be converted to BNBs and some of them would be then transferred to the `_marketingWallet`, the left BNBs would be added with the other half of the MDSV2 tokens to the MDSV2-BNB pool. However, the MDSV2 tokens are more than needed, hence some of the MDSV2 tokens would be left in the contract. As a result, the requirement `contractTokenBalance >= _minTokenBalance` becomes easier to be met when `_transfer()`, users are more possibly to spend more gas during the transaction, and the lp tokens are not added as many as expected.

Inappropriate BNB Converting Proportion 

The address should be checked before the assignment to make sure it is not zero addresses. 

Missing zero address validation

Solidity version >=0.8.0 includes checked arithmetic operations and underflow/overflow by default, making SafeMath redundant. 

Redundant SafeMath Usage

In the following code snippet, `tokensIntoLiqudity` should be `tokensIntoLiquidity`.
```solidity=
    event SwapAndLiquify(
        uint256 tokensSwapped,
        uint256 bnbReceived,
        uint256 tokensIntoLiqudity
    );
```

Typos in the contract

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

Redundant code

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

```solidity=
        _uniswapV2Router.addLiquidityETH{value: bnbAmount}(
            address(this),
            tokenAmount,
            0, // slippage is unavoidable
            0, // slippage is unavoidable
            address(this),
            block.timestamp
        );
```

MetaDogeSwap

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

7

1

5