Ease

When a user deposits EASE tokens in the GvToken contract, a deposit receipt is added to the _deposits array, which holds one receipt for every deposit that the user has made. When the user decides to withdraw their funds (in whole or partially) they can call the function withdrawRequest, which computes how many of the latest deposits need to be considered to match the withdrawal amount and stores that number N. After a set period of time (e.g. 2 weeks), the user is able to call withdrawFinalize which will transfer to them the deposited amount of EASE tokens that had been requested and will remove the last N deposits from the _deposits array.

The deposit, withdrawRequest and withdrawFinalize functions will operate as expected in isolation. However, let’s consider the following scenario, which consists of the following sequence of actions [deposit -> withdrawRequest -> deposit -> withdrawFinalize] while tracking the state of the GvToken:

• A user makes a deposit of 100 EASE:

• _totalDeposit[user] = 100

• _deposits[user] = [100]

• N = 0

• The user decides to withdraw 10 of those:

• _totalDeposit[user] = 100

• _deposits[user] = [90, 10]

• N = 1

• Before finalizing the withdrawal request (2 weeks delay) they change their mind and decide to deposit another 100:

• _totalDeposit[user] = 200

• _deposits[user] = [90, 10, 100]

• N = 1

• After that they finalize their initial withdrawal request, which pops the last one deposit, expecting it's the 10 EASE:

• _totalDeposit[user] = 190

• _deposits[user] = [90, 10]

• N = 0

After this sequence of actions the user will be able to withdraw at most 100 EASE even though _totalDeposit[user] is 190. This is because if withdrawRequest is called execution will reach function _updateDepositsAndGetPopCount and as the condition totalAmount >= withDrawAmount in the for loop will never be true (totalAmount will be strictly less than withDrawAmount), execution will not break out of the loop. Loop variable i will become 0 at the end of the loop and the last line of the function, index - (i - 1), will cause an underflow. Thus, the user will not be able to ever withdraw their deposit in whole.

There are a few TODOs in different parts of the code. All of them are of minor importance, but still we would advise in favor of resolving them before the final review of all the audits fixes is done by the auditing team.

Below is a list with functions containing TODO items:

• BribePot::bribe
• BribePot::_getBribeUpdates
• GvToken::withdrawFinalize
• GvToken::stake
• GvToken::unstake
• GvToken::setDelay
• TokenSwap::swapVArmor

Not all calls to ERC20 tokens are using the SafeERC20 wrappers. For the EASE token, which extends SolmateERC20, this would not make a difference as SolmateERC20 functions always return true. Nevertheless, it is still advised that SafeERC20 wrappers are used everywhere, as in a future version of the codebase SolmateERC20 might be dropped for a different ERC20 implementation that exhibits different behavior.

Function _update of the BribePot contract calls BribePot::_getBribeUpdates and BribePot::_rewardPerToken to update storage variables lastBribeUpdate, bribePerWeek and lastRewardUpdate and to compute the latest reward per token . After that BribePot::earned is called, which again calls BribePot::_getBribeUpdates and BribePot::_rewardPerToken to get the per token reward in order to compute the amount of EASE token earned for bribing gvEASE .

function earned(address account) public view returns (uint256) {
    (
        uint256 additionalRewardPerToken,
        uint256 currBribePerWeek,

    ) = _getBribeUpdates();
    uint256 currRewardPerToken = _rewardPerToken(
        additionalRewardPerToken,
        currBribePerWeek
    );
    return
        ((_balances[account] *
            (currRewardPerToken - (userRewardPerTokenPaid[account]))) /
            (MULTIPLIER)) + rewards[account];
}

The second call to BribePot::_getBribeUpdates and BribePot::_rewardPerToken are unnecessary. Creating a stripped version of earned, _earned, and calling that at the end of _update would result in gas savings.

function _earned(
    address account,
    uint256 rewardPerToken
) private view returns (uint256) {
    return
        ((_balances[account] *
            (rewardPerToken - (userRewardPerTokenPaid[account]))) /
            (MULTIPLIER)) + rewards[account];
}

Functions withdraw and getReward of the BribePot contract are defined as public even though they are not called by any BribePot function and thus could be made external.

Function GvToken::_deposit should disallow deposits when the total deposited amount is 0, i.e., parameters amount and rewardAmount are both 0. Otherwise, a user will unnecessarily spend funds in gas when depositing 0 EASE by mistake and will also make their future interactions with the contract more expensive for no reason as they will be adding a zero value deposit in the _deposits array.

Storage variables GvToken::gov and BribePot::gvToken can be made immutable.

There are a couple incorrect comments:

• Comment about the GvToken::_stakes storage variable

  /// user => rcaVault => % of gvEASE
  /// Dedaub: rcaVault => user => % of gvEASE
  mapping(address => mapping(address => uint256)) private _stakes;
  

• Comment in GvToken::_updateDepositsAndGetPopCount

  // If there is a remainder we need to update the index at which
  // we broke out of loop and push the withdrawan amount to user
  // _deposits withdraw 100 ease from [75, 30] EASE balance becomes
  // [5, 70, 75]
  // Dedaub: [5, 30, 70]
  if (remainder.amount != 0) {
      Deposit memory lastDepositWithdrawan = _deposits[user][i - 1];
      lastDepositWithdrawan.amount -= remainder.amount;
      _deposits[user][i - 1] = remainder;
      _deposits[user].push(lastDepositWithdrawan);
  }
  

Address 0xdEaD used in TokenSwap can be defined as a contract constant.

The floating version pragma solidity ^0.8.11 allows contracts to be compiled with any version of the Solidity compiler ranging from 0.8.11 to 0.9.0. Even though versions might not differ drastically, floating pragmas should be avoided and the pragma should be fixed to the version that will be used for the contracts’ deployment.

The contracts can be compiled with any version of the Solidity compiler ranging from 0.8.11 to 0.9.0, which, at the time of writing, have some known bugs. We inspected the bugs listed for this version and concluded that the subject code is unaffected.