Vaulty - Goal vault and Time Vault

To be qualified to earn rewards as a user, a vault must meet some requirement they get from the portion of the reward pool. Of course, the user calling the vault of which to claim reward must be the owner, other requirements are that users must have some tokens in the vault, must not have claimed the rewards before, and that the creation time for the vault must be lesser than the timestamps allotted for the rewards. The issue arises when users call the withdraw function first before calling the claimRewards function. This is because at the point of claiming rewards, users amount will already be made to zero, denying them the right to claim rewards even though they met other requirements before calling the withdraw function.

With the use of modifiers on some functions restrict the privilege of who can call them. This gives us the certainty of some functions reverting when called by users not allowed to call this function, it is recommended to mark these functions as payable as this will save gas when they are called by privileged addresses.

Vaults are designed to be associated with owners and the system allows for these vaults to be transferred between different addresses. However, for vaults to be transferred, they are expected to have a non-zero balance. In the transferVault function, the check is otherwise; expecting that a vault must be zero balance before it can be transferred.

Some ERC20 tokens are designed to revert when called transferring zero values. There are some tokens that exempt this check and when they get whitelisted, it is possible for the contract owner to call the withdrawPenaltyFee function for these tokens and this won’t revert, causing a wastage of gas after the call.

For gas optimization purposes, there are some unsigned comparisons made in both contracts to ensure that a function is greater than zero.  This is recommended to use a check that ensures that a value is a non-zero value to save some gas rather than it being exactly greater than zero.