Epoch Island security record

The protocol's current architecture does not account for the unique behaviors of various specialized ERC20 tokens, including interest-bearing, deflationary, and rebasing tokens. These tokens are characterized by their dynamic balance mechanisms, where the token balance can autonomously change over time due to factors like transaction fees, re-distribution, or balance adjustments. This aspect contradicts the protocol's underlying assumption of static token balances, potentially leading to inaccurate calculations or unintended interactions within the contract. Additionally, the protocol's open design, which allows liquidity providers (LPs) to utilize any ERC20 token, poses a significant risk. This unrestricted approach could enable LPs to introduce malicious tokens, crafted specifically to exploit the contract's mechanics or defraud takers. Such tokens might be engineered to perform a rug-pull – abruptly devaluing or making the tokens non-transferable after a transaction – or to otherwise deceive and manipulate the takers. This vulnerability necessitates a more stringent approach to token vetting and validation within the contract, to safeguard against these deceptive strategies and ensure the integrity of transactions.

Whenever a `rewardToken` or `depositToken` is transferred, they may fail without reverting. Depending on the context, this may lead to inconsistencies, users losing funds, or the contract losing funds. The reason is that calls to `transfer()` and `transferFrom()` are not checked for returning true. While many ERC20s will revert upon transfer failure, some ERC20s will return false in adherence to the ERC20 specification. If `rewardToken` or `depositToken` will return false on failure the transfer will silently fail. The return value is not checked in the following places: 1. `Vepoch.sol#L78`. 1. `Vepoch.sol#L108`. 1. `Vepoch.sol#L130`. 1. `Vepoch.sol#L146`. 1. `Vepoch.sol#L192`. 1. `Vepoch.sol#L210`. 1. `Vepoch.sol#L215`. 1. `Vepoch.sol#L234`. 1. `Vepoch.sol#L252`.

The owner of the contracts can call `transferOwnership()` to transfer the ownership to a new address. If an uncontrollable address is accidentally provided as the new owner address, then the contract will no longer have an active owner, and functions with the `onlyOwner` modifier can no longer be executed.

Two values were hard-coded into the code and, therefore, limited the flexibility: 1. The maximum LP fee that can ever be set is hard-coded into `supply()`. 1. The maximum protocol fee is hard-coded in `setProtocolFee()`.

It is important to validate inputs, even if they only come from trusted addresses, to avoid human error. The following functions do not have a proper validation of input parameters: 1. `EpochUpsidePoolV1.supply()`: 1. `_exchangeRate` not checked to be non-zero. Clarify if this is intended. 1. `_startDate` and `_endDate` not checked to be non-zero. 1. `_startDate` and `_endDate` not checked to be chronological. 1. `_startDate` and `_endDate` not checked to have a reasonable lower bound difference between each other. 1. `_feeBp` not checked to be non-zero. Clarify if this is intended. 1. `EpochUpsidePoolV1.setProtocolFee()`: 1. `_protocolFeeRecipientAddress` not checked to be different from `addresss(0x0)`. 1. `_protocolFeeMaxBp` not checked to be non-zero. Clarify if this is intended. 1. `EpochUpsidePoolV1.claimPositionFees()`: `_tokenAddresses` not checked to be the same length as `_tokenAmounts`.

If the owner renounces their ownership, all ownable contracts will be left without an owner. Consequently, any function guarded by the `onlyOwner` modifier will no longer be able to be executed.

Certain contracts have state variables, e.g., `owner`, which provide specific addresses with privileged roles. Such roles may pose a risk to end-users. For a detailed list of roles per contract, see the following list: The `EpochUpsidePoolV1.sol` contract contains the following privileged roles: 1. `_owner` (`Ownable` inheritance), as initialized during the execution of `constructor` to `msg.sender`: 1. Renounce the role (**and thereby prevent any future calls to the following listed functions!**) by calling `renounceOwnership()`. 1. Transfer the ownership to an arbitrary other address by calling `transferOwnership()`. 1. Change the protocol fee (up until `7001`, 7,001%) and fee receiver address by calling `setProtocolFee()`. A malicious or compromised owner could, in a worst-case scenario, unexpectedly change the protocol fee from zero to up to 7.001%.

The `deposits` mapping will begin at index one upon first `deposit()` call, leaving the zero'th index empty. This is because `depositCount` is incremented before setting the next `deposits` value. Particularly, if `deposits` is changed to an array for gas efficiency reasons, it is recommended to commence at index zero.

The `owner` may (accidentally) prevent further user deposits by setting `maxDepositDuration < 60`. This would lead to `deposit()` always reverting as `_duration > 59` and `_duration <= maxDepositDuration` cannot hold true at the same time for `maxDepositDuration < 60`. The root issue is that `setMaxDepositDuration()` does not enforce a lower bound on `maxDepositDuration`. Furthermore, the `owner` can (accidentally) set a too-low `maxDepositDuration` and lock that value forever by calling `setMaxDepositDurationLocked()`. This would lock out any future calls to `setMaxDepositDuration()` to undo such a setting

In order to validate the proper deployment and initialization of the contracts, it is a good practice to emit events. Also, any important state transition can be logged, which is beneficial for monitoring the contract, and also tracking eventual bugs, or hacks. Below we present a non-exhaustive list of events that could be emitted to improve the application management: 1. `Vepoch.addRewardTokens()`: `rewardIndex`. 1. `Vepoch._updateRewards()`: `earned[]` and `rewardIndexOf[]`. 1. `Vepoch.setAuthorisedLocked()`: `authorisedLocked`. 1. `Vepoch.setMaxDepositDurationLocked()`: `maxDepositDurationLocked`. 1. `Vepoch.setForfeitRedirectionAddressLocked()`: `forfeitRedirectionAddressLocked`. 1. `Vepoch.setForfeitRedirection()`: `forfeitRedirectionAddress`.