Galactixzone

Addresses should be checked before assignment or external call to make sure they are not `address(0)`.

In contract `PreSalePool`, functions `buyTokenWithExactlyBUSD()` and `buyTokenWithExactlyBNB()` use function `verifyWhitelist()` to verify a `_candidate` address can participate in the presale and, for what amount of BUSD they are approved to purchase the presale token with. The input information in function `verifyWhitelist()` is then used in the `Whitelist` library function `verifySignature()`, along with the state variable `signer` address. This function uses `getMessageHash()` to hash together `_salePhase`, `_signer`, `_candidate`, and `_BUSDAmount`, which is then used to check against the provided `_signature` using OpenZeppelin's ECDSA `recover()` function. A `nonce` value is usually incorporated to prevent a user from using the same signature for the exact same message twice within the contract instance. Within the context of the `PreSalePool` contract, it is conceivable that this omission is by design, since the amount a `_candidate` address can purchase is checked against a running sum of what they have already purchased. If `maxBUSDUserCanSpend` for the `currentSalePhase` is a multiple of the `_BUSDAmount` a user is verified to use, then the user may call one of the two buying functions several times. However, if this is not the intention, then we recommend adding a `nonce` in the message hash to keep track of the exact message for which the signature was created. Moreover, specifications such as the name of the function, name of the project, version, and type of project are often used within the message hash to prevent the message from being used elsewhere. This information is typically encoded in a *domain separator* (note not all of this information necessarily must be included, if not relevant). Lastly, a chain ID is usually encoded as well in the event that a fork of the chain occurs. The concern is that a lack of this information within the message hash may allow for a signature to be reused, if the `signer` address is ever used in another context, and if the same generic information is ever used for a message hash. A similar set up is used within the cited functions in contract `dNFT`, creating the same potential issue.

The only time `lockToken()` is called is in function `temporaryMerge()`, where the owner of the token is checked prior, as is the status of whether the token is locked. These same two checks are made within the function `lockToken()` again and are unnecessary, since `lockToken()` is a private function. A similar issue occurs with `unlockToken()`.

A local variable is shadowing another component defined elsewhere. ```solidity=8 constructor(address _admin, uint256 _totalSupply) ERC20("GalactixCoin", "GXZ") { ``` - Local variable `_totalSupply` in `GalactixToken.constructor` shadows the variable `_totalSupply` in `ERC20`.

In contracts `dNFT` and `PreSalePool`, the amount of tokens a user is able to buy is restricted. In `dNFT`, it is restricted by value `_maxAmountUserCanBuy` for the sale phase. This value may be set as high as the `MAX_SALE_AMOUNT`. If the product of (`_maxAmountUserCanBuy`)*(number of users buying) exceeds the `MAX_SALE_AMOUNT`, then it is possible that some users may buy all tokens before others get the chance to purchase the tokens for which they are whitelisted to buy. In `PreSalePool`, a similar issue occurs where if the `maxBUSDUserCanSpend` allows a user to purchase an amount of tokens such that the product of (max amount user can buy)*(number of whitelisted users) exceeds `maxPreSaleAmount`, then some users may be able to purchase all available tokens for the sale phase before other whitelisted members have purchased any tokens at all.

Requiring that `BUSDToken` is transferred from the `from` address to the `treasuryAddress` as a tax may keep a third party who is supposed to be approved to transfer the NFT from being able to transfer the NFT. As constructed, the user who owns the NFT must both give approval to the third party user to move their tokens, but then must also approve the contract for the amount of tax on the `launchPrice` (in `key`, the `keyPrice` - neither are necessarily known ahead of time). Failure to do the second part will keep the third party from being able to transfer the NFT.

The linked `transfer()`/`transferFrom()` invocations do not check the return value of the function call, which should yield `true` in the case of a proper ERC-20 implementation.

Aggregators allow for the possibility of negative values as price. ```solidity uint256 BNBPerBUSDInUint256 = uint256(BNBPerBUSD); ``` The type conversion `uint256(BNBPerBUSD)` from type int256 to type uint256 may cause a negative value to be converted to a large, nonequivalent unsigned integer.

Using Solidity's `transfer()` and `send()` functions for transferring Ether is not recommended, since some contracts may not be able to receive the funds. These functions forward only a fixed amount of gas (2300 specifically) and the receiving contracts may run out of gas before finishing the transfer. Additionally, gas costs may increase in the future. Thus, some contracts that can receive now may stop working in the future due to the gas limitation.

Functions `buyTokenWithExactlyBUSD()` and `buyTokenWithExactlyBNB()` both use `verifyWhitelist()` as a check, where the former function uses input `_BUSDAmount` as `_BUSDAmount` for `verifyWhitelist()` and the latter uses `msg.value` as `_BUSDAmount` for `verifyWhitelist()`. Since verifying an amount of BUSD (for example, 100 BUSD) is different than verifying the same amount of BNB (e.g., 100 BNB), the `msg.value` and `_BUSDAmount` should not be interchangeable in the signature verification process. If a user inputs a signature intended to be used in `buyTokenWithExactlyBUSD()` into function `buyTokenWithExactlyBNB()`, they may be able to buy more tokens faster than other users. Since there is a limit on the total number of tokens that can be bought in a phase, this may give an unfair advantage that leaves other whitelisted users unable to buy tokens.