Decentric security record

The function runLottery() is used to make a predetermined amount of winners out of an array of contestants. After performing necessary validation checks, it uses prefetched random numbers from Chainlink VRF to determine whether each individual contestant is a winner of the lottery for the specific tier. In essence, the function performs two important loops:On the first loop iterating through the contestants array, the function calculateResult() is called multiple times for the array's length. This function randomly determines whether the contestant is a winner. The variable numberOfWinnersChosen is incremented every time a winner is selected.On the second loop, the array of contestants is traversed in reverse order from the first loop. This loop only occurs if there were not enough winners selected on the first loop. Instead of calling the function calculateResult() again, contestants are automatically assigned a win if they were not winners yet. This guarantees that the function runLottery() will always yield the necessary amount of winners in order to return successfullyWhile not immediately perceivable, the previous logic introduces two major flaws that hamper the fairness of the lottery process:The result of the call to the function calculateResult() on the first loop is random and is an independent probabilistic event. This means that with an array of contestants of the same size as the number of expected winners, it is only natural that not all contestants will be selected as winners on the first loop. However, on the opposite side, if the array of contestants is very large in comparison to the number of expected winners, only the initial portion of the array will most likely yield winners, since once the expected number of winners is reached, the loop will break. Added to the fact that the addresses of contestants are numerically sorted, contestants with lower addresses will have a higher change of winning than their peers with higher addresses.Circling back to the scenario where the array of contestants is nearly the same size as the number of expected winners, when not enough winners are chosen on the first loop, the second loop will not calculate winners based on randomness. It will simply assign winners to contestants who are not winners yet, and it does so in reverse order. This means that higher addresses are more likely to simply win the lottery where lower addresses had to go through the random lottery process.Essentially, whenever the size of the array of contestants is smaller, more winning probability is given to higher addresses, whereas whenever the size of the array of contestants is bigger, lower addresses have more probability of winning.It should also be noted that, users may somewhat influence their own addresses prior to be assigned as contestants, e.g. keep creating new EOAs or contract addresses to serve their specific purpose as contestants.

The function calculateResult() is a helper function that computes whether an individual contestant should be a winner or a loser on the lottery process. This function uses a random number prefetched from Chainlink VRF and encodes it into a keccak256 hash along with other input parameters. One of these parameters is block.timestamp, which can be manipulated by either, the owner or manager of the protocol that is able to call the runLottery() function whenever he wants, or miners that validate the transaction.Malicious contestants may collude with the owner or manager of the protocol, or miners, to fix the lottery process and indirectly assign themselves as winners.It should also be noted that, while not as easy, other parameters such as index, contestant and IDO_ID may also be indirectly manipulated by malicious actors.

The function payForUserBonus() can be called by users to pay for bonus allocation and further claim the respective allocation in reward tokens. This function allows users to pay on behalf of other users. While this functionality is relevant to support account abstraction mechanisms, it should be implemented with care.The function performs a validation that checks whether the specific user has already paid for allocation, and if they have, it reverts. Since there are maxPayment and minPaymentPercentage variables that limit the input parameter paymentAmount, it is possible for malicious actors to frontrun transactions that call this function and grief legitimate users of paying for their allocation and receive reward tokens.While most of the times, it is expected legitimate users make use of the maxPayment available to get the maximum amount of rewards, malicious users may perform the same transaction first and on their behalf with minimal cost. The impact of this vulnerable scenario directly depends on the cost of the exploit and the relevant variables maxPayment and minPaymentPercentage.

The function calculateClaimAmount() performs vesting calculations on ERC20 tokens and returns the claimable amount to distributor contracts that can be claimed by users. An auto-unlock feature is also implemented that lets users claim tokens before the vesting process, and the amount of tokens that can be claimed at the start is controlled by the variable percentageAvailableForClaim.The function performs a validation that checks if percentageAvailableForClaim is 100% and allows users to claim the auto-unlocked tokens. However, if percentageAvailableForClaim is anything different than 100%, the auto-unlocked tokens cannot be called on the start but only after the cliff period has ended.

The function calculateClaimAmount() implements logic that hinders legitimate users from claiming tokens on a specific scenario. While it allows users to claim auto-unlocked and already vested tokens, in the case where the amount of leftover tokens to claim is less than what was already claimed minus the amount of auto-unlocked tokens, the function call reverts. This is due to calculations over the adjustedClaimed variable that will yield an underflow condition on the return statement of the function.As a Proof of Concept example, suppose:allocation = 100 tokenspercentageAvailableForClaim = 50 %claimed = 75 tokensThen:vesting will be 50 tokensunlocked will be 12.5 tokensadjustedClaimed will be 25 tokensunlocked - adjustedClaimed = -12.5 (Underflow)In order to be able to retrieve the leftover tokens, the user will have to wait for the end of the vesting to claim all tokens, and can no longer claim tokens as the vesting process matures over time.

The function runLottery() does not properly validate duplicate entries on the contestants array. While the array is assumed to be sorted numerically in ascending order, the validation does not check for equality with the previous entry.

The functions updateMinimumPaymentPercentage(), updateMinimumPaymentPercentageForIDO(), updateMinimumBonusPaymentPercentage(), and updateMinimumBonusPaymentPercentageForIDO() do not perform the same validations of the input parameter minimumPaymentPercentage_ as the constructor of the smart contract does, leaving the possibility of undefined behaviour across the protocol, should these variable be set incorrectly.

The function depositFor() is used to perform a lock of ERC20 tokens on behalf of a user that can be unstaked and withdrawn at a later date. While this functionality is relevant to support account abstraction mechanisms, it should be implemented with care.The function also implements two protection mechanisms, the cancelation of the withdrawal request and the reset of the staking duration of the total amount of tokens.Combining the previous two facts about the functionalities of this function, it enables the possibility for malicious actors to frontrun legitimate transactions that call this function and grief users on two possible accounts:Legitimate user stakes tokens. Stake duration has elapsed and legitimate user calls the function requestWithdrawal(). During the cooldown period, a malicious user deposits a minimal amount of tokens using depositFor(), causing the withdraw request to be cancelled. The malicious user may do this multiple times.Legitimate user stakes tokens. Stake duration is almost at the end or in withdraw cooldown period when a malicious user deposits a minimal amount of tokens using depositFor() with a duration equal to maximumStakingDuration, causing the user to have to wait further more to withdraw their tokens. The malicious user may do this multiple times.While most of the times, it is expected legitimate users make use of the minimumStakingDuration to stake the tokens, malicious users may perform the same transaction first and on their behalf with minimal cost. The impact of this vulnerable scenario directly depends on the cost of the exploit and the relevant variables minimumStakeAmount and maximumStakingDuration.

The function payForUserBonus() performs a check that validates whether the provided paymentAmount is at least the minPaymentPercentage allowed. Furthermore, it does not allow the same user to pay for bonus allocation more than once. This effectively means that a user that provides incorrect input parameters by mistake may not rectify and increase their payment, losing on potential bonus rewards.

The variable subscriptionId is not capable of being modified after being initialized in the constructor. Since this variable relates to Chainlink's subscription to request random numbers, if the subscription account is compromised, the protocol may become compromised as well.