Pac Miner security record

The function `hatchGhosts()` gives rewards to referrers and is called whenever `hatchGhosts()` or `buyGhosts()` is called. The function `buyGhosts()` also updates the reward struct with the chain of referrers. It is possible to loop the referrers so that a user can obtain additional rewards. For example, Alice buys ghosts and refers Bob. Bob then buys ghosts and refers Alice. Then if Alice buys more ghosts and again refers Bob, then their `Rewards` will be updated and set `_upline2` to be `Alice address`. Now Alice is one of their own referrers and will gain additional rewards whenever they hatch ghosts. Additionally, any user could create multiple EOA and make them referrers of each other to collect all of the referral rewards.

In the contract `pacMan_Contract` 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. The hacker can call `initializedMarket()` to start the contract functionality or set the `antiwhalestatus` at his/her will. 

The function `getMyMiners()` takes in any address as an input and returns the associated amount of `hatcheryMiners`. This can also be done without an additional function by making the mapping `hatcheryMiners` public.

The first entry in the rewards struct is `referrer`. But when the struct is in use, the first entry is `msg.sender` and the second entry is `referrer`.

When calculating the `antiwhale` fee, if the value of `antiwhale` is 10 then it will go until the final else statement to determine how much `BNB` to transfer. However it is the same amount that is transfered if the value of `antiwhale` is less than 10.

The name of the contract `pacman_contract` does not follow the naming convention for contracts, which is to use CapWords.

The first person to call `buyGhosts()` with a nonzero value will receive 97500 miners regardless of the amount as the amount bought is dependent on the contract balance, which may be 0 for the first caller if no funds were supplied to the contract beforehand. This means that in the extreme case someone could call this function with `1 wei` and get 97500 miners while then subsequently if the second caller contributed `1 ether` they would only receive 116512 miners. This demonstrates how the first caller gets the best deal and subsequent buyers get worse deals.

The contract lacks proper documentation and comments explaining the design of each function and the reasoning behind the decisions taken.

The functions `buyGhosts()`, `hatchGhosts()`, and `sellGhosts()` use the built in `transfer()` function. There are potential issues with this as this forwards exactly 2300 gas and if the receiving contract has a `fallback` function or gas prices are changed, then the transaction may be reverted. See this [doc](https://ethereum.stackexchange.com/questions/19341/address-send-vs-address-transfer-best-practice-usage) for more details.

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.