LandX Finance security record

When `rewardsToDistribute()` is called, it mints the vested tokens and increments the `rewardSharesPerToken`. However, the `rewardSharesPerToken` is not incremented if the vesting has fully completed at the time of the function call, as seen in the following code segment on L245: ```=solidity if (elapsedDays >= rewardVestingDuration) { amountVested = MAX_REWARD_AMOUNT.sub(rewardVested.amountVested); _mint(address(this), amountVested); rewardVested.amountVested += amountVested; rewardVested.lastVestedAt = block.timestamp; } ```

The specified receiver of the `_deposit()` function in `xBasket` never receives the minted xBasket tokens as intended. Additionally, the `deposit()` and `mint()` functions check whether the receiver is able to mint/deposit the requested amount whereas the funds are taken from the `msg.sender`.

The `LNDX` contract uses the global variables `rewardSharesPerToken` and `feeSharesPerToken` to track the amount of rewards and fees to distribute on a per token basis. To track how many rewards each user should receive, the contract stores the amount the user is not entitled to in the mappings `rewardsPerGrant` and `feePerGrant`. The simplified computation for the rewards of a user is then `amountOfTokens * rewardSharesPerToken - rewardsPerGrant`. Whenever a user claims rewards, `rewardsPerGrant` will therefore need to be updated to exclude the rewards that have just been claimed by adding them to `rewardsPerGrant`. The code however subtracts the claimed rewards from `rewardsPerGrant` (L198), which means the user will be able to claim even more tokens with each claim. Similarly, the code subtracts the fee that has been distributed from `feePerGrant` instead of adding it (L192). Additionally, the amount used is likely wrong since all tokens - including unvested ones - are used when computing the rewards.

The `crop` state variable in `xToken` is set to the constant value, "CORN". The `xToken` constructor is designed to receive a value for the string of the crop being created, however, this is just used for the name of the ERC20 token, and not for the assignment of the `crop` state variable. This protocol is intended to work around multiple crops (e.g. xSOY, xWHEAT) however this constant state variable does not allow this as any reading of this state will read "CORN". Further, `xBasket` only considers four predetermined crops. While it is understood that these are the four crops that the `xBasket` will be beginning with, the team should have the functionality to add or remove crops used in the `xBasket` as needed.

A common attack in DeFi is the sandwich attack. Upon observing a trade of asset X for asset Y, an attacker front-runs the victim trade by also buying asset Y, lets the victim execute the trade, and then executes another trade after the victim by trading back the amount gained in the first trade. Intuitively, one uses the knowledge that someone is going to buy an asset, and that this trade will increase its price, to make a profit. The attacker’s plan is to buy this asset cheaply, let the victim buy at an increased price, and then sell the received amount again at a higher price afterward. The `getShards()` function of `xToken` converts both the shards mint fee and the `xTokensAnnualRent` from `xToken` to USDC through a Uniswap router. The `amountOutMinimum` and `sqrtPriceLimitX96` variables specified in the `ExactInputSingleParams` required for the Uniswap swap are set to 1, and 0 respectively, which will execute the swap even if there is one USDC returned to the user or a price of zero for the `xToken`. A savvy user could front-run these swaps to minimize the USDC returned to the `xToken` contract following the swap and profit off of the price change. This issue is also present in `xBasket.autoCompoundRewards()`, except they would be front-running USDC to `xToken` swaps.

The `cToken` constructor instantiates the ERC20 symbol of all cTokens created as "cCorn". This creates cTokens with identical symbols.

The maximum allowable crop share value stored in `KeyProtocolVariables` is unused when minting a new LandXNFT. With nothing limiting the assignable value of the crop shares, LandXNFTs can be minted with crop share values that exceed the `maxAllowableCropShare` for the given crop as specified in `KeyProtocolVariables`.

The contracts use different precision values throughout the code base without properly documenting them. Constants such as `10 ** 3`, `1e6`, `10 ** 7` and `10**9` are just some of the constants that can be found in the code. Without documentation, it is impossible to verify that the correct precision is used everywhere.

EIP-4626 specifies the following requirement for `totalAssets()`: > SHOULD include any compounding that occurs from yield. However, the current implementation of `totalAssets()` does not account for the potential yield.

`unstakePreview()` returns a tuple of the staked amount, rewards, and fees for a given `stakeID` if it were to be unstaked. However, the rewards value is not guaranteed to be accurate because `computeStakeReward()` is dependent on `rewardSharesPerToken`, which can be modified by the `rewardsToDistribute()` call in `unstake()`. The `previewUnstake()` function does not take into account possible changes to `rewardSharesPerToken` when `rewardsToDistribute()` is called.