Ecotrader security record

InvestmentToken does not use fixed solidity versions. The contract is using unfixed pragma (^0.8.0), Contract should be deployed with the same compiler version and flags that they have been tested thoroughly. Using floating pragma does not ensure that the contracts will be deployed with the same version. The most recent compiler version may get selected while deploying a contract which has a higher chance of having bugs in it.

setAdmin2() function emits the AdminUpdated() event but for the second isAdmin1 parameter it passes argument as false while setting the _admin2 address as a new admin.

Currently _withdraw() contains logic to handle (token == address(this)) in if{}. Because the withdrawMintedTokens() is removed, The redundant code needs to be removed from _withdraw().

Currently _withdraw() is getting used in withdrawUSDC() and withdrawWeth() , in these two functions its checking that the amount that admin is trying to withdraw is less than or equal to what this contract address holds, the similar thing is getting checked in _withdraw() on L256. This redundant check can be removed.

Currently, users can invest directly after the contract gets deployed. There’s no start and end period for calling invest().

This should be noted that the contract has two pausing mechanisms.The pauseInvestment() and unpauseInvestment() functions set the value for investmentPaused. And pause() and unpause() which calls inherited _pause() and _unpause() from the Pausable contract respectively. whenNotPaused() modifier from the inherited functionality is getting used for the invest() function and investmentPaused value is getting used for the invest() function on the L102.

The maximum investment limit check on the L119 can be tricked by users by using multiple addresses by one user to invest more amount than the maximumInvestment limit.The issue doesn’t create any direct security risk and is getting highlighted only for providing more information.

Users would be able to claim some percentage of the amount for the elapsed month directly after investing.This is because in the _calculateClaimableTokens() function, the claimablePercentage gets calculated with monthsPassed (already elapsed time) let’s say that is 19 months already. So now when the user invests again after 19 months the claimableTokens will be calculated according to the elapsed time. So the user can claim the amount for 19 months without waiting for 19 months. Additionally, the user can perform this action in a way where the already invested user will invest after 19 month and after 1 month ( when 20 months will complete) will take 100 percent claim amount. In another case, an already invested user can invest and claim both after 20 months have elapsed, so in this case user would be able to directly claim the amount without waiting. Our recommendation is to consider checking that it matches the business logic.