Ethena Labs - pipidu83's results

Lines of code

https://github.com/code-423n4/2023-10-ethena/blob/main/contracts/StakedUSDeV2.sol#L42-L45

Vulnerability details

Impact

Users could have to face a cooldown period of MAX_COOLDOWN_DURATION i.e. 90 days if they attempt to set assets or shares into cooldown before the DEFAULT_ADMIN_ROLE sets the cooldownDuration to 14 days using setCooldownDuration

  function setCooldownDuration(uint24 duration) external onlyRole(DEFAULT_ADMIN_ROLE) {
    if (duration > MAX_COOLDOWN_DURATION) {
      revert InvalidCooldown();
    }

    uint24 previousDuration = cooldownDuration;
    cooldownDuration = duration;
    emit CooldownDurationUpdated(previousDuration, cooldownDuration);
  }

This is at odds with the documentation

" Q: Why is there a cooldown period during launch? During the closed initial launch, there is a 14-day cooldown from requesting to unstake sUSDe to receiving USDe in return. Users must first request their USDe be unstaked wherein their USDe will be placed in a USDeSilo smart contract. Once the cooldown period has elapsed, users will be able to withdraw their USDe from the USDeSilo smart contract. "

and would mean users' assets are held in cooldown longer than necessary, potentially leading to loss of reputation / disengagement from users.

Proof of Concept

In cooldownAssets and cooldownShares, the cooldowns[owner].cooldownEnd variable is set to uint104(block.timestamp) + cooldownDuration

  function cooldownAssets(uint256 assets, address owner) external ensureCooldownOn returns (uint256) {
    if (assets > maxWithdraw(owner)) revert ExcessiveWithdrawAmount();

    uint256 shares = previewWithdraw(assets);

    cooldowns[owner].cooldownEnd = uint104(block.timestamp) + cooldownDuration;
    cooldowns[owner].underlyingAmount += assets;

    _withdraw(_msgSender(), address(silo), owner, assets, shares);

    return shares;
  }

  function cooldownShares(uint256 shares, address owner) external ensureCooldownOn returns (uint256) {
    if (shares > maxRedeem(owner)) revert ExcessiveRedeemAmount();

    uint256 assets = previewRedeem(shares);

    cooldowns[owner].cooldownEnd = uint104(block.timestamp) + cooldownDuration;
    cooldowns[owner].underlyingAmount += assets;

    _withdraw(_msgSender(), address(silo), owner, assets, shares);

    return assets;
  }

That means users can unstake only after block.timestamp >= uint104(block.timestamp_initial) + cooldownDuration as per function definition

  function unstake(address receiver) external {
    UserCooldown storage userCooldown = cooldowns[msg.sender];
    uint256 assets = userCooldown.underlyingAmount;

    if (block.timestamp >= userCooldown.cooldownEnd) {
      userCooldown.cooldownEnd = 0;
      userCooldown.underlyingAmount = 0;

      silo.withdraw(receiver, assets);
    } else {
      revert InvalidCooldown();
    }
  }

meaning that if user calls cooldownAssets or cooldownShares before the cooldownDuration is set to 14 days, he is going to have to wait for at least 14 days plus the time difference between the second and first call to cooldownAssets or cooldownShares to unstake ANY amount of shares or assets (this is linked to another vulnerability submitted as HIGH detailing the fact that calling cooldownAssets or cooldownShares more than once will effectively reset the cooldown period of ALL assets or shares to the cooldownDuration at the time of the second call).

Tools Used

Visual Studio / Manual Review

Recommended Mitigation Steps

Set cooldownDuration = 14 days in StakedUSDeV2's constructor.

Assessed type

Other