CrowdFunding Static Analysis Findings

CFG-01S: Inexistent Visibility Specifiers

Type	Severity	Location
Code Style		CrowdFunding.sol:L46, L47, L55, L56

Description:

The linked variables have no visibility specifier explicitly set.

Example:

Copy
46mapping(uint256 => FtsoReward) pendingStakersRewards;

Recommendation:

We advise them to be set so to avoid potential compilation discrepancies in the future as the current behaviour is for the compiler to assign one automatically which may deviate between pragma versions.

Alleviation:

The CloudFunding team has opted not to alleviate any informational or minor exhibits they disagree with, thus rendering this exhibit as acknowledged.

CFG-02S: Inexistent Sanitization of Input Address

Type	Severity	Location
Input Sanitization		CrowdFunding.sol:L58-L70

Description:

The linked function accepts an address argument yet does not properly sanitize it.

Impact:

The presence of zero-value addresses, especially in constructor implementations, can cause the contract to be permanently inoperable. These checks are advised as zero-value inputs are a common side-effect of off-chain software related bugs.

Example:

Copy
58constructor(
59    address _manager,
60    address _projectOwner,
61    uint256 _natLotSize,
62    uint256 _tokenLotSize,
63    uint256 _lotQty,
64    uint256 _raiseDeadline,
65    uint256 _stakingDuration,
66    string memory _projectDescription,
67    string memory _iouName,
68    string memory _iouSymbol,
69    uint8 _iouDecimals
70) IOU(_iouName, _iouSymbol, _iouDecimals) {

Recommendation:

We advise some basic sanitization to be put in place by ensuring that the address specified is non-zero.

Alleviation:

The CloudFunding team has opted not to alleviate any informational or minor exhibits they disagree with, thus rendering this exhibit as acknowledged.

CFG-03S: Improper Invocations of EIP-20 transfer

Type	Severity	Location
Standard Conformity		CrowdFunding.sol:L349, L498

Description:

The linked statement do not properly validate the returned bool of the EIP-20 standard transfer function. As the standard dictates, callers must not assume that false is never returned.

Impact:

If the code mandates that the returned bool is true, this will cause incompatibility with tokens such as USDT / Tether as no such bool is returned to be evaluated causing the check to fail at all times. On the other hand, if the token utilized can return a false value under certain conditions but the code does not validate it, the contract itself can be compromised as having received / sent funds that it never did.

Example:

Copy
349wNat.transfer(to, totalRewards);

Recommendation:

Since not all standardized tokens are EIP-20 compliant (such as Tether / USDT), we advise a safe wrapper library to be utilized instead such as SafeERC20 by OpenZeppelin to opportunistically validate the returned bool only if it exists in each instance.

Alleviation:

The CloudFunding team has stated that the transfer call is performed on a known token implementation and as such it is safe to execute it directly. As a result, we consider this exhibit nullified.