VAIOT security record

In the contract `StakingRewards` 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. - `notifyRewardAmount()`: allows the owner to specify the rewards and duration for the next reward period - `changeStakeLimit()`: allows the owner to change the user staking limit - `changePoolLimit()`: allows the owner to change the pool staking limit - `changeGracePeriod()`: allows the owner to change the grace period - `changeFeeCollectingWallet()`: allows the owner to change the fee collecting wallet - `changeFeeAmount()`: allows the owner to change the amount of fees collected - `recoverERC20()`: allows the owner to return ERC20 tokens that were sent to the contract by accident - `transferOwnership()`: allows owner to change the ownership of the contract 

In the function `constructor()`, there is no mechanism to confirm that the input reward token address `_rewardToken` and `_stakingToken` are distinct. If they are identical, stakers may be unable to withdraw their staked tokens because those tokens are being utilized as reward tokens.

When transferring standard ERC20 deflationary tokens, the input amount may not be equal to the received amount due to the charged transaction fee. As a result, an inconsistency in the amount will occur and the transaction may fail due to the validation checks. For example, if a user sends 100 deflationary tokens (with a 10% transaction fee) to the target contract, only 90 tokens actually arrive to the contract.

Addresses are not validated before assignment or external calls, potentially allowing the use of zero addresses and leading to unexpected behavior or vulnerabilities. For example, transferring tokens to a zero address can result in a permanent loss of those tokens. - `_feeAddress` is not zero-checked before being used. --- - `_newWallet` is not zero-checked before being used.

There are no upper boundaries for **FEE_PERCENTAGE** which is used to charge fee from the user. It is possible to set the total fee rate up to any arbitrary amount. The `changeGracePeriod()` function also lacks the upper bound checking.

The change of `_owner` by function `transferOwnership()` overrides the previously set `_owner` with the new one without guaranteeing the new `_owner` is able to actuate transactions on-chain.

The contract is serving as the underlying entity to interact with one or more third party protocols. The scope of the audit treats third party entities as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. - The contract `StakingRewards` interacts with third party contract with `IERC20` interface via `stakingToken`. --- - The contract `StakingRewards` interacts with third party contract with `IERC20` interface via `rewardsToken`. --- - The function `StakingRewards.recoverERC20` interacts with third party contract with `IERC20` interface via `_tokenAddress`.

The return values of the `transfer()` and `transferFrom()` calls in the smart contract are not checked. Some ERC-20 tokens' transfer functions return no values, while others return a bool value, they should be handled with care. If a function returns `false` instead of reverting upon failure, an unchecked failed transfer could be mistakenly considered successful in the contract.