Findings
Issue 01
Description
Proxy contracts are very vulnerable and may easily cause high severity logical and security issues by misusing them.
Recommendation
Make sure you are familiar with the potential risks of using proxy contracts and have handled them properly.
Issue 02
Description
The contract is upgradeable which means the owner is able to change critical logic and behavior after the contract is deployed.
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 swapExactTokensForETHSupportingFeeOnTransferTokens and addLiquidityETH. Both of which may cause _transfer to fail unnecessarily.
Recommendation
_transfer should always work, and shouldn't fail if swapExactTokensForETHSupportingFeeOnTransferTokens or any other router-related functions fail, in order to make sure the token will always be tradable.
Use try-catch when calling external functions in critical path flows.
Although it's a best practice to handle errors in a graceful manner, the likelihood of these functions failing constantly is low.
Issue 05
Description
The code does not emit events when transferring fees. This can cause blockchain explorers and DApps to inaccurately parse transfers and transactions.
Recommendation
Add Transfer event when taking fees.
Issue 06
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 the set functions.
Furthermore, consider emitting events when changing the state of the contract, such as setting fees.
Issue 07
Description
The owner can pause the token and all transfer/allowance functions at any time.
Recommendation
Remove this function if not needed.
Last updated