TokenAndPresale Manual Review Findings

TAP-01M: Inapplicacy of Checks-Effects-Interactions Pattern

Description:

The linked code segments perform BNB transfers mid-execution, opening up the functions to re-entrancy vulnerabilities.

Example:

Copy
250function claimDevFeeAndAddLiquidity() external onlyOwner {
251   require(!devClaimed);
252   uint256 forDeflect = address(this).balance.mul(200).div(1000); // 20%
253   uint256 forMultisig = address(this).balance.mul(425).div(1000); //42.4%
254
255   multisig.transfer(forMultisig);
256   deflect.transfer(forDeflect);
257   devClaimed = true;
258
259   moonMissionStart();
260}

Recommendation:

We advise that the Checks-Effects-Interactions is applied here whereby any BNB transfers that are meant to be made are done so at the end of the function's execution after all state changes and event emittances.

Alleviation:

The Checks-Effects-Interactions pattern is properly applied in the latest iteration of the codebase.

TAP-02M: Potentially Breaking Functionality

Description:

The transfer opcode assigns a static gas amount to the external call that transfers funds outwards which can be changed in a consequent fork of Binance and thus cause such transfer calls to fail.

Example:

Copy
250function claimDevFeeAndAddLiquidity() external onlyOwner {
251   require(!devClaimed);
252   uint256 forDeflect = address(this).balance.mul(200).div(1000); // 20%
253   uint256 forMultisig = address(this).balance.mul(425).div(1000); //42.4%
254
255   multisig.transfer(forMultisig);
256   deflect.transfer(forDeflect);
257   devClaimed = true;
258
259   moonMissionStart();
260}

Recommendation:

We advise that an OpenZeppelin wrapper implementation is instead used safely, such as the sendValue function of the Address library, to ensure compatibility at the EVM level perpetually.

Alleviation:

The instances of transfer were properly replaced by their sendValue counterpart.