XEL Crypto

Using `averageTerm` to determine the term of several wallets could be manipulated by the user. In the case that a user could create wallets with a very short term with a large amount, and a long term with a quite small amount, the user could get more tokens when claiming these wallets at one time than doing it separately.

In the function `getRewardMultiplier()`, the check should be ```solidity require(finalWeek - 1 >= termWeeks, "Incorrect term format"); ``` to avoid underflow.

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

Addresses should be checked before assignment or external calls to ensure they are not zero addresses.

The `endId` should be checked not over the length of `unmintedWallets[owner]`.

In the `XENWalletManager` contract, the users can create wallets and claim rewards by the wallet information calculated by the term, reward multiplier, and amount. Besides, the `owner` could get the rewards that expired. However, there are some details that are not found in this contract. For example: How to guarantee enough tokens have been transferred into the contract when creating wallets?

The return value of the transfer()/transferFrom() call is not checked. ```solidity=300 xenCrypto.transfer(owner, rescued - xenFee); ``` --- ```solidity=301 xenCrypto.transfer(feeReceiver, xenFee); ```

The contracts cited have an 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 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.