Description: The buyToken() function allows the caller to specify any arbitrary duration for the vestDurationInMinutes parameter as it is not verified in the signature.

Risk/Impact: Any user can specify a short vestDurationInMinutes duration, enabling them to claim the remaining tokens due to them much earlier than intended by the team.

Recommendation: The vestDurationInMinutes value associated with the 'BuyOrder' should be verified in the signature via the verifySign() function to ensure that only vesting durations approved by the team can be used.

Resolution: The team has implemented the above recommendation.

Description: In the claimLinearVestAmt() function, there's a risk that claimAmount can exceed availableAmount if enough time has elapsed between claims.

Risk/Impact: If claimAmount exceeds availableAmount, the transaction will revert due to an underflow error when trying to decrease availableAmount. As a result, the user will not be able to claim their remaining tokens.

Recommendation: An if-statement should be added to the claimLinearVestAmt() function that checks if claimAmount exceeds availableAmount. When true, claimAmount should be set equal to availableAmount to ensure that the user can claim all of their remaining tokens.

Resolution: The team has implemented the above recommendation.

Description: In the if-statement in the linearVest() function, availableAmount is not updated to reflect the additional tokens being added to the user's vesting schedule.

if (linearVests[msg.sender].status == true) {
	linearVests[msg.sender].totalAmount += totalAmount;
	linearVests[msg.sender].amount += _amount;
	linearVests[msg.sender].vestDurationInMinutes += vestDurationInMinutes;
	linearVests[msg.sender].availableAmount;

Risk/Impact: These additional tokens purchased by the user can never be claimed.

Recommendation: availableAmount should be increased by _amount in the if-statement in the linearVest() function.

Resolution: The team has implemented the above recommendation.

Description: The vestDurationInMinutes value for each vesting schedule does not represent the total duration in which tokens are vested.

Risk/Impact: The vestDurationInMinutes value is misleading and as a result could be incorrectly set, as it does not accurately reflect the expectations it implies.

Recommendation: The team should adjust the logic in the claimLinearVestAmt() function by properly following a linear vesting schedule to ensure vestDurationInMinutes represents the full duration until a user can claim 100% of the tokens they are entitled to.

Resolution: The team has modified the logic to now properly reflect vestDurationInMonths.

Description: In the claimLinearVestAmt() function, the calculation extends the user's subsequent claim time proportionally to the delay in initiating their last claim. Consequently, the timing for the user's next claim is pushed further into the future, effectively penalizing users who delay their claims. This approach diverges from the intended linear vesting schedule.

linearVests[msg.sender].nextClaim += count * 2 minutes;

Risk/Impact: The overall vesting period is extended based on the time that a user waits in between claims, with the next claim time being set to reflect these delays.

Recommendation: We suggest that the team revisit and adjust the logic within the claimLinearVestAmt() function to guarantee a true linear vesting schedule, irrespective of the timing of user claims.

Resolution: The team has implemented the above recommendation.

Description: The buyToken() function permits the caller to set the referalStatus parameter to 'refer' without conducting any verification to ensure its validity through the transaction's signature.

Risk/Impact: Any user can specify 'refer' for the referalStatus parameter and be able to receive an additional referral bonus without any verification by the team.

Recommendation: The referalStatus parameter associated with the 'BuyOrder should be verified in the signature via verifySign() function to enforce whether or not the referral status has been approved by the team.

Resolution: The team has implemented the above recommendation.

Description: The verifySign() function does not include the contract address when hashing values for the transaction to verify the signature.

Risk/Impact: This could allow users to repurpose a signature meant for a different contract or chain, in the event a similar contract exists.

Recommendation: The verifySign() function should include this contract's address into the hash, ensuring signatures are specific to this contract alone.

Resolution: The team has implemented the above recommendation.

Description: An inconsistency exists in the buyToken() function as, initially, 25% of the purchase amount is allocated to the recipient of the buyOrder, while the remaining 75% of tokens are vested towards the caller of the transaction.

Risk/Impact: Should the recipient and the caller not be the same address, this setup results in tokens being distributed to two separate addresses from a single purchase. This may lead to potential misalignment with the team's intended token distribution.

Recommendation: The buyToken() function should be modified to ensure tokens are both transferred and vested either to the caller or the recipient of the buyOrder, ensuring consistent token allocation on purchases.

Resolution: The team has indicated that this functionality is intended.

Description: Although the contract inherits ReentrancyGuard, the nonReentrant modifier is not used in the contract.

Recommendation: The team could remove the ReentrancyGuard contract to reduce contract size and deployment costs.

Resolution: The team has removed the ReentrancyGuard contract.

Description: The initialPercent state variable cannot be modified but is not declared constant.

Recommendation: The above state variable could be declared constant for additional gas savings on each reference.

Resolution: The team has added a function that allows them to update the initialPercent state variable.