Epoch Island - vEPOCH Token

When calling `withdrawForfeit()`, the rewards that need to be paid back to the contract is calculated as follows: ``` uint256 forfeitReward = ((earned[_depositId] + rewardTokensClaimed[_depositId]) * percentage) / 1e18; ``` However, the `rewardTokensClaimed` is never updated after the payback. Thus, when users don't withdraw 100 percent of their deposit, they will repay more rewards than they are obligated to with the following withdrawals. Furthermore, the user won't be able to unlock the entire deposit unless they buy `rewardToken` to pay back.

An attacker may be able to reduce the rewards received by other users without any penalty, only incurring gas costs. Such an attack is possible whenever `forfeitRedirectionAddress != address(0)`. The described exploit scenario will lead to the fact that current deposits will receive fewer reward shares. In case the attacker has control over `forfeitRedirectionAddress`, they will be able to claim those rewards without any deposits being locked.

The [Checks-Effects-Interactions](https://solidity.readthedocs.io/en/latest/security-considerations.html#use-the-checks-effects-interactions-pattern) coding pattern is meant to mitigate any chance of other contracts manipulating the state of the blockchain in unexpected and possibly malicious ways before control is returned to the original contract. As the name implied, only after checking whether appropriate conditions are met and acting internally on those conditions should any external calls to, or interactions with, other contracts be done. The following functions are violating the "Checks-Effects-Interactions"-pattern and/or do not employ any reentrancy mitigating modifers, making them susceptible to reentrancy: 1. `Vepoch.addRewardTokens()`. 1. `Vepoch.claimYield()`. 1. `Vepoch.deposit()`. 1. `Vepoch.withdrawForfeit()`. 1. `Vepoch.withdraw()`.

Every Solidity file specifies in the header a version number of the format `pragma solidity (^)0.8.*`. The caret (`^`) before the version number implies an unlocked pragma, meaning that the compiler will use the specified version _and above_, hence the term "unlocked".