Part 2
Zaros
PerpetualsDEXFoundrySolidity
70,000 USDC
View results
Previous Next
Submission Details
Severity: high
Invalid

Users are Unable to Cancel Withdrawal Requests Leading to Indefinitely Locked Funds

rampage

Summary

The redeem() function in VaultRouterBranch.sol lacks a withdrawal cancellation mechanism, potentially leading to indefinitely locked funds when redemptions fail due to insufficient assets or credit capacity. Users cannot recover their shares once a withdrawal request is initiated, creating a significant risk if redemption conditions cannot be met.

Links to affected code

  • VaultRouterBranch.sol:L433~570

Vulnerability details

Finding description and impact

In the VaultRouterBranch.sol#redeem() function, users can face situations where their withdrawal requests become permanently locked, without any mechanism to cancel them. This occurs in two specific scenarios:

  1. When the redeemed assets amount falls below the minAssets threshold

  2. When there is insufficient unlocked credit capacity in the vault

In both cases, the transaction will revert, but the withdrawal request remains active in the system. Since there's no cancellation mechanism implemented, users' shares remain frozen indefinitely within the protocol if these conditions persist.

The function includes critical checks:

function redeem(uint128 vaultId, uint128 withdrawalRequestId, uint256 minAssets) external {
// fetch storage slot for vault by id
Vault.Data storage vault = Vault.loadLive(vaultId);
​
// load storage slot for previously created withdrawal request
WithdrawalRequest.Data storage withdrawalRequest =
WithdrawalRequest.loadExisting(vaultId, msg.sender, withdrawalRequestId);
​
// revert if withdrawal request already fulfilled
if (withdrawalRequest.fulfilled) revert Errors.WithdrawalRequestAlreadyFulfilled();
​
// revert if withdrawal request delay not yet passed
if (withdrawalRequest.timestamp + vault.withdrawalDelay > block.timestamp) {
revert Errors.WithdrawDelayNotPassed();
}
​
// prepare the `Vault::recalculateVaultsCreditCapacity` call
uint256[] memory vaultsIds = new uint256[](1);
vaultsIds[0] = uint256(vaultId);
​
// updates the vault's credit capacity before redeeming
Vault.recalculateVaultsCreditCapacity(vaultsIds);
​
// define context struct, get withdraw shares and associated assets
RedeemContext memory ctx;
ctx.shares = withdrawalRequest.shares;
ctx.expectedAssetsX18 = getIndexTokenSwapRate(vaultId, ctx.shares, false);
​
// load the mm engine configuration from storage
MarketMakingEngineConfiguration.Data storage marketMakingEngineConfiguration =
MarketMakingEngineConfiguration.load();
​
// cache vault's redeem fee
ctx.redeemFee = vault.redeemFee;
​
// get assets minus redeem fee
ctx.expectedAssetsMinusRedeemFeeX18 =
ctx.expectedAssetsX18.sub(ctx.expectedAssetsX18.mul(ud60x18(ctx.redeemFee)));
​
// calculate assets minus redeem fee as shares
ctx.sharesMinusRedeemFeesX18 =
getVaultAssetSwapRate(vaultId, ctx.expectedAssetsMinusRedeemFeeX18.intoUint256(), false);
​
// get the shares to send to the vault deposit and redeem fee recipient
ctx.sharesFees = ctx.shares - ctx.sharesMinusRedeemFeesX18.intoUint256();
​
// cache the vault's credit capacity before redeeming
ctx.creditCapacityBeforeRedeemUsdX18 = vault.getTotalCreditCapacityUsd();
​
// cache the locked credit capacity before redeeming
ctx.lockedCreditCapacityBeforeRedeemUsdX18 = vault.getLockedCreditCapacityUsd();
​
// redeem shares previously transferred to the contract at `initiateWithdrawal` and store the returned assets
address indexToken = vault.indexToken;
uint256 assets =
IERC4626(indexToken).redeem(ctx.sharesMinusRedeemFeesX18.intoUint256(), msg.sender, address(this));
​
// get the redeem fee
if (ctx.sharesFees > 0) {
IERC4626(indexToken).redeem(
ctx.sharesFees, marketMakingEngineConfiguration.vaultDepositAndRedeemFeeRecipient, address(this)
);
}
​
// require at least min assets amount returned
-> if (assets < minAssets) revert Errors.SlippageCheckFailed(minAssets, assets);
​
// invariant: received assets must be > 0 even when minAssets = 0
if (assets == 0) revert Errors.RedeemMustReceiveAssets();
​
// if the credit capacity delta is greater than the locked credit capacity before the state transition, revert
if (
-> ctx.creditCapacityBeforeRedeemUsdX18.sub(vault.getTotalCreditCapacityUsd()).lte(
-> ctx.lockedCreditCapacityBeforeRedeemUsdX18.intoSD59x18()
)
) {
revert Errors.NotEnoughUnlockedCreditCapacity();
}
​
// set withdrawal request to fulfilled
withdrawalRequest.fulfilled = true;
​
// emit an event
emit LogRedeem(vaultId, msg.sender, ctx.sharesMinusRedeemFeesX18.intoUint256());
}

Risk Assessment

The absence of a withdrawal cancellation mechanism presents a significant risk to users as their funds could become permanently locked in the protocol if market conditions or vault parameters prevent successful redemption.

Recommended mitigation steps

Implement a cancelWithdrawalRequest function in VaultRouterBranch.sol that allows users to cancel their pending withdrawal requests and retrieve their shares. The function should:

  1. Verify the withdrawal request exists and belongs to the caller

  2. Ensure the request hasn't been fulfilled

  3. Return the locked shares to the user

  4. Mark the request as cancelled or remove it from storage

Updates

Lead Judging Commences

inallhonesty Lead Judge
5 months ago
inallhonesty Lead Judge 4 months ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.