EGO

The `_computeReleasableAmount` function is called by `claim` function and is responsible for calculating the tokens that will be sent to the user. If the user claims the token after the vesting end time, the function will return less than the total number of claimable tokens defined in the variable `totalAmountOfUser`. The calculation should not exclude the "startAmount" after the vesting schedule ends. Due to the error, users will not be able to claim the full reward amount after the vesting period ends. ```solidity if (currentTime < vestingStartTime) { return 0; } else if (currentTime >= vestingEndTime) { return totalAmountOfUser .mul((100 - startVestingPercentage)) .div(100) .sub(userAddressToAmountClaimed[_account]); } else { ... } ```

The "setStakingRules" function can be used to modify the reward token and record release configuration. It is generally a best practice to call the "update" function to update relevant reward state variables before updating the contract reward configuration. This can ensure that the reward before the change was properly calculated with old configurations.

The code comment for the `getViewData` function states that 'With this function user can see information...'; however, the function is protected with the `onlyRole(ADMIN_ROLE)` modifier, which restricts access to only the admin. The function should not have such an access restriction. ```sol=176 /** * @notice With this function user can see information about contract, including tokens addresses, amount of reward tokens, that will be paid to all of user in some epoch, duration of epoch and the minimum period of time for which the reward is received. * @return viewData - structure with information about contract. */ function getViewData() external view onlyRole(ADMIN_ROLE) returns (ViewData memory viewData) ```

The first parameter of the "FalseSender" event should be "sourceChain," but the code uses "sourceAddress," which is an incorrect event parameter. ```sol=70 event FalseSender(string sourceChain, string sourceAddress); ``` ```sol=263 emit FalseSender(sourceAddress, sourceAddress); ```

The code check if the msg.sender claimed the "StartAmount"; if not, the calculation will perform the ".sub(userAddressToAmountClaimed[_account])" in the calculation. ```sol=178 if (!isStartAmountClaimed[msg.sender]) { vestedAmount = vestedAmount.add(startAmount).sub( userAddressToAmountClaimed[_account] ); ``` However, based on the code logic in the "claim" function, the value of "isStartAmountClaimed" will be set to true only if "userAddressToAmountClaimed" is not equal to zero. On the contrary, if the "isStartAmountClaimed[address]" is not equal to true, the "isStartAmountClaimed[address]" will always equal zero, making the ".sub(userAddressToAmountClaimed[_account])" meaningless. ```sol=103 userAddressToAmountClaimed[msg.sender] += _amount; isStartAmountClaimed[msg.sender] = true; ```

Some functions place the role check and `require` check at the end of the function call, which wastes gas for the previous code execution if the transaction reverts. ```sol=190 require( trustedRemotes[destinationChain], "Chain does not supported" ); ``` ```sol=307 _checkRole(BRIDGE_MASTER_ROLE, to); require( maxSupply >= totalSupply() + amount, "Total supply of token reached" ); ```

The return value of the transfer()/transferFrom() call is not checked. ```solidity=133 IERC20(_token).transfer(_receiver, _amount); ```