Smart contract security audit report performed by Callisto Security Audit Department
https://bscscan.com/token/0x550d7984b7adfff88815e5528e12e322df6d3b9b#code
-
It is possible to double withdrawal attack. More details here.
-
Lack of transaction handling mechanism issue. WARNING! This is a very common issue, and it already caused millions of dollars in losses for lots of token users! More details here.
Add the following code to the transfer(_to address, ...) function:
require( _to != address(this) );
Description:
SafeERC20 is a wrapper library around ERC20 calls that make safe the interaction with someone else’s ERC20 token, in your contracts. What makes SafeERC20 better than then normal ERC20 is that the former can ensure the safety of normal ERC20 function calls by checking the boolean return values of ERC20 operations and revert the transaction if they fail, at the same time allowing you to support some non-standard ERC20 tokens they don’t have boolean return values.
Also Panda token has 6 decimals , most of the other ERC20 tokens are either 18 decimal or else and interaction with these can be problematic therefore , use SafeERC20. Recommendation:
Use SafeERC20 library instead of standard ERC20
In conditions like burning tokens mistakenly or sending tokens mistakenly , there should be an emergency mint function to mint back the tokens lost , make sure that function is protected with something like onlyOwner.
The value here _mint(msg.sender, 100000000000000 * 10 ** decimals()); should be depicted in scientific
notation instead , i.e 1e14 to increase readability.
It is a good coding practice to store values like amountToMint , InitialMint inside a variable.
Declare a variable like this uint initialMint = 1e14; and use that in the constructor.
Each event should use three indexed fields if there are three or more fields.
Make the field value indexed in event Transfer and event Approval in the interface IERC20
Many functions in the code base lack documentation. This hinders reviewers’ understanding of the code’s intention, which is fundamental to correctly assess not only security, but also correctness. Additionally, docstrings improve readability and ease maintenance. They should explicitly explain the purpose or intention of the functions, the scenarios under which they can fail, the roles allowed to call them, the values returned and the events emitted.
Consider thoroughly documenting all functions (and their parameters) that are part of the contracts’ public API. Functions implementing sensitive functionality, even if not public, should be clearly documented as well. When writing docstrings, consider following the Ethereum Natural Specification Format (NatSpec).
Contracts should be deployed with the same compiler version and flags that they have been tested the most with. Locking the pragma helps ensure that contracts do not accidentally get deployed using, for example, the latest compiler which may have higher risks of undiscovered bugs. Contracts may also be deployed by others and the pragma indicates the compiler version intended by the original authors.
The contract is missing a test suite to validate and verify the behavior of the contract functionalities, it is recommended to add tests to ensure that the contract functions and behaves as expected(Make sure the tests have 100% coverage).
It is known that every contract can potentially receive an unintended ERC20-token deposit without the ability to reject it even if the contract is not intended to receive or hold tokens. As a result, it is recommended to implement a function that will allow extracting any arbitrary number of tokens from the contract.
Tokens may be lost if the user calls the transfer mistakenly (Ex - sending tokens to a contract instead of an EOA). ERC223 solves this problem , users can accept/reject tokens arriving at their smart contracts , there is a check if the target is a smart contract , if it is then assumes that the contract has implemented a “tokenFallback”.
It is recommended to adhere to the security practices described