ShibaRocket
Search…
Findings
Issue 01
Type
Severity
Location
Best Practice
Low
addLiquidtyDescription
addLiquidity calls the external function addLiquidityETH . Since this function can be called during _transfer, it may cause _transfer to fail unnecessarily. 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
_transferIssue 02
Type
Severity
Location
Best Practice
Low
swapTokensForEthDescription
swapTokensForEth calls external function swapExactTokensForETHSupportingFeeOnTransferTokens , and is called during _transfer, which can cause the same issues as specified in issue 01.Recommendation
Same as Issue 01.
Issue 03
Type
Severity
Location
Gas Optimization
Informational
_approveDescription
approve is being called every transaction on the same tokens and for the same spender (the router).
Recommendation
In order to reduce gas cost,
approve could be called once (with max int), and then check if it is needed again using allowanceIssue 04
Type
Severity
Location
Owner Privileges
Medium
addLiquidityDescription
The recipient of the newly created LP tokens is the owner of the contract. The newly created LP tokens are unlocked.
1
pancakeRouter.addLiquidityETH{value: ethAmount}(
2
address(this),
3
tokenAmount,
4
0, // slippage is unavoidable
5
0, // slippage is unavoidable
6
owner(),
7
block.timestamp
8
);
Copied!
Recommendation
Our recommendation is to change the recipient of the newly created LP tokens to the contract in order to ensure that the LP tokens are locked or to simply lock the tokens in the contract for a certain time frame.
Issue 06
Type
Severity
Location
Volatile Code
Medium
_getCurrentSupplyDescription
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
One possible solution is to limit the number of excluded addresses. We encourage the owner of the project and the community to frequently monitor the number of excluded addresses. The issue described could be recovered by calling
includeInReward which removes an element from the _excluded array. Issue 07
Type
Severity
Location
Logical Issue
Medium
includeInRewardDescription:
The code is vulnerable to the SafeMoon bug - 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.Recommendation:
Properly calculate _rOwned of the included address in
includeInReward based on its _tOwned amountIssue 08
Type
Severity
Location
Logical Issue
Informational
includeInRewardDescription
The error message in the require doesn’t describe the error correctly.
require(_isExcluded[account], "Account is already excluded");
Issue 09
Type
Severity
Location
Gas Optimization
Informational
Contract
Description:
exist array can grow indefinitely proportionally to the number of all-time holders. Recommendation
The array is unused. Consider removing it to save on gas.
Issue 10
Type
Severity
Location
Gas Optimization
Informational
Contract
Description:
minTokensBeforeSwap is set to a very small value which will likely always be less than the contract's token balance. Therefore, swapAndLiquify will take place in almost every sell, there is a chance that users will pay the gas cost for a small swap transaction. On BSC the gas fees are reasonable, but this may be a critical issue if considering deploying the contract to ETH.Issue 11
Type
Severity
Location
Gas Optimization
Informational
Contract
Description:
myRewards variable is unusedRecommendation
Consider removing unused variables before deployment to save on gas and storage.
Issue 12
Type
Severity
Location
Volatile Code
Medium
swapAndLiquifyDescription
SwapAndLiquify takes place only on sell transactions. There is a chance that the contract will accrue a significant amount of tokens. The consequence is a pretty significant price drop because of the large number of tokens that would enter the pool. The team should be aware of this issue.Recommendation
Consider limiting the price impact as a result of
swapAndLiquify. We recommend limiting it based on a percentage of the pair balance.Issue 13
1
receive() external payable {}
Copied!
Description
There is a receive function in the contract, which means any address can send BNB to the contract. The problem is that there is no way to recover BNB that were mistakenly sent to the contract.
Recommendation
In order to prevent the contract from receiving BNB from investors, which will result in a loss of funds, our recommendation is to only accept ETH from “whitelisted” addresses (for example the router address should be whitelisted).
The receive function will revert if the address is not whitelisted.
Last modified 3mo ago