Findings

Issue 01

Description

addLiquidity calls the external function addLiquidityETH . Since this function can be called during _transfer, it may cause _transfer to fail unnecessarily.

Recommendation

Use try-catch when calling external functions in critical path flows. Our recommendation is to Always make sure error cases are handled gracefully in critical functions such as _transfer

Issue 02

Description

swapTokensForEth calls external function swapExactTokensForETHSupportingFeeOnTransferTokens , and is called during _transfer, which can cause the same issues as specified in issue 01.

Recommendation

Same as Issue 01.

Issue 03

Description

approve is being called every transaction on the same tokens and for the same spender (the router).

Recommendation

In order to reduce gas cost, approve could be called once (with max int), and then check if it is needed again using allowance

Issue 04

Description

The recipient of the newly created LP tokens is the owner of the contract. The newly created LP tokens are unlocked.

  pancakeRouter.addLiquidityETH{value: ethAmount}(
        address(this),
        tokenAmount,
        0, // slippage is unavoidable
        0, // slippage is unavoidable
        owner(),
        block.timestamp
    );

Recommendation

Our recommendation is to change the recipient of the newly created LP tokens to the contract in order to ensure that the LP tokens are locked or to simply lock the tokens in the contract for a certain time frame.

Issue 06

Description

The _excluded array can grow indefinitely. _transfer calls getCurrentSupply function which iterates over _excluded array. Iterating over an unbounded array can exceed the block gas limit which will make the token untradable.

Recommendation

One possible solution is to limit the number of excluded addresses. We encourage the owner of the project and the community to frequently monitor the number of excluded addresses. The issue described could be recovered by calling includeInReward which removes an element from the _excluded array.

Issue 07

Description: The code is vulnerable to the SafeMoon bug - excluding an address from the fee and then later including it back will cause the address to receive all RFI rewards for the time it was excluded (at the expense of other holders).

In includeInReward _rOwned is not updated. _rOwned should be updated and be calculated according to the current rate.

Recommendation: Properly calculate _rOwned of the included address in includeInReward based on its _tOwned amount

Issue 08

Description

The error message in the require doesn’t describe the error correctly.require(_isExcluded[account], "Account is already excluded");

Issue 09

Description: exist array can grow indefinitely proportionally to the number of all-time holders.

Recommendation

The array is unused. Consider removing it to save on gas.

Issue 10

Description: minTokensBeforeSwap is set to a very small value which will likely always be less than the contract's token balance. Therefore, swapAndLiquify will take place in almost every sell, there is a chance that users will pay the gas cost for a small swap transaction. On BSC the gas fees are reasonable, but this may be a critical issue if considering deploying the contract to ETH.

Issue 11

Description: myRewards variable is unused

Recommendation

Consider removing unused variables before deployment to save on gas and storage.

Issue 12

Description SwapAndLiquify takes place only on sell transactions. There is a chance that the contract will accrue a significant amount of tokens. The consequence is a pretty significant price drop because of the large number of tokens that would enter the pool. The team should be aware of this issue.

Recommendation

Consider limiting the price impact as a result of swapAndLiquify. We recommend limiting it based on a percentage of the pair balance.

Issue 13 

receive() external payable {}

Description

There is a receive function in the contract, which means any address can send BNB to the contract. The problem is that there is no way to recover BNB that were mistakenly sent to the contract.

Recommendation

In order to prevent the contract from receiving BNB from investors, which will result in a loss of funds, our recommendation is to only accept ETH from “whitelisted” addresses (for example the router address should be whitelisted). The receive function will revert if the address is not whitelisted.

PreviousDisclaimer

Last updated