Gooeys.io security record

The user inputting the ids into `getTumbleCost()` need not own the tokens they input in the function call.

The `GooeyFruit.sol` contract does not conform to the order of layout recommended by the solidity documentation which is the following: - Type declarations - State variables - Events - Functions Reference: https://docs.soliditylang.org/en/v0.8.9/style-guide.html#order-of-layout

Inside the code and the documentation (https://dogira.gitbook.io/goobook/game-mechanics/usdgoo-tokenomics) the ticker of the token is "GOO" but here is "GTO".

In `GooeyFruit.sol` at line 180 is passed to the `buyFood()` function the variable `_receipient` instead of `_recipient`. --- In `GooeyFruit.sol` at line 189 is passed to the `buyFoodAltToken()` function the variable `_receipient` instead of `_recipient`.

In the file `Gooeys.sol`, the function code `pickGeneticCosmetic()` is difficult to read because of the nested ternary operators. --- Attempting to break down the logic, the statement seems to read as: ```solidity if cos1 == cos2 { if randomRoll % 100 < 90 { // Is randomRoll mod 100 less than 90? If yes, return uint(cos1); // return first cosmetic value. } if randomRoll % 100 < 30 { // Is randomRoll mod 100 less than 30? If yes, if randomRoll & 2 == 0 { // is it even? If yes, return uint(cos1); // return cos1. } return uint(cos2); // if randomRoll mod 100 less than 30 and odd, return cos2 } return newCos; // if cos1 == cos2 and randomRoll mod 100 not less than 90, then use newCos } return newCos; // if cos1 and cos2 values are different, use newCos ``` If this is the intended set up, there are issues with this. First, if `cos1 == cos2`, there is no need to choose `cos2` over `cos1` since they are the same value. Second, if `randomRoll % 100 < 30` then it is also true that `randomRoll % 100 < 90`. Since the code first checks that the modulus is less than 90, this case will always be executed first and return `cos1`, so the case where the modulus is less than 30 will never be used.

The only place that this contract can be paid `MATIC` is through the `withdraw()` function. Since this function is only callable by the owner of the contract, only the owner can potentially send `MATIC` to this contract, in which case, the value of the call is automatically sent back to the owner.

Contracts have unlocked compiler versions. 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 different compiler versions. 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.

Inside `Gooeys.sol` at line 338 is made a call to `requestRandomness()` which returns a bytes32 as we can see from `VRFConsumerBase.sol`: ```solidity function requestRandomness(bytes32 _keyHash, uint256 _fee) internal returns (bytes32 requestId) { LINK.transferAndCall(vrfCoordinator, _fee, abi.encode(_keyHash, USER_SEED_PLACEHOLDER)); uint256 vRFSeed = makeVRFInputSeed(_keyHash, USER_SEED_PLACEHOLDER, address(this), nonces[_keyHash]); nonces[_keyHash] = nonces[_keyHash] + 1; return makeRequestId(_keyHash, vRFSeed); } ``` No return value is captured or used for this call.

To adhere to the check-effect-interaction pattern, all updates to state should occur before external calls to other contracts.

In the sum for `mutationHigh`, the value for `adjBond/400` at most only adds a value of 5 to the total sum. Relative to the other values added in the sum, this value is low.