Weeweepad security record

This is because when nfts are purchased, entire funds are immediately sent to the companyAddress.The issue here is that the companyAddress was mistakenly uninitialized in the constructor due to a coding error and therefore set to address(0). Which means all funds will be burnt or lost (sent to address(0)).

stake function is designed to take address and amount parameters. This implementation introduces the possibility of malicious users passing stakers address with 1 wei, and repeatedly calling this for the purpose of extending the redeem period of these stakers.

Removing an address from the whitelisted addresses will set the mapping of whitelist to false, change the element in the whitelistItems[index[i]] to the last element and then delete from the whitelistIndex and whitelistItems mapping. Not updating the whitelistIndex mapping before deleting will introduce an unexpected behavior.

This is a custom token contract built without the integration of the standard ERC20 contract, like the Openzeppelin library. The approve function is designed to always increase the amount of tokens a spender can spend.This introduces an issue that makes it impossible to ever reduce the amount of a spender unless the spender has exhausted their approved amount.

The buy function requires a signature operation getting signed by the signingkey om the backend. However, it allows for signature replay attacks as users can use the same signature multiple times.

In addPublicRandom, it updates _addressess[val] to _addresses[arrLength - 1]. However, _addresses[arrLength - 1] was already deleted before that line. Therefore, some addresses will be lost and not get whitelisted. This will also at some point add the null address as a whitelisted address with a tier. Some addresses will be lost in the process of adding and will sometimes run into an arithmetic error due to the second loop (in a situation when provided address parameters are lesser than 32).

In the case where isNativeToken == false after people funds are already in the contract and sale has ended, even without minimum raise not check before removing sale token. This is possible due to removeOtherTokens() function preventing token from being fundToken but doesn't prevent token from being saleToken in the case where isNativeToken == false, making rugpull a possibility:

the buy function will revert anytime a user intends to get the StakingLot or NFTStakingLot token. There is a if-condition in the the _beforeTokenTransfer hook function that is ensuring that the sender lockup period has reached and that the lastBoughtTimestamp of the sender is greater than the receiver.When users invoke the buy function, it runs until it enters the _mint function and then reverts due to the extended logic implementation on the _beforeTokenTransfer since this is called within the _mint function.It is important to stress that the logic in the _beforeTokenTransfer is flawed. Since it expects that token transfer to be enabled after the lockup period is over, the if-condition is expected to be lastBoughtTimestamp[from].add(lockupPeriod) <= block.timestamp (check lockupFree modifier).

The changeFeeInfoOnPool() call setFeeInfo() on the pool which requires pool not started yet, however their is not minimum cooldown time before pool starts meaning pool creator can set pool to start 2 seconds immediately pool gets created preventing protocol factory from setting fee.

To detect when addresses have been whitelisted, it is compared that whitelist[addresses[i]] is not equal to the true constant value.