Galactixzone

- **Make additional note about admin roles too** In the contract `PreSalePool` the role `superAdmin` has authority over the functions shown in the diagram below. Additionally, the `admin` role has authority over functions: - `setPreSaleToken()` - `setBUSDToken()` - `deployNewSalePhase()` - `setSigner()` - `pause()` - `unpause()` - `setPriceFeed()` Any compromise to the `superAdmin` account may allow the hacker to take advantage of this authority and withdraw all presale tokens from the contract, as well as pause the contract or use the other functions to disrupt the correct operation of the contract. The `admin` role also has the ability to disrupt the normal operation of the contract.  --- In the contract `DNFT` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set the `treasuryAddress` to a malicious one, as well as pause the contract or use the other functions to disrupt the correct operation of the contract.  --- In the contract `DKeyNFT` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and set the `treasuryAddress` to a malicious one, as well as pause the contract or use the other functions to disrupt the correct operation of the contract. 

`PreSalePool`, `dNFT`, and `key` are upgradeable contracts; the owner can upgrade these contracts without the community's commitment. If an attacker compromises the account, they can change the implementation of the contract and drain tokens from the contract.

All `GXZ` tokens are sent to an input `_admin` address when deploying the contract. This is a potential centralization risk as the deployer can distribute `GXZ` without the consensus of the community.

Encoding through `abi.encodePacked()` is used with at least two dynamic type inputs controlled by the user. This type of encoding is susceptible to malleability when used with strings, bytes, or other dynamic types. As such, it is not a good choice for signature verification with the input used, since users can change the input and potential get the same bytes output from from `abi.encodePacked`. Moreover, note that uints and other variable types do not need to be converted to strings before being encoded.

The hardcoded aggregator address is cited as the pair DAI/BNB while the contract is set up for use with BUSD and BNB. While both stablecoins, there are slight differences in the prices of BUSD and DAI which could cause inaccurate price calculations.

The contracts cited are serving as the underlying entity to interact with one or more third party protocols. The scope of the audit treats third party entities as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. ```solidity AggregatorV3Interface internal priceFeed; ``` - The contracts `PreSalePool`, `dNFT`, and `key` interact with a third party contract using the `AggregatorV3Interface` interface via `priceFeed`. --- ```solidity IERC20 public BUSDToken; ``` - The contracts `PreSalePool`, `dNFT`, and `key` interact with a third party contract using the `IERC20` interface via `BUSDToken`.

The `priceFeed` state variable is using a hardcoded testnet address at initialization.