Chill

The amount of `XDD` to be minted to `TeamLock` and `AdvisorLock` can exceed their limits. Let's direct our attention to `AdvisorLock`. On line 13 of `XDD.sol` we notice the amount to be minted to the `AdvisorLock` should not exceed two percent of the `TotalSupply`. The function `initialize()` sets `adviserUnLockDuration = 2 * privateUnLockDuration` where `privateUnLockDuration is `31104000`. Suppose `adviserLockAddr[deployer] = 100000`. If the deployer calls `claimAdviserUnLockFunds()`, they will receive `200 million XDD tokens` which is an additional 2% of the `TotalSupply`. The issue stems from this calculation ```solidity if (duration > adviserUnLockDuration) { duration = adviserUnLockDuration; AdviserLock * adviserLockAddr[user] * duration / privateUnLockDuration / ONE_HUNDRED_PERCENT - adviserClaimed[user]; ``` Notice `duration / privateUnLockDuration = 2` which is why that additional `2%` was minted.

Functions which are never called internally within a contract should have an external visibility. ```solidity=18 function initialize() initializer public { ``` --- ```solidity=19 function setBaseURI(string memory buri) public onlyOwner { ``` --- ```solidity=23 function mint(address to, uint256 tokenId) public onlyOwner { ``` --- ```solidity=92 function decimals() public view virtual override returns (uint8) { ``` ```solidity=52 function decimals() public pure override returns (uint8) { ``` --- ```solidity=56 function initialize() initializer public { ``` --- ```solidity=92 function queryPrivateTotalLockFunds(address user) view public returns (uint256){ ``` --- ```solidity=95 function queryAdviserTotalLockFunds(address user) view public returns (uint256){ ``` --- ```solidity=98 function queryTeamTotalLockFunds(address user) view public returns (uint256){ ```

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

Redundant reads and writes to storage consume additional gas which results in a more costly execution. For example lets examine the following code, ```solidity function setTeamLockAddr(address[] memory to, uint256[] memory percent) external onlyOwner { require(to.length == percent.length, "length error"); for (uint256 i = 0; i < to.length; i++) { teamLockTotalPercent -= teamLockAddr[to[i]]; teamLockAddr[to[i]] = percent[i]; teamLockTotalPercent += percent[i]; } require(teamLockTotalPercent <= ONE_HUNDRED_PERCENT, "Too many team funds raised"); } ``` There are two reads and writes to the variable `teamLockTotalPercent`. This is redundant and can be done in one line. The following changes increase gas efficiency. ```solidity function setTeamLockAddr(address[] memory to, uint256[] memory percent) external onlyOwner { require(to.length == percent.length, "length error"); for (uint256 i = 0; i < to.length; i++) { teamLockAddr[to[i]] = percent[i]; teamLockTotalPercent = teamLockTotalPercent - teamLockAddr[to[i]] + percent[i]; } require(teamLockTotalPercent <= ONE_HUNDRED_PERCENT, "Too many team funds raised"); } ```

The following import statements in `XDD.sol` are redundant: ```solidity import "@openzeppelin/contracts-upgradeable/token/ERC20/ERC20Upgradeable.sol"; import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol"; ``` because `ERC20BurnableUpgradeable.sol` already imports those two contracts. At this link [ERC20BurnableUpgradeable](https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable/blob/master/contracts/token/ERC20/extensions/ERC20BurnableUpgradeable.sol) you can see that the two linked contracts imported on lines 6 and 8. Similarly, the following import statement on line 4 in `ERC721.sol` is redundant because ```solidity import "@openzeppelin/contracts/token/ERC721/extensions/ERC721Burnable.sol"; ``` the line above imports `ERC721.sol`.

The contract has unlocked compiler version. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to differing compiler version numbers. This can lead to an ambiguity when debugging as compiler specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.