Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The `PerpDepository` class's `getPositionValue` function calculates the unrealized PNL by querying t. The `PerpDepository` class's `getPositionValue` function calculates the unrealized PNL by querying the exchange for the mark price, which is defined as the time-weighted average price (TWAP) over a 15-minute interval. However, the function incorrectly uses a 15-second TWAP instead of the intended 15...

Vulnerable code:
```\nfunction getPositionValue() public view returns (uint256) {\n    uint256 markPrice = getMarkPriceTwap(15);\n    int256 positionSize = IAccountBalance(clearingHouse.getAccountBalance())\n       .getTakerPositionSize(address(this), market);\n    return markPrice * _abs(positionSize);\n}\n\nfunction getMarkPriceTwap(uint32 twapInterval)\n    public\n    view\n    returns (uint256)\n{\n    IExchange exchange = IExchange(clearingHouse.getExchange());\n    uint256 markPrice = exchange.getSqrtMarkTwapX96(market, twapInterval)\n       .formatSqrtPriceX96ToPriceX96()\n       .formatX96ToX10_18();\n    return markPrice;\n}\n```
MEDIUM severity: The vulnerability "Contracts Not Well Designed for Upgrades" is characterized by inconsistent storag. The vulnerability "Contracts Not Well Designed for Upgrades" is characterized by inconsistent storage layout and initialization practices in the contracts. Specifically, the contracts introduce buffer space in the storage layout to accommodate potential upgrades, but the buffer space is not consiste...

Vulnerable code:
```\nuint256[10] private _gap;\n```\n```\nuint256[10] private _gap;\n```\n```\nuint256[10] private _base_gap;\n```\n```\nuint256[50] private _gap_L2MessageService;\n```\n```\nfunction __RateLimiter_init(uint256 _periodInSeconds, uint256 _limitInWei) internal {\n    // Initialize the rate limiter\n    _period = _periodInSeconds;\n    _limit = _limitInWei;\n    _lastReset = block.timestamp;\n}\n```\n```\nfunction _init_MessageServiceBase(address _messageService, address _remoteSender) internal {\n    // Initialize the message service\n    _messageService = _messageService;\n    _remoteSender = _remoteSender;\n}\n```
MEDIUM severity: The code relies on several assumptions about the Aave and Compound integrations, which may not alway. The code relies on several assumptions about the Aave and Compound integrations, which may not always hold true. A malicious or malfunctioning integration (or lending pool) could potentially violate these assumptions, leading to unintended behavior in the system.\n\nThe first assumption is that the...

Vulnerable code:
```\nIPlatformIntegration(_integration).checkBalance(_bAsset)\n```\n```\nIPlatformIntegration(_integrators[i]).withdraw(_recipient, bAsset, q, _bAssets[i].isTransferFeeCharged)\n```\n```\nrequire(bAssetToPToken[_bAsset] == address(0), "pToken already set");\n```
MEDIUM severity: The vulnerability arises in the implementation of a share-based vault, specifically in the ERC4626 s. The vulnerability arises in the implementation of a share-based vault, specifically in the ERC4626 standard, where the shares are calculated based on the deposit value. The issue allows the initial depositor to manipulate the price per share value, subsequently forcing future depositors to deposit a...

Vulnerable code:
```\nfunction _mint(address receiver, uint256 shares) internal {\n    // Need to transfer before minting or ERC777s could reenter.\n    asset.safeTransferFrom(msg.sender, address(this), shares);\n\n    _mint(receiver, shares);\n\n    emit Deposit(msg.sender, receiver, assets, shares);\n\n    afterDeposit(assets, shares);\n}\n\nfunction previewMint(uint256 shares) public view virtual returns (uint256) {\n    uint256 supply = totalSupply; // Saves an extra SLOAD if totalSupply is non-zero.\n\n    return supply == 0? shares : shares.mulDivUp(totalAssets(), supply);\n}\n```
MEDIUM severity: The `Goldilend.liquidate()` function may revert due to an underflow issue in the `repay()` function'. The `Goldilend.liquidate()` function may revert due to an underflow issue in the `repay()` function's interest calculation. This vulnerability arises from the use of the `FixedPointMathLib.divWad()` function, which performs a rounding operation on the interest calculation. Specifically, when the `re...

Vulnerable code:
```\nfunction repay(uint256 repayAmount, uint256 _userLoanId) external {\n    Loan memory userLoan = loans[msg.sender][_userLoanId];\n    if (userLoan.borrowedAmount < repayAmount) {\n        revert ExcessiveRepay();\n    }\n    if (block.timestamp > userLoan.endDate) {\n        revert LoanExpired();\n    }\n    uint256 interestLoanRatio = FixedPointMathLib.divWad(userLoan.interest, userLoan.borrowedAmount);\n    uint256 interest = FixedPointMathLib.mulWadUp(repayAmount, interestLoanRatio);\n    outstandingDebt -= repayAmount - interest > outstandingDebt? outstandingDebt : repayAmount - interest;\n    // rest of code\n}\n\nfunction liquidate(address user, uint256 _userLoanId) external {\n    Loan memory userLoan = loans[msg.sender][_userLoanId];\n    if (block.timestamp < userLoan.endDate || userLoan.liquidated || userLoan.borrowedAmount == 0) {\n        revert Unliquidatable();\n    }\n    loans[user][_userLoanId].liquidated = true;\n    loans[user][_userLoanId].borrowedAmount = 0;\n    outstandingDebt -= userLoan.borrowedAmount - userLoan.interest;\n    // rest of code\n}\n```
MEDIUM severity: The vulnerability lies in the fact that the DAO proposals do not require a minimum participation quo. The vulnerability lies in the fact that the DAO proposals do not require a minimum participation quorum. This means that even if the DAO falls below the minimum viable membership threshold, voting for proposals can still continue. In the worst-case scenario, this could allow the last remaining DAO m...

Vulnerable code:
```\nrequire(_votesRequired > 0, "Proposal cannot have a 0 votes required to be successful");\n```\n```\nfunction propose(string memory _proposalMessage, bytes memory _payload) override public onlyTrustedNode(msg.sender) onlyLatestContract("rocketDAONodeTrustedProposals", address(this)) returns (uint256) {\n    RocketDAOProposalInterface daoProposal = RocketDAOProposalInterface(getContractAddress('rocketDAOProposal'));\n    RocketDAONodeTrustedInterface daoNodeTrusted = RocketDAONodeTrustedInterface(getContractAddress('rocketDAONodeTrusted'));\n    RocketDAONodeTrustedSettingsProposalsInterface rocketDAONodeTrustedSettingsProposals = \n        RocketDAONodeTrustedSettingsProposalsInterface(getContractAddress("rocketDAONodeTrustedSettingsProposals"));\n\n    require(daoNodeTrusted.getMemberLastProposalBlock(msg.sender).add(rocketDAONodeTrustedSettingsProposals.getCooldown()) <= block.number, \n        "Member has not waited long enough to make another proposal");\n\n    setUint(keccak256(abi.encodePacked(daoNameSpace, "member.proposal.lastblock", msg.sender)), block.number);\n\n    return daoProposal.add(msg.sender, 'rocketDAONodeTrustedProposals', _proposalMessage, \n        block.number.add(rocketDAONodeTrustedSettingsProposals.getVoteDelayBlocks()), \n        rocketDAONodeTrustedSettingsProposals.getVoteBlocks(), \n        rocketDAONodeTrustedSettingsProposals.getExecuteBlocks(), \n        daoNodeTrusted.getMemberQuorumVotesRequired(), _payload);\n}\n```
MEDIUM severity: The AutoRoller.sol contract's `previewWithdraw` function does not adhere to the ERC-4626 standard's . The AutoRoller.sol contract's `previewWithdraw` function does not adhere to the ERC-4626 standard's rounding requirements. Specifically, it does not round up when calculating the next guess for the preview withdrawal amount. This is in contrast to the standard's recommendation to round up when calcu...

Vulnerable code:
```\nfunction previewWithdraw(uint256 assets) public view virtual returns (uint256) {\n    uint256 supply = totalSupply; // Saves an extra SLOAD if totalSupply is non-zero.\n\n    return supply == 0? assets : assets.mulDivUp(supply, totalAssets());\n}\n```\n```\nfor (uint256 i = 0; i < 20; ) {\n    if (guess > supply) {\n        guess = supply;\n    }\n\n    int256 answer = previewRedeem(guess.safeCastToUint()).safeCastToInt() - assets.safeCastToInt();\n\n    if (answer >= 0 && answer <= assets.mulWadDown(0.001e18).safeCastToInt() || (prevAnswer == answer)) {\n        break;\n    }\n\n    if (guess == supply && answer < 0) {\n        revert InsufficientLiquidity();\n    }\n\n    int256 nextGuess = guess - (answer * (guess - prevGuess) / (answer - prevAnswer));\n    prevGuess = guess;\n    prevAnswer = answer;\n    guess = nextGuess;\n\n    unchecked {\n        ++i;\n    }\n}\n\nreturn guess.safeCastToUint() + maxError;\n```\n```\nint256 answer = previewRedeem(guess.safeCastToUint()).safeCastToInt() - assets.safeCastToInt();\n```\n```\nint nextGuess = guess - (answer * (guess - prevGuess) / (answer - prevAnswer));\nprevGuess = guess;\nprevAnswer = answer;\nguess = nextGuess;\n```\n```\nreturn guess.safeCastToUint() + maxError;\n```\n```\nint nextGuess = guess - (answer * (guess - prevGuess) / (answer - prevAnswer));\n```
MEDIUM severity: The `BMIDAIStaking` contract assumes that the price of DAI and DAIx are equivalent, which can lead t. The `BMIDAIStaking` contract assumes that the price of DAI and DAIx are equivalent, which can lead to unintended consequences. When a liquidity provider stakes tokens to the `BMIDAIStaking` contract, the equal amount of DAI and DAIx are transferred from the pool contract. This assumption can result...

Vulnerable code:
```\nfunction _stakeDAIx(address _user, uint256 _amount, address _policyBookAddr) internal {\n    require(_amount > 0, "BMIDAIStaking: Can't stake zero tokens");\n\n    PolicyBook _policyBook = PolicyBook(_policyBookAddr);\n    // transfer DAI from PolicyBook to yield generator\n    daiToken.transferFrom(_policyBookAddr, address(defiYieldGenerator), _amount);\n\n    // transfer bmiDAIx from user to staking\n    _policyBook.transferFrom(_user, address(this), _amount);\n\n    _mintNFT(_user, _amount, _policyBook);\n}\n```
MEDIUM severity: The vulnerability allows a malicious user to bypass the `takerInvariant` modifier, which is designed. The vulnerability allows a malicious user to bypass the `takerInvariant` modifier, which is designed to prevent a maker from closing their position if it would result in the global maker open positions falling below the global taker open positions. This is achieved by liquidating their own account,...

Vulnerable code:
```\nfunction closeMakeFor(\n    address account,\n    UFixed18 amount\n) \n    public \n    nonReentrant \n    notPaused \n    onlyAccountOrMultiInvoker(account) \n    settleForAccount(account) \n    takerInvariant \n    closeInvariant(account) \n    liquidationInvariant(account)\n{\n    _closeMake(account, amount);\n}\n```\n```\nfunction closeAll(address account) external onlyCollateral notClosed settleForAccount(account) {\n    AccountPosition storage accountPosition = _positions[account];\n    Position memory p = accountPosition.position.next(_positions[account].pre);\n\n    // Close all positions\n    _closeMake(account, p.maker);\n    _closeTake(account, p.taker);\n\n    accountPosition.liquidation = true;\n}\n```
MEDIUM severity: The vulnerability lies in the implementation of cross-chain messaging in the `Game` and `MainVault` . The vulnerability lies in the implementation of cross-chain messaging in the `Game` and `MainVault` contracts, which utilizes Connext's `xcall()` function. Specifically, certain functions that route messages across chains are currently unprotected, allowing anyone to execute them under specific cond...

Vulnerable code:
```\nuint256 relayerFee = _relayerFee!= 0? _relayerFee : msg.value;\nIConnext(connext).xcall(\n    value: relayerFee,\n    _destinationDomain, // _destination: Domain ID of the destination chain\n    target, // _to: address of the target contract\n    address(0), // _asset: use address zero for 0-value transfers\n    msg.sender, // _delegate: address that can revert or forceLocal on destination\n    0, // _amount: 0 because no funds are being transferred\n    0, // _slippage: can be anything between 0-10000 because no funds are being transferred\n    _callData // _callData: the encoded calldata to send\n);\n```\n```\ndef IConnext(connext).xcall(\n    value=msg.value - _relayerFee,\n    _destinationDomain=_destinationDomain,  # _destination: Domain ID of the destination chain\n    _recipient=_recipient,  # _to: address receiving the funds on the destination\n    _token=_token,  # _asset: address of the token contract\n    _delegate=msg.sender,  # _delegate: address that can revert or forceLocal on destination\n    _amount=_amount,  # _amount: amount of tokens to transfer\n    _slippage=_slippage,  # _slippage: the maximum amount of slippage the user will accept in BPS (e.g. 30 = 0.3%)\n    _callData=bytes("")\n):\n```\n```\nparams.delegate | (optional) Address allowed to cancel an xcall on destination.\n```
MEDIUM severity: The `DataStore` struct, as defined in the provided code, lacks a crucial `_gap` field, which is esse. The `DataStore` struct, as defined in the provided code, lacks a crucial `_gap` field, which is essential for ensuring the upgradability of the contract. This oversight can lead to unintended consequences when attempting to upgrade the contract in the future.\n\nIn Geode contracts, the `_gap` field...

Vulnerable code:
```\nDataStoreUtils.DataStore private DATASTORE;\nGeodeUtils.Universe private GEODE;\nStakeUtils.StakePool private STAKEPOOL;\n```\n```\nstruct DataStore {\n    mapping(uint256 => uint256[]) public allIdsByType;\n    mapping(bytes32 => uint256) public uintData;\n    mapping(bytes32 => bytes) public bytesData;\n    mapping(bytes32 => address) public addressData;\n}\n```
MEDIUM severity: The `depositProfitTokenForUsers()` and `withdrawProfit()` functions in the Vault V3 contract contain. The `depositProfitTokenForUsers()` and `withdrawProfit()` functions in the Vault V3 contract contain a redundant check that can be optimized. Specifically, the code snippet in question checks if the current block timestamp (`block.timestamp`) is less than or equal to the `lastProfitTime` variable. \...

Vulnerable code:
```\nif (block.timestamp <= lastProfitTime) {\n    revert NYProfitTakingVault__ProfitTimeOutOfBounds();\n```
MEDIUM severity: The `LibMathUnsigned` library declares `_UINT256_MAX` as `2^255-1`, which is actually the value of `. The `LibMathUnsigned` library declares `_UINT256_MAX` as `2^255-1`, which is actually the value of `_INT256_MAX`. This appears to be a naming inconsistency, as the variable name suggests it should represent the maximum value of an unsigned 256-bit integer, whereas the actual value represents the max...

Vulnerable code:
```\nlibrary LibMathUnsigned {\n    uint256 private constant _WAD = 10**18;\n    uint256 private constant _UINT256_MAX = 2**255 - 1;\n}\n```
MEDIUM severity: The Ditto rewards earned by shorters are calculated based on the Ditto shorter rate, which is a para. The Ditto rewards earned by shorters are calculated based on the Ditto shorter rate, which is a parameter that can be changed by the admin or the DAO. However, the current implementation does not account for the retroactive impact of changes to this rate on accrued Ditto yield shares. This means tha...

Vulnerable code:
```\n1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n11\n12\n13\n14\n15\n16\n17\n18\n19\n20\n21\n22\n23\n24\n25\n26\n27\n28\n29\n30\n31\n32\n33\n34\n35\n36\n37\n38\n39\n40\n41\n42\n43\n44\n45\n46\n47\n48\n49\n50\n51\n52\n53\n54\n55\n56\n57\n58\n59\n60\n61\n62\n63\n64\n65\n66\n67\n68\n69\n70\n71\n72\n73\n74\n75\n76\n77\n78\n79\n80\n81\n82\n83\n84\n85\n86\n87\n88\n89\n90\n91\n92\n93\n94\n95\n96\n97\n98\n99\n100\n101\n102\n103\n104\n105\n106\n107\n108\n109\n110\n111\n112\n113\n114\n115\n116\n117\n118\n119\n120\n121\n122\n123\n124\n125\nfunction _claimYield(uint256 vault, uint256 yield, uint88 dittoYieldShares) private {\n126     STypes.Vault storage Vault = s.vault[vault];\n127     STypes.VaultUser storage VaultUser = s.vaultUser[vault][msg.sender];\n128     // Implicitly checks for a valid vault\n129     if (yield <= 1) revert Errors.NoYield();\n130     // Credit yield to ethEscrowed\n131     VaultUser.ethEscrowed += yield;\n132     // Ditto rewards earned for all shorters since inception\n133     uint256 protocolTime = LibOrders.getOffsetTime();\n134     uint256 dittoRewardShortersTotal = Vault.dittoShorterRate * protocolTime;\n135     // Ditto reward proportion from this yield distribution\n136     uint256 dittoYieldSharesTotal = Vault.zethCollateralReward;\n137     uint256 dittoReward = dittoYieldShares.mul(dittoRewardShortersTotal).div(dittoYieldSharesTotal);\n138     // Credit ditto reward to user\n139     if (dittoReward > type(uint80).max) revert Errors.InvalidAmount();\n140     VaultUser.dittoReward += uint80(dittoReward);\n141 }\n```\n```\nfunction testYieldRateChange() public {\n    address alice = makeAddr("alice");\n    address bob = makeAddr("bob");\n    address[] memory assets = new address[](1);\n    assets[0] = asset;\n\n    fundLimitBid(DEFAULT_PRICE, 320000 ether, receiver);\n    fundLimitShort(DEFAULT_PRICE, 80000 ether, alice);\n    fundLimitShort(DEFAULT_PRICE, 80000 ether, bob);\n    generateYield();\n    skip(yieldEligibleTime);\n\n    // Alice and Bob have the same number of Ditto yield shares\n    assertEq(diamond.getDittoMatchedReward(vault, alice), diamond.getDittoMatchedReward(vault, bob));\n\n    vm.prank(alice);\n    diamond.distributeYield(assets);\n\n    // Ditto shorter rate is updated\n    vm.prank(owner);\n    diamond.setDittoShorterRate(vault, 2);\n\n    vm.prank(bob);\n    diamond.distributeYield(assets);\n\n    uint256 aliceDittoRewards = diamond.getDittoReward(vault, alice);\n    uint256 bobDittoRewards = diamond.getDittoReward(vault, bob);\n\n    // Bob receives more Ditto rewards than Alice, even both were entitled to the same amount\n    assertApproxEqAbs(aliceDittoRewards * 2, bobDittoRewards, 2);\n}\n```
MEDIUM severity: The `inflationMultiplier` variable in the `L1ECOBridge` contract is updated through the `rebase` fun. The `inflationMultiplier` variable in the `L1ECOBridge` contract is updated through the `rebase` function, which is triggered by an independent transaction on the L1 chain. This value is used to convert between token amounts and `_gonsAmount` in the `_initiateERC20Deposit` and `finalizeERC20Withdraw...

Vulnerable code:
```\nfunction rebase(uint32 _l2Gas) external {\n    inflationMultiplier = IECO(l1Eco).getPastLinearInflation(block.number);\n```\n```\nIECO(_l1Token).transferFrom(_from, address(this), _amount);\n_amount = _amount * inflationMultiplier;\n```\n```\nuint256 _amount = _gonsAmount / inflationMultiplier;\nbytes memory _ecoTransferMessage = abi.encodeWithSelector(IERC20.transfer.selector, _to, _amount);\n```\n```\nfunction rebase(uint256 _inflationMultiplier)\n    external\n    virtual\n    onlyFromCrossDomainAccount(l1TokenBridge)\n    validRebaseMultiplier(_inflationMultiplier)\n{\n    inflationMultiplier = _inflationMultiplier;\n    l2Eco.rebase(_inflationMultiplier);\n    emit RebaseInitiated(_inflationMultiplier);\n}\n```
MEDIUM severity: The vulnerability in the `_computeVariableOpeningFee` function of the Tapioca protocol's `BBLendingC. The vulnerability in the `_computeVariableOpeningFee` function of the Tapioca protocol's `BBLendingCommon` contract lies in its flawed implementation of the variable opening fee computation. The function relies on a hardcoded assumption that the exchange rate will always be USDO <> USDC, which is in...

Vulnerable code:
```\nfunction _computeVariableOpeningFee(uint256 amount) internal returns (uint256) {\n    if (amount == 0) {\n        return 0;\n    }\n\n    (bool updated, uint256 _exchangeRate) = assetOracle.get(oracleData);\n    if (!updated) {\n        revert OracleCallFailed();\n    }\n\n    if (_exchangeRate >= minMintFeeStart) {\n        return (amount * minMintFee) / FEE_PRECISION;\n    }\n    if (_exchangeRate <= maxMintFeeStart) {\n        return (amount * maxMintFee) / FEE_PRECISION;\n    }\n\n    uint256 fee = maxMintFee - (((_exchangeRate - maxMintFeeStart) * (maxMintFee - minMintFee)) / (minMintFeeStart - maxMintFeeStart));\n\n    if (fee > maxMintFee) {\n        return (amount * maxMintFee) / FEE_PRECISION;\n    }\n    if (fee < minMintFee) {\n        return (amount * minMintFee) / FEE_PRECISION;\n    }\n\n    if (fee > 0) {\n        return (amount * fee) / FEE_PRECISION;\n    }\n    return 0;\n}\n```\n```\nfunction _initCoreStorage(\n    IPenrose _penrose,\n    IERC20 _collateral,\n    uint256 _collateralId,\n    ITapiocaOracle _oracle,\n    uint256 _exchangeRatePrecision,\n    uint256 _collateralizationRate,\n    uint256 _liquidationCollateralizationRate,\n    ILeverageExecutor _leverageExecutor\n) private {\n    maxMintFeeStart = 975000000000000000; // 0.975 * 1e18\n    minMintFeeStart = 1000000000000000000; // 1 * 1e18\n}\n```\n```\nfunction setMinAndMaxMintRange(uint256 _min, uint256 _max) external onlyOwner {\n    emit UpdateMinMaxMintRange(minMintFeeStart, _min, maxMintFeeStart, _max);\n\n    if (_min >= _max) {\n        revert NotValid();\n    }\n\n    minMintFeeStart = _min;\n    maxMintFeeStart = _max;\n}\n```
MEDIUM severity: The contract's operator limit logic is hardcoded, which can lead to issues when attempting to upgrad. The contract's operator limit logic is hardcoded, which can lead to issues when attempting to upgrade the system to accommodate additional operators. The current implementation is limited to a single operator, with the `addOperator` function reverting if an attempt is made to add more. This is becau...

Vulnerable code:
```\nfunction addOperator(address _operatorAddress, address _feeRecipientAddress) external onlyAdmin returns (uint256) {\n    StakingContractStorageLib.OperatorsSlot storage operators = StakingContractStorageLib.getOperators();\n    StakingContractStorageLib.OperatorInfo memory newOperator;\n\n    if (operators.value.length == 1) {\n        revert MaximumOperatorCountAlreadyReached();\n    }\n}\n```\n```\nfunction _depositOnOneOperator(uint256 _depositCount, uint256 _totalAvailableValidators) internal {\n    StakingContractStorageLib.setTotalAvailableValidators(_totalAvailableValidators - _depositCount);\n    _depositValidatorsOfOperator(0, _depositCount);\n}\n```
MEDIUM severity: The vulnerability identified is the use of incorrect interfaces in the code, which may lead to poten. The vulnerability identified is the use of incorrect interfaces in the code, which may lead to potential issues and inconsistencies in the implementation. Specifically, the code uses `IPeUSD` instead of the expected `IEUSD` interface, and `IesLBR` instead of the expected `ILBR` interface.\n\nThis de...

Vulnerable code:
```\nIPeUSD public EUSD;\n```\n```\nif (address(EUSD) == address(0)) {\n    EUSD = IPeUSD(_eusd);\n}\n```\n```\npublic class IesLBR {\n}\n```\n```\nLBR = IesLBR(_lbr);\n```
MEDIUM severity: The vulnerability arises from the use of a downcast operation to convert the total bid amount to a `. The vulnerability arises from the use of a downcast operation to convert the total bid amount to a `uint96` data type, without performing any checks to ensure that the value does not exceed the maximum limit of `uint96`. This can lead to a loss of assets for some tokens, particularly those with high...

Vulnerable code:
```\nsettlement_.totalIn = uint96(result.totalAmountIn);\n```
MEDIUM severity: The vulnerability arises from an issue in the rebalancing mechanism of the system, where the `totalW. The vulnerability arises from an issue in the rebalancing mechanism of the system, where the `totalWithdrawalRequests` variable is not properly reset between rebalancing cycles. This variable tracks the cumulative total of withdrawal requests made during the current rebalancing period, and its value...

Vulnerable code:
```\nfunction resetVaultUnderlying(uint256 _vaultNumber) internal {\n    vaults[_vaultNumber].totalUnderlying = 0;\n    vaultStage[_vaultNumber].underlyingReceived = 0;\n    vaults[_vaultNumber].totalSupply = 0;\n}\n```\n```\nuint256 totalUnderlying = getTotalUnderlyingVault(_vaultNumber) - totalWithdrawalRequests;\n```