Findings
Issue 01
Gas Optimization
Low
_transfer
Acknowledged
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 02
Volatile Code
Medium
_transfer
Acknowledged
Description
_transfer
may call internally to swapExactTokensForETHSupportingFeeOnTransferTokens
it 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.
Although it's a best practice to handle errors in a graceful manner, the likelihood of these functions failing constantly is low.
⚠️ Please note:
A large number of consecutive buys may result in a significant amount of tokens that will be sold in the next sell transaction which will result in a very high slippage.
Issue 03
Logical Issue
Low
_takeLiquidity
Acknowledged
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 04
Lack of Events
Informational
set functions
Acknowledged
Description
set functions don't emit events.
Recommendation
Consider emitting events when changing the state of the contract.
Issue 05
Owner Capabilites / Volatile Code
Low
_getCurrentSupply
Acknowledged
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
A possible solution is to limit the number of excluded addresses. The issue described could be resolved by calling includeInReward
which removes an element from the _excluded array.
Issue 06
Logical Issue
Low
includeInReward
Acknowledged
Description:
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.
The team acknowledged this issue and they are not planning to exclude and then include an address from rewards.
Recommendation:
Properly calculate _rOwned of the included address in includeInReward
based on its _tOwned amount.
Issue 07
Gas Optimization
Low
_transfer
Acknowledged
Description
swapTokens is called on every sell, even though the value of the amount of tokens may be less than the gas consumption the user will likely pay for the extra swap.
Recommendation
Consider adding a threshold for swapTokens to be called.
Issue 08
Gas Optimization
Low
_transfer
Acknowledged
Description
Two ifs check the same condition.
if(contractTokenBalance > 0) {
if(contractTokenBalance > 0)
swapTokens(contractTokenBalance);
}
Issue 09
Volatile Code / Owner Capabilities
Low
_transfer
Acknowledged
Description
_transfer
may call internally to swapETHToFee
Since this function can be called during _transfer
, it may cause _transfer
to fail unnecessarily. In addition, if this function fails constantly it will make the token unsaleable. A malicious owner can cause the transfer to the marketing address to constantly fail and make the token unsaleable.
Recommendation
Consider transferring the ownership to a timelock contract which will delay the execution of modifying the marketing address or renounce ownership.
General Notes
The owner of the project has completed a kyc procedure with our company. Which reduces the likelihood of a malicious activiy by the owner.
Last updated