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