FINDINGS

Detailed Summary of Findings

Static Analysis

No major issues were found. Some false positive errors were reported by the tool. All the other issues have been categorized above according to their level of severity.

Manual Review

Critical Severity Issues

C-01. Contract is not compliant with EIP-20 and hence completely unusable for any ERC20 use case

The token implemented is not compliant with the eip standard and miss the important functions that are necessary for the working of the token. All the tokens must comply with some standard eip, in this case EIP 20, which states that it must have following functions and events :

Failing to comply with the eip20 will have the following impacts: Token cannot be listed on any major CEX or DEX as they all expect existence of those functions and require the allowance specifically. Not detectable by any wallet as no standard being followed. Cannot be used for DAO purposes. Cannot be used for any use case as not detectable by wallets, so it is essentially useless.

Instances:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract NFTube {
    string public name = "NFTube";
    string public symbol = "NFTT";
    uint8 public decimals = 18;
    uint256 public totalSupply = 100000000 * 10**uint256(decimals); // Total Supply: 100,000,000 NFTT (100 million)

    mapping(address => uint256) public balanceOf;

    event Transfer(address indexed from, address indexed to, uint256 value);

    constructor() {
        balanceOf[msg.sender] = totalSupply;
    }

    function transfer(address to, uint256 value) external returns (bool) {
        require(balanceOf[msg.sender] >= value, "Insufficient balance");

        balanceOf[msg.sender] -= value;
        balanceOf[to] += value;

        emit Transfer(msg.sender, to, value);
        return true;
    }
}

Recommended Mitigation Steps:

Use the openzeppelin ERC20 contracts by inheriting for them, they have all the necessary functions and are security tested.

Low Severity Issues

L-01. Missing Natspec

Solidity contracts can use a special form of comments to provide rich documentation for functions, return variables and more. This special form is named the Ethereum Natural Language Specification Format (NatSpec). There are no natspec functions in the whole contract for the functions, consider adding them to better explain the functions and make them more readable and audit-able.

Instances:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract NFTube {
    string public name = "NFTube";
    string public symbol = "NFTT";
    uint8 public decimals = 18;
    uint256 public totalSupply = 100000000 * 10**uint256(decimals); // Total Supply: 100,000,000 NFTT (100 million)

    mapping(address => uint256) public balanceOf;

    event Transfer(address indexed from, address indexed to, uint256 value);

    constructor() {
        balanceOf[msg.sender] = totalSupply;
    }

    function transfer(address to, uint256 value) external returns (bool) {
        require(balanceOf[msg.sender] >= value, "Insufficient balance");

        balanceOf[msg.sender] -= value;
        balanceOf[to] += value;

        emit Transfer(msg.sender, to, value);
        return true;
    }
}

Recommended Mitigation Steps:

Add the natspec comments in proper format on each function and constructor.

L-02. New Solidity versions support named mappings, use that for more readibility of code

Newer versions of solidity like 0.8.20 allow the named mappings that make the code more readable. Mapping are generally hard to read, specifically the nested ones. Adding names for them make them more readable and audit-able.

Instances:

mapping(address => uint256) public balanceOf;

as

mapping(address user => uint256 balance) public balanceOf;

Recommended Mitigation Steps:

Use named mapping instead of unnamed mapping for more readability and auditibility of the codebase.

L-03. Avoid Using Floating Pragma

Contracts should be deployed with the same compiler version and flags used during development and testing. Locking the pragma helps to ensure that contracts do not accidentally get deployed using another pragma. An outdated pragma version might introduce bugs that affect the contract system negatively or recently released pragma versions may have unknown security vulnerabilities.

Instances:

pragma solidity ^0.8.0;

Recommended Mitigation Steps:

Consider locking the pragma.

Gas Otimization Issues

G-01. Constructors can be marked payable

You can cut out 10 opcodes in the creation-time EVM bytecode if you declare a constructor. Consider making the constructor payable to save gas.

Instances:

constructor() {
        balanceOf[msg.sender] = totalSupply;
    }

Recommended Mitigation Steps: Make the constructor payable