Naga Coin Crowdsale Contract Audit

The NAGA distribution smart contract code NAGACoin.sol (“The smart contract”) has been audited. OpenZeppelin libraries are not considered in the audit.

Below our assessment and recommendations, in order of importance.

Critical Severity

• No issues of critical severity. The contract can be deployed for the intended.

High Severity Issues

• No High Severity Issues.

Medium Severity Issues

Check that destination of token transfers is not 0X0

• Sanity check on parameter address _to is missing in both the functions mint(address _to, uint256 _amount) and mintWithTimeLock(address _to, uint256 _amount, uint256 _releaseTime). This means that the token can be transferred to the zero address 0x00 by calling the function with the arguments mint('0x00','tokenAmount'). The same is the case for the function mintWithTimeLock.
• Rate of occurrence: Low (Reason: Minting is only allowed to owner)
• Correction: We advise to use: require(_to != address(0))

Minting can lock tokens to a time in the past

• Sanity check on parameter uint256 _releaseTime is missing in function mintWithTimeLock(address _to, uint256 _amount, uint256 _releaseTime). This means the token can be locked by passing a _releaseTime from the past.
• Rate of occurrence: Low (Reason: Minting is only allowed to owner)
• Correction: We advise to use: require(_releaseTime > now)

Low Severity Issues

Redundant code has been found. For gas optimisation we recommend to remove this code in order to minimize the contract size.

The modifiers onlyOwner and canMint are called twice in the function mint(address _to, uint256 _amount) and called thrice in the function mintWithTimeLock(address _to, uint256 _amount, uint256 _releaseTime) because they are also implemented by the parent function which means they are redundant in NAGACoin.sol

Additional Information and Notes

1. The smart contract is ERC20 compatible, as required by the functional specification. Token minting is managed by the contract owner outside of the smart contract which means the contract is centralized. The contract owner has full control of the token supply and distribution and has the power to create tokens at will. Collected funds are also under the control of the owner and managed outside of The smart contract. These features may be unexpected by some users and participants.
2. All the supply will be created and distributed by the central owner account so it is highly recommended to use a hardware wallet for protecting the owner account or a multisig wallet.
3. Warnings: Formal security audits are not enough to be safe. We recommend implementing an automated contract-based bug bounty and setting a period of time where security researchers from around the globe can try to break the contract’s invariants.

Conclusions and Recommendations

1. No critical issues have been found in the code. Medium and low severity issues have been identified and respective corrections have been proposed.
2. In general, it is highly recommended to comply with community best practice of ERC20 token issuance and to use sanity checks on function arguments.
3. If saving gas is a high priority and therefore the checks of address _to and uint256 _releaseTime were eliminated for this reason, even more gas could be saved by removing other checks such as total supply limit because input values are double checked.