Skip to content

Instantly share code, notes, and snippets.

@SakshamGuruji3
Created February 16, 2023 08:35
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save SakshamGuruji3/6c668428563d9feaec69b438e401bb59 to your computer and use it in GitHub Desktop.
Save SakshamGuruji3/6c668428563d9feaec69b438e401bb59 to your computer and use it in GitHub Desktop.

Security Audit Report

1. Summary

Smart contract security audit report performed by Callisto Security Audit Department

2. In scope

https://bscscan.com/token/0x550d7984b7adfff88815e5528e12e322df6d3b9b#code

3. Findings

3.1. Known vulnerabilities of ERC-20 token

Severity: low

Description

  1. It is possible to double withdrawal attack. More details here.

  2. 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.

Recommendation

Add the following code to the transfer(_to address, ...) function:

require( _to != address(this) );

MANUAL FINDINGS

1

Severity: low

Use SafeERC20 Lib Instead To Make Interactions With Non-ERC20 Safe

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

2

Severity: low

Introduce The Mint function To Handle Emergency Conditions

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.

NOTES

1 - Use Scientific Notation To Increase Readability

The value here _mint(msg.sender, 100000000000000 * 10 ** decimals()); should be depicted in scientific notation instead , i.e 1e14 to increase readability.

2 - Store The Value To Mint Inside A variable

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.

3 - Event Missing Indexed Fields

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

4 - Missing docstrings

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).

5 - Unspecific compiler version pragma

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.

6 - Missing Test Suite

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).

7 - 7.1 Standard ERC20-related issues

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.

7.2 Token Loss Due To Accidental Transaction

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”.

Conclusion

It is recommended to adhere to the security practices described

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment