Baby Doge - NFT Farm

The function `depositOnBehalf` calls `stakeToken.transferFrom` to send tokens from Msg.sender instead of the address `account`. Therefore the address `account` will receive the shares and the reward token instead of the message sender. Therefore the `account` must send tokens to Msg.sender before the Msg.sender calls `depositOnBehalf`. Otherwise the Msg.sender will lose their deposit tokens and previous rewards assuming Msg.sender and `account` are differing accounts. A similar issue can be found in `ERC20FarmFixed`, `ERC721FarmFixed`, and `ERC721Farm`.

Boolean constants can be used directly and do not need to be compared to true or false.

Multiple Solidity versions are used in the codebase. Versions used: `^0.8.11`, `^0.8.0`

For the `ERC20Farm.sol` and `ERC20FarmedFixEnd.sol`, there is a minor risk of a user claiming double rewards via reentrancy. Consider the following scenario: 1. Suppose the stakeToken contains a hook to an external contract for recipient verification. 2. Further suppose that Bob controls a contract that deposits X stakeToken at block 0. 3. At Block 100, Bob's contract then calls withdraw function which transfers the stakeToken. 4. Bob's contract would be able to reenter deposit using the hook. This would allow Bob to collect rewards based on the `withdrawal` call and then the `deposit` call. This would be an issue for ERC721 if safeTransferFrom was used. Further, nonReentrant modifier will not protect against this attack.

Addresses should be checked before assignment or external call to make sure they are not zero addresses.

When calling the `deposit` function there is a potential loss of staked tokens given the following scenario: 1. If the following statement is true: `_amount` > `defaultStakePPS` 2. If `depositedAmount` < `defaultStakePPS` is true where `depositedAmount` = `subsequentBalance` - `initialBalance` Then `user.shares` will not record an updated amount.

The initial require statement of the `deposit()` function always checks that `_amount` is larger then zero. Therefore the fourth require statement is always true.

The owner parameter is shadowing the function `owner` in `Ownable`.

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 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.

The `feeReceiver` are not used in `ERC721FarmFixEnd` and in `ERC721Farm`.