
Work done
- Crowdsale Smart Contract Audit
Smart Contract Audit Report
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 functionsmint(address _to, uint256 _amount)
andmintWithTimeLock(address _to, uint256 _amount, uint256 _releaseTime)
. This means that the token can be transferred to the zero address0x00
by calling the function with the argumentsmint('0x00','tokenAmount')
. The same is the case for the functionmintWithTimeLock
. - 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 functionmintWithTimeLock(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
- 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.
- 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.
- 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
- No critical issues have been found in the code. Medium and low severity issues have been identified and respective corrections have been proposed.
- In general, it is highly recommended to comply with community best practice of ERC20 token issuance and to use sanity checks on function arguments.
- If saving gas is a high priority and therefore the checks of
address _to
anduint256
_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.
About Client
Naga Coin is a Fintech company based in London, aimed at revolutionizing the world through decentralizing financial technology and providing access to the best market tools for everyone across the globe.