Findings
Issue 01
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, 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.
Status
The issue has been resolved.
Issue 02
Description
The owner can set PancakeSwap's router address, which gives him full control over all token swaps.
Recommendation
Consider implementing a timelock mechanism to allow users to review the changes, or remove this feature altogether as backward-incompatible router updates are a very rare event, and this can be implemented with the existing updateStrategy logic.
Status
The issue has been resolved.
Issue 03
Description
The owner can blacklist any address anytime.
Recommendation
Consider time limiting this capability / remove this capability if not needed.
Status
The issue has been resolved.
Issue 04
Description
_transfer may call internally to swapExactTokensForETHSupportingFeeOnTransferTokens and addLiquidityETH , which may cause _transfer to fail unnecessarily.
Recommendation
_transfer should always work, and shouldn't fail if swapExactTokensForETHSupportingFeeOnTransferTokens or addLiquidityETH fail to ensure token will always be tradable.
Wrap these functions inside try-catch.
Status
The issue has been resolved.
Issue 05
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).
Status
The issue has been resolved.
Last updated