Pundi X Token (NPXS) security audit, conducted by the Callisto Network Security Department in June 2019.
Pundi X (NPXS) Specificities
Audit Request
Audit Top 200 CoinMarketCap tokens.
Pundi X (NPXS).
Deployed at:
https://etherscan.io/address/0xa15c7ebe1f07caf6bff097d8a589fb8ac49ae5b3#contracts
Source Code:
https://etherscan.io/address/0xa15c7ebe1f07caf6bff097d8a589fb8ac49ae5b3#contracts
Disclosure policy:
Platform:
ETH.
Number of lines:
348.
Pundi X (NPXS) Smart Contract Security Audit Report
Are Your Funds Safe?
1. In scope
2. Findings
In total, 9 issues were reported including:
- 5 low severity issues.
- 1 notes.
- 3 owner privileges (the ability of an owner to manipulate contract, may be risky for investors).
No critical security issues were found.
2.1. Known vulnerabilities of ERC-20 token
Severity: low.
Description:
-
It is possible to double withdrawal attack. More details here.
- 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 the following code to the transfer(_to address, ...)
function:
require( _to != address(this) );
2.2. Owner Privileges
Severity: owner privileges.
Description:
- The owner receives funds immediately after the purchase of tokens. It should be available after the end of crowdsale. Otherwise, the owner has the opportunity to buy tokens for the same money. (line 149).
RefundVault
andWithdrawVault
contracts is managed manually by the owner and are not integrated with theCrowdsale
contract which is not good for investors. (lines 200 and 446) - The contract owner allowed to pause transfer functions (
transfer
,transferFrom
). (lines 541-545) - The owner can finish minting whenever he wants. Related with issue #4. (line 401)
2.3. ERC20 Compliance: event missing
Severity: low.
Description:
According to ERC20 standard when burning coins a transfer event should be emitted. In this case the Burn
event is emitted, it is better to additionally use emit Transfer(msg.sender, address(0), value);
Code snippet:
2.4. stopReceive
is not implemented for transferFrom
Severity: low.
Description:
stopReceive
mechanism is used for transfer
function but not implemented for transferFrom
function. It is possibler to approve
funds to yourself and send through transferForm
without any restrictions.
Code snippet:
2.5. ERC223 Compliance, transferAndCall issues
Severity: note.
Description:
- Judging by the call of the
tokenFallback
function, this token should support the ERC223 standard. But in this case it should be called in thetransfer
function also. It should check whether the recipient is a contract. And functiontransfer(address, uint, bytes)
should be implemented. Please, read this - Judging by
transferAndCall
function this token should support the ERC677 standard. But in this case it should callcontractFallback
nottokenFallback
function. And should check whether the recipient is a contract. Please, read this transferAndCall
function does not usewhenNotPaused
modifier and tokens may be transferred even if the contract is paused.
Code snippet:
2.6. Zero address checking
Severity: low.
Description:
There are no zero address checking in functions deposit
at line 212, mint
at line 389, deposit
at line 465.
2.7. Allowance Approval
Severity: low.
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. Conclusion
The audited smart contract can be deployed. Only low severity issues were found during the audit.
4. Revealing audit reports
- https://gist.github.com/yuriy77k/ede3912b0498e812eecd528acbe37137
- https://gist.github.com/yuriy77k/72b57e6c662bf0413e4ad11190db1977
- https://gist.github.com/yuriy77k/76d020a1607a9483b7dba267eb36b36d
Appendix
Smart Contract Audits by Callisto Network.
Miscellaneous
Our Most Popular Audit Reports.
Trust the Blockchain, Audit the Smart Contracts.
Follow Callisto’s Security Department on Twitter to get our latest news and updates!