HashEx was commissioned by the VoidFarm team to perform an audit of VoidFarm smart contracts. The audit was conducted between April 12 and April 16, 2021.
The audited code is located in VoidFarm’s github repository . The audit was performed after the commit 508c815. A recheck was done after commit 1cc0311 . There was limited documentation available at voidfarm.gitbook.io.
Update: VoidToken deployed to BSC at 0x3C44eAf8b4eAEF6e48Bfc18Ee92412BE0b395746 and MasterChef at 0xD72fF7178fb11141492Da457A1B3c4D5143b696c are identical to reviewed  versions.
The purpose of this audit was to achieve the following:
● Identify potential security issues with smart contracts.
● Formally check the logic behind given smart contracts.
Information in this report should be used to understand the risk exposure of smart contracts, and as a guide to improving the security posture of smart contracts by remediating the issues that were identified.
Similar to OpenZeppelin version of release v3.3 with pragma fixed to 0.6.12.
Similar to OpenZeppelin version of release v3.0 with pragma changed to 0.6.12.
Similar to a mix of OpenZeppelin’s v2.5 and v3.0 with pragma changed to 0.6.12.
Similar to OpenZeppelin version of release v3.1 with pragma fixed to 0.6.12.
Similar to OpenZeppelin version of release v3.1 with pragma changed to 0.6.12.
Similar to Compound’s version with minor changes. Audited  by OpenZeppelin in 2019.
Similar to Binance’s version with pragma changed to 0.6.12.
Similar to OpenZeppelin version of release v3.3 with pragma changed to 0.6.12.
Migrations contract from Truffle project, unused.
Helper contract with functions for frontend.
Implementation of BEP20 token with custom functionality.
Similar to SushiSwap’s chef contract with modifications.
01. BEP20 standard violation: High; Fixed
02. Lack of safeguards: Medium; Fixed
03. Unlimited mint by owner: Medium; Informed
04 Inconsistent mine rate: Medium; Fixed
05 Maximum supply can be exceeded: Medium; Fixed
06 Low severity issues & recommendations: Low; Fixed/Informed
#01 BEP20 standard violation (restriction of zero amount transfer): High
transfer() function in VoidToken.sol does not allow to input zero transfer amount as it’s demanded in ERC-20  and BEP-20  standards. This issue may break the interaction with smart contracts that rely on full ERC20 support.
Update: VoidFarm team has removed require statement for transfer amount > 0 in commit 1cc0311 .
#02 Lack of safeguards: Medium
setFeeAddress() functions in MasterChef.sol should require non-zero input addresses.
Update: checks on non-zero addresses were added in commit 1cc0311 .
#03 Unlimited mint by owner: Medium
mint() function in VoidToken.sol could be used by the owner of the contract to unlimitedly mint new tokens. However, the logic of the MasterChef.sol demands ownership of the VOID token. We recommend transferring ownership to MasterChef contract as soon as possible after contract deployment.
Update: ownership was transferred to the MasterChef contract in 0xfcf5e929e8d6b9bbd6457cc84fb39da1daeaa539e9618e7541c5464c5a37764d.
#04 Inconsistent mine rate: Medium
Documentation on the VoidFarm website claims that 0.01 Void mined per block. Around 288 Void tokens per day, a very low emission. Actually, in MasterChef.sol a bigger amount is mined per block as 0.01 Void is minted on the contract’s balance and then 0.0002 Void is minted to dev’s address. Moreover, the minted amount per block can be adjusted by the owner at any time (capped by 10 Void per block).
Update: issue was fixed in commit 1cc0311 .
#05 Maximumsupplycanbeexceeded Medium
Documentation on the VoidFarm website claims that the max supply of Void is restricted by 30k. However, it could surpass restriction as the reward update could take any amount unless the current supply is less than 30k.
Update: issue was fixed in commit 1cc0311 . It must be noted that with these changes if the token supply is bigger than maxSupply parameter (for example, more tokens were preminted) the MasterChef contract won’t work because the function updatePool will always fail.
#06 Low severity and general recommendations: Low
- VoidToken.sol L28–29 contains variables _taxFee and _burnFee that should be declared constans. Update: issue was fixed in .
- MasterChef.sol L55 contain maxSupply variable should be declared constant. Update: issue was fixed in .
- Documentation on the VoidFarm website states a dev fee of 2%. Actually, it’s slightly less (2 of 102). Update: issue was fixed in .
- Any accidental direct, not via
deposit(), Void token deposits to MasterChef.sol will be burned with the next
- Typo in a comment in MasterChef.sol L225. Update: issue was fixed in .
- We recommend adding documentation to the smart contracts.
- We recommend using tests before deployment. At least VoidToken and MasterChef should be covered.
It is crucially important for users before using the token to check that ownership of VoidToken is transferred to MasterChef contract as farming via
mint() won’t work and before this transfer owner of the token can mint an unlimited number of tokens.
One high severity issue was found regarding BEP20 token standard violation.
Audit includes recommendations on the code improving and preventing potential attacks.
Update: high severity issue was fixed before deployment amongst various fixes of the issues from the initial report.
Update: contracts deployed to BSC at 0x3C44eAf8b4eAEF6e48Bfc18Ee92412BE0b395746 and 0xD72fF7178fb11141492Da457A1B3c4D5143b696c are identical to the reviewed ones.
VoidToken’s ownership was transferred to the MasterChef contract in 0xfcf5e929e8d6b9bbd6457cc84fb39da1daeaa539e9618e7541c5464c5a37764d.
HashEx website: https://hashex.org