Skip to content

Instantly share code, notes, and snippets.

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 yuriy77k/76d020a1607a9483b7dba267eb36b36d to your computer and use it in GitHub Desktop.
Save yuriy77k/76d020a1607a9483b7dba267eb36b36d to your computer and use it in GitHub Desktop.

Pundi X (NPXS) Token audit report.

1. Summary

This document is a security audit report performed by danbogd, where Pundi X (NPXS) Token has been reviewed.

2. In scope

Сommit hash .

3. Findings

In total, 6 issues were reported including:

  • 1 medium severity issues
  • 2 low severity issues
  • 2 owner privileges (ability of owner to manipulate contract, may be risky for investors)..
  • 1 notes.

No critical security issues were found.

3.1. Allowance Approval

Severity: medium

Description

Following ERC-20 final description:

"NOTE: To prevent attack vectors like the one described here and discussed here, clients SHOULD make sure to create user interfaces in such a way that they set the allowance first to 0 before setting it to another value for the same spender. THOUGH The contract itself shouldn't enforce it, to allow backwards compatibility with contracts deployed before.

Do not throw in case if the following condition is true require((value == 0) || (_allowances[msg.sender][spender] == 0)) and return false, users might not notice that the changes didn't occur, and external contract calls to this function will highlight many other issues.

Code snippet

function approve(address _spender, uint256 _value) returns (bool) {

    require((_value == 0) || (allowed[msg.sender][_spender] == 0));

    allowed[msg.sender][_spender] = _value;
    Approval(msg.sender, _spender, _value);
    return true;
  }

3.2. 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 losses for lots of token users! More details here.

Recommendation

Add into a function transfer(address _to, ... ) following code:

require( _to != address(this) );

3.3. No checking for zero address

Severity: low

Description

In this function there in no checking for zero address.

Code snippet

function deposit(address investor) onlyOwner payable {
    deposited[investor] = deposited[investor].add(msg.value);
  }

3.4. Owner Privileges

Severity: owner previliges

Description

Contract owner allow himself to:

  • Unlimited token minting and creation of new tokens after the crowd sale ended.
  • Pause/unpause transfer, transferFrom, Approve, increaseApproval, decreaseApproval functions.

Code snippet

function mint(address _to, uint256 _amount) onlyOwner canMint returns (bool) {
    balances[_to] = balances[_to].add(_amount);
    Mint(_to, _amount);
    Transfer(0x0, _to, _amount);
    return true;
  }


 modifier whenPaused() {
    require(paused);
    _;
  }

3.5. Consider using latest version of solidity.

Severity: minor observation

Description

The contracts use solidity version 0.4.11. It is suggested to use the latest version and fix all compiler warnings that arise. Compiler version should be fixed to avoid any potential discrepancies in smart contract behavior caused by different versions of compiler.

4. Conclusion

The review did not show any critical issues, some of medium and low severity issues were found.

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