GrabCoinClub

In the contract `GrabCoinClub` 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 unlock a series, set properties, set signer, set admin, set wallet, and withdraw tokens or ether from this contract.  In the contract `GrabCoinClub` the role `admin` has authority over the following functions. Any compromise to the `admin` account may allow the hacker to take advantage of this authority and mint NFT. - mintAdmin() - mintAirdrop() In the contract `Dividends` 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 change contract state addresses which would drastically affect network interactions. 

All of the 6,000,000,000 ether tokens are sent to the contract deployer when deploying the contract. This could be a centralization risk as the deployer can distribute all tokens without obtaining the consensus of the community.

When purchasing with Ether, there is no check to guarantee the appropriate amount was sent by the caller.

The following message does not describe the error correctly. ```solidity=236 require(0 < balance, "ERC721Enumerable: owner index out of bounds"); ```

The function `_sendErc20()` is missing a sanity check to ensure the parameter `tokenAddress` is a contract. If the `tokenAddress` is an EOA, the function call `tokenAddress.call()` will always return true.

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

The function doesn't verify if the supplied `contractURI` or `baseURI` is a valid IPFS location.

Within the current contract, there is no distinction between the different blockchains supported by `GrabCoinClub`. If the signer signed a message on one chain (e.g. Ethereum), and accidentally leaks the message, the message would be valid for a similar transaction of a chain with the same encryption method (e.g. BSC). For example, if the signer signed a message (wallet_, series_, quantity_, tokenAddress_, amount_, nonce_) on Ethereum and the same wallet_, tokenAddress_ exists on BSC. The attacker can reuse this signed message to mint NFT on BSC.

The return value of the transfer()/transferFrom() call is not checked. ```solidity=76 _token.transfer(msg.sender, (total * 10**_token.decimals()) / 10); ``` --- ```solidity=175 IERC20(tokenAddress_).transferFrom(from_, address(this), amount_); ```