TenGuDaruma security record

In the contract `FarmStaking` 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.  In the contract `FarmStaking` the role `_owner` also has authority over the functions in commit'f677e3b53fa79d062cce3dd6a3c8f4b871192193'. - function `pause()`: to pause the transactions. - function `unpause()`: to unpause the transactions. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority. In the contract `WishPool` 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.  In the contract `WishPool` the role `_owner` also has authority over the functions in commit'f1b5f8bc84f224cfc434705c7d15f50ed60fb970'. - function `pause()`: to pause the transactions. - function `unpause()`: to unpause the transactions. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.

In the contract `FarmReward` 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.  In the contract `FarmReward` the role `_owner` also has authority over the functions in commit'ca81e9d775e7631c854c8fd6c6a9069925e208c4'. - function `pause()`: to pause the transactions. - function `unpause()`: to unpause the transactions. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.

One or more declarations do not conform to the [Solidity style guide](https://solidity.readthedocs.io/en/v0.7.3/style-guide.html#naming-conventions) with regards to its naming convention. Particularly: - `camelCase`: Should be applied to function names, argument names, local and state variable names, modifiers - `UPPER_CASE`: Should be applied to `constant` variables - `CapWords`: Should be applied to contract names, struct names, event names, and enums.

The contract is serving as the underlying entity to interact with one or more implementations that are out of the scope of this audit, such as `appConf.getRewardAmount()`,`nftFactory.tokenDetail()`, `IFactory(appConf.getNftFactoryAddr()).mintDamo()`, `IERC20Ex(redeemToken).safeTransferFrom()`, etc. The scope of the audit treats these codes as black boxes and assumes their functional correctness. The detailed dependencies are listed below: ```solidity contract AppConf contract damoFactory contract daMoContract contract wishDaMo interface IERC20Ex ```

Performing integer division before multiplication truncates the low bits, losing the precision of calculation. ```solidity=175 uint256 multiple = elapsedTime / appConf.getRewardPeriod(stakingRecord.gen); ``` ```solidity=176 rewardAmount = nftCount * (multiple * appConf.getRewardAmount(stakingRecord.gen)); ```

External calls are made inside a *for* loop. This might lead to a denial-of-service attack. If any of the calls fail, it will cause the entire loop to revert.

The logic of functions `_claimAll()`, `_claim()`, `unstakeAll()` and `_unstake()` are too complex and contain many loops. Loops that do not have a fixed number of iterations, for example, loops that depend on storage values, have to be used carefully. Due to the block gas limit, transactions can only consume a certain amount of gas. Either explicitly or just due to normal operation, the number of iterations in a loop can grow beyond the block gas limit which can cause the complete contract to be stalled at a certain point. This may not apply to view functions that are only executed to read data from the blockchain. Still, such functions may be called by other contracts as part of on-chain operations and stall those. Please be explicit about such cases in the documentation of your contracts.

The `tokenIds` may be duplicated among different types of NFTs, hence the `stakingStatusMap` should not only record the `tokenIds`, but also the NFT type.

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

When the `rewardType` is not `Model.REWARD_TYPE_FIXED`, investors may get less reward because of solidity's division truncation feature. e.g. If the `nftCount == 1`, `appConf.getRewardAmount(stakingRecord.gen) == 1`, `appConf.getRewardPeriod(stakingRecord.gen) == 7 day`, `elapsedTime == 13 day`, the `rewardAmount` would be 1, which means the 6 of 13 days for staking are nullified.