OneRare V2

According to the project whitepaper: **Rare Dishes can be minted multiple times but each subsequent mint will get progressively harder. The first mint of each Dish will require the player to collect 1 copy of each Ingredient. With each mint, the number of Ingredients needed to combine the recipe will square exponentially.** For example : The First French Fry mint will require 1 Oil, 1 Potato and 1 Salt. The Second French Fry mint will require 4 Oil, 4 Potato and 4 Salt. The Third French Fry mint will require 9 Oil, 9 Potato and 9 Salt. However, in the current implementation of function `cookDish()`, the second mint will require **3** of each ingredient and the third mint will require **5** of each ingredient, which is inconsistent with the intended design. This might cause the price of minting a dish to be smaller than expected.

*This issue is considered benign because the reentrancy only acts as a double call.* A reentrancy attack can occur when the contract creates a function that makes an external call to another untrusted contract before resolving any effects. If the attacker can control the untrusted contract, they can make a recursive call back to the original function, repeating interactions that would have otherwise not run after the external call resolved the effects. ### External call(s) File: contracts/ORareNft.sol (Line 120, Function `create()`) ```solidity _mint(to_, id, initialSupply_, data_); ``` * This function call executes the following external call(s). * In `ERC1155._doSafeTransferAcceptanceCheck`, * `IERC1155Receiver(to).onERC1155Received(operator,from,id,amount,data)` * This call sends Ether. ### State variables written after the call(s) File: contracts/ORareNft.sol (Line 122-123, Function `create()`) ```solidity _tokenSupply[id] = initialSupply_; nextId++; ``` ### Same issue was also seen in function createBatch(). Please notice that this issue is the same with the [**Revest Exploit**](https://revestfinance.medium.com/revest-protocol-exploit-recovery-plan-b06ca33fbdf5).

According to the current implementation, call to the function `claimReward()` might revert because of the gas exhaustion. This might happen when the total types of `ORareNFT` are large while only a small number of NFT types will be distributed through the staking contract. In this case, the while loop between L476 and L479 will loop through all the NFT types until finding an NFT id that the vault contract owns. Since in each loop function `_oRareNft.balanceOf()` will be executed, it is possible that the gas will be exhausted during the loops.

In the current implementation, the fee percent of marketplace can be set as much as 100%. There should be a bound that limits how high the fees can be set in the linked functions.

Current implementation of `updateTotalRewards()` function could be vulnerable to Front-Running attacks. When a malicious user speculates the owner calls `updateTotalRewards()`, he can execute a `claimRewards()` call in the `ORareNftStaking` contract and let his call "front-run" the owner's call, so that the actual number of rewards added to the vault contract will be larger than the owner ever wanted to increase.