THE9Company security record

The codebase contains multiple Solidity versions, which can lead to unexpected behavior, potential vulnerabilities, difficulties in maintaining the code, and inconsistencies in the execution of the smart contract. Using different versions may also result in increased complexity during code auditing, as different security features and bug fixes are present in different versions of the compiler. Versions used: `^0.8.0` `^0.8.0` is used in THE9.sol file. ```solidity=905 pragma solidity ^0.8.0; ```

Literals with many digits are difficult to read and review. ```solidity=1262 _mint(_msgSender(), _calcDecimal(10000000000)); ```

In the current smart contract design, the role `ORG_ADMIN_ROLE` holds an unusually high level of privilege, including the ability to execute the main functions like `transferAmountWithLock` and `createAmountWithLock`. Moreover, the `updateAmountWithLock` function allows this role to modify existing token amounts for a given `beneficiary`, which is particularly concerning. This approach raises significant security and centralization risks. The `ORG_ADMIN_ROLE` (which is also the `PAUSER` and `DEFAULT_ADMIN`) represents a single point of failure, and if compromised, it could jeopardize the entire contract's integrity. This setup also heavily centralizes control, undermining the decentralized nature of blockchain technologies. Given these concerns, we would like the team to clarify the rationale behind those design choices and to add multiple layer of security to such account (e.g., multi-sig).

The `lockCycleDays` field of the `BeneficiaryInfo` mapping has no upper bound. This means that if this value is set to a very big number and a certain percentage of `amount` has been transferred to the user already, the `_getNextReleaseTime` will increase by a `lockCycleDays` days (set as a big number). Therefore, no amount could be released for that `beneficiary` before the `lockCycleDays` amount of days passes and there will be no way to update that record again (since the `remainPercent` will not be 100).

The function `updateAmountWithLock` before updating the details in the `BeneficiaryInfo` mapping, it checks wether the mapping exists and the `remainPercent` is higher than `100`. Although, the mapping is retrieved a second time at the pointed locations, while the original `beforeInfo` could be used.

The `SafeMath` library is used unnecessarily. With Solidity compiler versions 0.8.0 or newer, arithmetic operations will automatically revert in case of integer overflow or underflow. ```solidity=46 library SafeMath { ``` - An implementation of `SafeMath` library is found. --- ```solidity=1361 remainPercent = SafeMath.sub(remainPercent, beforeInfo.unlockPercent); ``` - `SafeMath.sub` is called in `transferAmountWithLock` function of `THE9` contract. *Note: Only a sample of 1 `SafeMath` library usage in this contract (out of 6) are shown above.*