Laxce

The current contract architecture allows for the USDT contract to be changed without the following variables, struct and mapping being correctly updated. If the contract owner updates the usdt contract by calling _changeUsdtToken() before the end of the token sale, the value of usdtRaised would become inaccurate because it now holds the value of the old tokens contributed as well as the new tokens. Similarly, the UserInfo struct and users mapping which keeps track of the user’s individual contributions would become inaccurate.

The contract implements a limit to the amount of USDT a user can use in a single purchase described in the initialize function:minimumBuyLimit = 5000; maximumBuyLimit = 500000; These values do not take into account the decimals of the USDT token (6 decimals on ETH) thereby making the equivalent amounts to be less than viable purchase amounts. minimumBuyLimit = 5000; // 0.005 USDT maximumBuyLimit = 500000; // 0.5 USDT

The contract does not call UUPSUpgradeable_init() in its initialize function.

The contract could follow the conventions of the Solidity style guide which provide that non-external (and public) functions should be prefixed by an underscore. This would improve contract readability. Reference.

There are a number of redundancies within the codebase described below:1. Unused struct: Currently there is no functionality to provide users with any benefits for contributing to the private sale. The usdtContributed and laxceReceived fields are unused after they are set in the buyTokens function call. user.usdtContributed += usdtAmount; // @audit-issue unused       user.laxceRecieved += tokens; // @audit-issue unused   1. Inaccurate userInfo details: When a user calls buyTokens , the _beneficiary address passed in is redundant. Payment is made from the msg.sender wallet and tokens are transferred to the msg.sender, not the beneficiary wallet. Within the UserInfo struct the user key is the _beneficiary and not the msg.sender who makes all transactions and should accrue all benefits.

The _deliverTokens function uses the vanilla erc20 transfer and doesn’t check the return values of the transfer function or perform any address checks which could potentially revert execution. To handle potential reverts or failures during token transfers, the SafeERC20 library is recommended to be used - in this case, the safeTransfer function within this library would be advised to implement to take care of any potential errors unhandled by the regular transfer function. This is implemented in some parts of the codebase but is missing on the line specified.