PandAI Token Contract Security Audit Report

BSC_PandaAI_token_contract_audit_report.md

PandAI Token Contract Security Audit Report

1. Summary

PandAI Token smart contract security audit report performed by chhajershrenik

2. In scope

PandAIToken

3. Findings

No security issues were found in the provided contract.

In total, 5 notes were reported, including:

• 4 notes.

• 1 owner privilege.

3.1 Owner Privileges

Severity: owner privilege

Description

Currently, the total supply of the tokens is minted to the owner of the contract, and the distribution of tokens is controlled by the owner.

    constructor() ERC20("PandAI Token", "PANDAI") {
        _mint(msg.sender, 100000000000000 * 10 ** decimals());
    }

Consider transferring the tokens initially to a multi-sig account, so that the tokens are protected by multiple members during the distribution and vesting period.

3.2 Follow good coding practice

Severity: Note

Description

1. Missing docstrings

   The PandAIToken contract in the code base lack documentation. 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 documented as well. When writing docstrings, consider following the Ethereum Natural Specification Format (NatSpec).

2. Unlocked Pragma

   Contracts should be deployed using the same compiler version/flags with which they have been tested. Locking the floating pragma, i.e. by not using ^ in pragma solidity ^0.8.9, ensures that contracts do not accidentally get deployed using an older compiler version with unfixed bugs.

3. Missing test suite

   The contract is missing a test suite to validate and verify the behavior of the contract functionalities. Add tests are recommended to ensure that the contract functions and behaves as expected.

4. PandAI Token has 6 decimals

   Tokens with 18 decimals are the current norm, For instance, USDC has 6 decimals, cTokens from Compound and WBTC have 8. Your internal calculations may be inaccurate if you are handling PandAI tokens without considering these cases.

4. Security practices

• Open-source contact.
• The contract should pass a bug bounty after the completion of the security audit.
• Public testing.
• Automated anomaly detection systems. - NOT IMPLEMENTED. A simple anomaly detection algorithm is recommended to be implemented to detect behavior that is atypical compared to normal for this contract. For instance, the contract must halt deposits in case a large amount is withdrawn in a short period until the owner or the community of the contract approves further operations.
• Multisig owner account.
• Standard ERC20-related issues. - NOT IMPLEMENTED. 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.
• Crosschain address collisions. ETH, ETC, CLO, etc. It is possible that a transaction can be sent to the address of your contract at another chain (as a result of a user mistake or some software fault). It is recommended that you deploy a "mock contract" that would allow you to withdraw any tokens from that address or prevent any funds deposits. Note that you can reject transactions of native tokens deposited, but you can not reject the deposits of ERC20 tokens. You can use this source code as a mock contract: extractor contract source code. The address of a new contract deployed using CREATE (0xf0) opcode is assigned following this scheme keccak256(rlp([sender, nonce])). Therefore you need to use the same address that was originally used at the main chain to deploy the mock contract at a transaction with the nonce that matches that on the original chain. Example: If you have deployed your main contract with address 0x010101 at your 2021th transaction then you need to increase your nonce of 0x010101 address to 2020 at the chain where your mock contract will be deployed. Then you can deploy your mock contract with your 2021th transaction, and it will receive the same address as your mainnet contract.