Pixie App Smart Contract Security Audit

Contents

Introduction

Coinfabrik has been hired to audit the Pixie token sale smart contracts. We started this PDF report writing a summary of the smart contracts provided by the client and a list of the analysis methods used to audit the contracts. Next, we detailed our findings ordering the issues by severity, followed by all the observations we considered important to add. Furthermore, we ended up this audit report with a conclusion explaining how do the auditors value the code reviewed, and what are the most important things that need to be corrected to it to make it work flawlessly and securely.

Summary

The contracts audited have been taken from the pixie-tge-smart-contracts repository at: https://github.com/PixieMe/pixie-tge-smart-contracts

The audit is based on the commit 830ec38db0a92e532893a708e5c91827c0a4b53c , and updated to reflect the changes done on commits 7d0aacf2ba5cffee2829f8da0ce21d2ef7740b10 and 62070dfa23d67ca72cca76ffb8a95b066337ec93 on branch check-sender-is-whitelisted , merged into branch master at commit 1b00ae17e58b28e5e9c62623fbc7666f72199b24 .

The audited contracts are these:

PixieCrowdsale.sol: The Pixie Crowdsale logic PixieToken.sol: The Pixie Token PixieTokenAirdropper.sol: Pixie airdropping functions

The Pixie token sale will have an initial supply of 100000000000 tokens issued.

The following analyses were performed:

Misuse of the different call methods: call.value(), send() and transfer(). Integer rounding errors, overflow, underflow and related usage of SafeMath functions. Old compiler version pragmas. Race conditions such as reentrancy attacks or front-running. Misuse of block timestamps, assuming anything other than them being strictly increasing. Contract soft locking attacks (DoS). Potential gas cost of functions being over the gas limit. Missing function qualifiers and their misuse. Fallback functions with a higher gas cost than the one that a transfer or send call allow. Fraudulent or erroneous code. Code and contract interaction complexity. Wrong or missing error handling. Overuse of transfers in a single transaction instead of using withdrawal patterns. Insufficient analysis of the function input requirements. Detailed findings Critical severity

None found.

Medium severity

None found.

Minor severity

Non-exhaustive checks at crowdsale for timestamp setters

It is required for getting the token amount rate. However, the contract setters for the main sale time frame do not enforce this, which may lead to the presale starting before or ending after the main sale, if it is set incorrectly:

function updateOpeningTime(uint256 _openingTime) external onlyManagement { require(_openingTime > 0, "A opening time must be specified"); openingTime = _openingTime; } /** * @dev Allows for updating the private sale close time in the event of a delay * @dev Must be called by management, use sparingly as no restrictions are set * * @param _privateSaleCloseTime the epoch time to set */ function updatePrivateSaleCloseTime(uint256 _privateSaleCloseTime) external onlyManagement { require(_privateSaleCloseTime > 0, "A private sale time must be specified"); privateSaleCloseTime = _privateSaleCloseTime; } /** * @dev Allows for updating the pre sale close time in the event of a delay * @dev Must be called by management, use sparingly as no restrictions are set * * @param _preSaleCloseTime the epoch time to set */ function updatePreSaleCloseTime(uint256 _preSaleCloseTime) external onlyManagement { require(_preSaleCloseTime > 0, "A pre sale time must be specified"); preSaleCloseTime = _preSaleCloseTime; } /** * @dev Allows for updating the pre sale close time in the event of a delay * @dev Must be called by management, use sparingly as no restrictions are set * * @param _closingTime the epoch time to set */ function updateClosingTime(uint256 _closingTime) external onlyManagement { require(_closingTime > 0, "A closing time must be specified"); closingTime = _closingTime; } A way to change this behavior while enforcing the checks to be exhaustive would be: function updateOpeningTime(uint256 _openingTime) external onlyManagement { require(_openingTime > 0, "An opening time must be specified"); openingTime = _openingTime; } function updatePrivateSaleCloseTime(uint256 _privateSaleCloseTime) external onlyManagement { require(_privateSaleCloseTime > openingTime, "Private sale time must be greater than opening time."); privateSaleCloseTime = _privateSaleCloseTime; } function updatePreSaleCloseTime(uint256 _preSaleCloseTime) external onlyManagement { require(_preSaleCloseTime > privateSaleCloseTime, "Presale time must be greater than private sale time."); preSaleCloseTime = _preSaleCloseTime; } function updateClosingTime(uint256 _closingTime) external onlyManagement { require(_closingTime > preSaleCloseTime, "Closing time must be greater than presale time."); closingTime = _closingTime; }

This issue was corrected in the last revision sent to us.

Observations

We annotate some of the verifications done to the contracts to indicate that they were performed even when no critical issue was found during the audit.

Misuse of the different call methods: call.value() , send() and transfer() . We found no incorrect use of call() or send() , and transfer() . Integer rounding errors, overflow, underflow and related usage of SafeMath functions. Race conditions such as reentrancy attacks or front running. There are only two possible calls to another contract: When calling _forwardFunds in the PixieCrowdsale contract, calling OpenZeppelin’s RefundVault contract. In the PixieTokenAirdropper, calling to an ERC20 token, which is set at the construction of the contract and never changed. Misuse