Findings
Issue 01
Description
The owner can blacklist any address for 2 days after deploying the contract.
Recommendation
Either remove this function or add a require statement that prohibits the owner from blacklisting the pair address and the contract address. In addition, add a time limit for the setBlacklist function.
Issue 02
Description
The owner can disable trading and make the token untradeable.
Recommendation
Either remove this function or add a require statement that prevents the function from disabling trading once enabled.
Issue 03
Description
approve is being called on every transaction which automatically contributes liquidity to the pool, on the same tokens and for the same spender (the router).
Recommendation
In order to reduce gas costs, approve could be called once (with max int).
Issue 04
Description
_transfer may internally call to external contracts (e.g. the router or vault contracts). Since these functions can be called during _transfer, it may cause the function to unnecessarily fail. In addition, if this function fails constantly it will make the token untradeable.
A malicious owner can cause the transfer to the vault address to consistently fail and make the token untradeable.
In this case, the addLiquidity and swapTokens can fail when calling the router and transfer can fail when calling the vault.
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 05
Description
The calculation of the liquidity fee amount seems to be complex. To make the calculation simpler and easier to read, you can follow these steps:
Swap (amountOfFees * liqFeePercentage / 2) for ETH in order to add liquidity.
The same value will be added as liquidity along with the newly swapped ETH.
The rest of the fees are transferred to the vault.
Issue 06
Description
_liqFeeCollected and _vaultFeeCollected are both in token units while amountBNB is in BNB units. Therefore the calculations on amountBNBLiquidity and amountBNBVault are wrong.
Issue 07
Description
The token will be untradeable should the owner set either of these values to 0.
Recommendation
Consider adding a minimum value to these functions (via a require statement). Furthermore, consider setting the minimum value to a percentage of the pair balance out of the total supply.
Max tx amount need to be greater than 0.1% of the total supply.
Issue 08
Description
There is no upper limit to the setFees functions. If the owner sets them to 100% the token will be untradeable.
Recommendation
Consider adding an upper limit to these functions.
The total amount of fees that can be taken is 25%.
Issue 09
Description
Make sure the fees are always in range and not greater than the percentage factor.
Issue 11
Description
There is a receive function in the contract, which means any address can send BNB to the contract.
Recommendation
In order to prevent the contract from receiving BNB from investors, who can lose their funds, our recommendation is to only accept BNB from “whitelisted” addresses (e.g. the router address). The receive function will revert if the address is not whitelisted.
Last updated