Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: This vulnerability allows an attacker to liquidate their own position in a single transaction, effec. This vulnerability allows an attacker to liquidate their own position in a single transaction, effectively bypassing the efficiency and liquidity removal limits, at a minimal cost. The attacker can achieve this by manipulating the oracle prices to create a situation where their position becomes liqu...

Vulnerable code:
```\nit('panprog liquidate unsuspecting user / self in 1 transaction', async () => {\n\n    function setupOracle(price: string, timestamp: number, nextTimestamp: number) {\n        const oracleVersion = {\n            price: parse6decimal(price),\n            timestamp: timestamp,\n            valid: true,\n        };\n        oracle.at.whenCalledWith(oracleVersion.timestamp).returns(oracleVersion);\n        oracle.status.returns([oracleVersion, nextTimestamp]);\n        oracle.request.returns();\n    }\n\n    var riskParameter = {\n        maintenance: parse6decimal('0.2'),\n        takerFee: parse6decimal('0.00'),\n        takerSkewFee: 0,\n        takerImpactFee: 0,\n        makerFee: parse6decimal('0.00'),\n        makerImpactFee: 0,\n        makerLimit: parse6decimal('1000'),\n        efficiencyLimit: parse6decimal('0.2'),\n        liquidationFee: parse6decimal('0.50'),\n        minLiquidationFee: parse6decimal('10'),\n        maxLiquidationFee: parse6decimal('1000'),\n        utilizationCurve: {\n            minRate: parse6decimal('0.0'),\n            maxRate: parse6decimal('1.00'),\n            targetRate: parse6decimal('0.10'),\n            targetUtilization: parse6decimal('0.50'),\n        },\n        pController: {\n            k: parse6decimal('40000'),\n            max: parse6decimal('1.20'),\n        },\n        minMaintenance: parse6decimal('10'),\n        virtualTaker: parse6decimal('0'),\n        staleAfter: 14400,\n        makerReceiveOnly: false,\n    };\n\n    var marketParameter = {\n        fundingFee: parse6decimal('0.0'),\n        interestFee: parse6decimal('0.0'),\n        oracleFee: parse6decimal('0.0'),\n        riskFee: parse6decimal('0.0'),\n        positionFee: parse6decimal('0.0'),\n        maxPendingGlobal: 5,\n        maxPendingLocal: 3,\n        settlementFee: parse6decimal('0'),\n        makerRewardRate: parse6decimal('0'),\n        longRewardRate: parse6decimal('0'),\n        shortRewardRate: parse6decimal('0'),\n        makerCloseAlways: false,\n        takerCloseAlways: false,\n        closed: false,\n    };\n\n    await market.connect(owner).updateRiskParameter(riskParameter);\n```\n```\nLiquidated maker: collateral = 99980000\nmaker = 0\n```
MEDIUM severity: The WithdrawPeriphery contract contains a critical vulnerability due to the incorrect assignment of . The WithdrawPeriphery contract contains a critical vulnerability due to the incorrect assignment of the MAX_BPS constant. Specifically, the value of MAX_BPS is set to 1000, which is significantly lower than the typical industry standard of 10,000. This deviation from the norm is inconsistent with th...

Vulnerable code:
```\nuint256 internal constant MAX_BPS = 1000;\n```
MEDIUM severity: The `updateGlobalPositionData` function in the `LiquidationModule` is responsible for updating the g. The `updateGlobalPositionData` function in the `LiquidationModule` is responsible for updating the global position data after a position is liquidated. However, the function uses the position's last price (`position.lastPrice`) instead of the current price when updating the global position data. Thi...

Vulnerable code:
```\nFile: LiquidationModule.sol\n\n@notice Function to liquidate a position.\n@dev One could directly call this method instead of `liquidate(uint256, bytes[])` if they don't want to update the Pyth price.\n@param tokenId The token ID of the leverage position.\nfunction liquidate(uint256 tokenId) public nonReentrant whenNotPaused liquidationInvariantChecks(vault, tokenId) {\n    FlatcoinStructs.Position memory position = vault.getPosition(tokenId);\n\n    (uint256 currentPrice, ) = IOracleModule(vault.moduleAddress(FlatcoinModuleKeys._ORACLE_MODULE_KEY)).getPrice();\n\n    // Settle funding fees accrued till now.\n    vault.settleFundingFees();\n\n    // Check if the position can indeed be liquidated.\n    if (!canLiquidate(tokenId)) revert FlatcoinErrors.CannotLiquidate(tokenId);\n\n    FlatcoinStructs.PositionSummary memory positionSummary = PerpMath._getPositionSummary(\n        position,\n        vault.cumulativeFundingRate(),\n        currentPrice\n    );\n\n    vault.updateGlobalPositionData({\n        price: position.lastPrice,\n        marginDelta: -(int256(position.marginDeposited) + positionSummary.accruedFunding),\n        additionalSizeDelta: -int256(position.additionalSize) // Since position is being closed, additionalSizeDelta should be negative.\n    });\n```\n```\nFile: FlatcoinVault.sol\n\n@notice Function to update the global position data.\n@dev This function is only callable by the authorized modules.\n@param _price The current price of the underlying asset.\n@param _marginDelta The change in the margin deposited total.\n@param _additionalSizeDelta The change in the size opened total.\nfunction updateGlobalPositionData(\n    uint256 _price,\n    int256 _marginDelta,\n    int256 _additionalSizeDelta\n) external onlyAuthorizedModule {\n    int256 profitLossTotal = PerpMath._profitLossTotal({\n        globalPosition: _globalPositions,\n        price: _price\n    });\n\n    int256 newMarginDepositedTotal = int256(_globalPositions.marginDepositedTotal) + _marginDelta + profitLossTotal;\n\n    if (newMarginDepositedTotal < 0) {\n        revert FlatcoinErrors.InsufficientGlobalMargin();\n    }\n\n    _globalPositions = FlatcoinStructs.GlobalPositions({\n        marginDepositedTotal: uint256(newMarginDepositedTotal),\n        sizeOpenedTotal: uint256((int256(_globalPositions.sizeOpenedTotal) + _additionalSizeDelta)),\n        lastPrice: _price\n    });\n```
MEDIUM severity: The `MetaSwap.swap()` function is susceptible to a reentrancy vulnerability, which can be exploited . The `MetaSwap.swap()` function is susceptible to a reentrancy vulnerability, which can be exploited by an attacker to manipulate the trade process and steal tokens. The vulnerability arises from the lack of a reentrancy guard in the function, allowing an attacker to repeatedly call `swap()` before t...

Vulnerable code:
```\nif (address(tokenTo)!= Constants.ETH) {\n    uint256 balance = tokenTo.balanceOf(address(this));\n    require(balance >= amountTo, "INSUFFICIENT_AMOUNT");\n    _transfer(tokenTo, balance, recipient);\n} else {\n```
MEDIUM severity: The `apmNamehash` used in the EOPBCTemplate's BalanceRedirectPresale contract references a namehash . The `apmNamehash` used in the EOPBCTemplate's BalanceRedirectPresale contract references a namehash that is already utilized by the aragonBlack/Presale contract. This naming collision can lead to confusion and potential issues when attempting to deploy and manage multiple variants of the contract. S...

Vulnerable code:
```\nbytes32 private constant PRESALE_ID = 0x5de9bbdeaf6584c220c7b7f1922383bcd8bbcd4b48832080afd9d5ebf9a04df5;\n```\n```\nbytes32 private constant PRESALE_ID = 0x5de9bbdeaf6584c220c7b7f1922383bcd8bbcd4b48832080afd9d5ebf9a04df5;\n```
MEDIUM severity: This vulnerability arises when a bidder's account becomes blacklisted after submitting a bid in a ba. This vulnerability arises when a bidder's account becomes blacklisted after submitting a bid in a batch auction. The auction settlement process relies on the bidder's account being active and functional to facilitate the refund and payout of quote tokens and base tokens. However, if the bidder's acc...

Vulnerable code:
```\nif (settlement.pfBidder!= address(0)) {\n    _allocateQuoteFees(\n        feeData.protocolFee,\n        feeData.referrerFee,\n        settlement.pfReferrer,\n        routing.seller,\n        routing.quoteToken,\n        uint96(\n            Math.mulDivDown(\n                settlement.pfPayout,\n                settlement.totalIn,\n                settlement.totalOut\n            )\n        )\n    );\n\n    unchecked {\n        routing.funding -= uint96(settlement.pfPayout);\n    }\n\n    Transfer.transfer(\n        routing.quoteToken,\n        settlement.pfBidder,\n        settlement.pfRefund,\n        false\n    );\n\n    _sendPayout(settlement.pfBidder, settlement.pfPayout, routing, auctionOutput);\n}\n```\n```\nfunction settle(uint96 lotId_)\n    external\n    virtual\n    override\n    onlyInternal\n    returns (Settlement memory settlement, bytes memory auctionOutput)\n{\n    // Standard validation\n    _revertIfLotInvalid(lotId_);\n    _revertIfBeforeLotStart(lotId_);\n    _revertIfLotActive(lotId_);\n    _revertIfLotSettled(lotId_);\n    \n    // rest of code\n}\n```\n```\nfunction refundBid(\n    uint96 lotId_,\n    uint64 bidId_,\n    address caller_\n) external override onlyInternal returns (uint96 refund) {\n    // Standard validation\n    _revertIfLotInvalid(lotId_);\n    _revertIfBeforeLotStart(lotId_);\n    _revertIfBidInvalid(lotId_, bidId_);\n    _revertIfNotBidOwner(lotId_, bidId_, caller_);\n    _revertIfBidClaimed(lotId_, bidId_);\n    _revertIfLotConcluded(lotId_);\n\n    // Call implementation-specific logic\n    return _refundBid(lotId_, bidId_, caller_);\n}\n```
MEDIUM severity: The vulnerability occurs when a D3MM pool repays all borrowed funds to the vault using the `D3Fundin. The vulnerability occurs when a D3MM pool repays all borrowed funds to the vault using the `D3Funding.sol repayAll` function, which in turn calls `D3VaultFunding.sol poolRepayAll` and ultimately `D3VaultFunding.sol _poolRepayAll`. This process is supposed to decrease the borrowed funds and increase...

Vulnerable code:
```\nfunction _poolRepayAll(address pool, address token) internal {\n    info.totalBorrows = info.totalBorrows - amount;\n    info.balance = info.balance - amount;\n}\n```\n```\nfunction repayAll(address token) external onlyOwner nonReentrant poolOngoing {\n    ID3Vault(state._D3_VAULT_).poolRepayAll(token);\n    _updateReserve(token);\n    require(checkSafe(), Errors.NOT_SAFE);\n}\n```\n```\nfunction _poolRepayAll(address pool, address token) internal {\n   .\n   .\n   .\n    \n    info.totalBorrows = info.totalBorrows - amount;\n    info.balance = info.balance - amount; // amount should be added here\n\n    IERC20(token).safeTransferFrom(pool, address(this), amount);\n\n    emit PoolRepay(pool, token, amount, interests);\n}\n```\n```\nfunction userDeposit(address user, address token) external nonReentrant allowedToken(token) {\n    AssetInfo storage info = assetInfo[token];\n    uint256 realBalance = IERC20(token).balanceOf(address(this)); // check tokens owned by vault\n    uint256 amount = realBalance - info.balance; // amount = 120000-80000\n\n    IDToken(info.dToken).mint(user, dTokenAmount);\n    info.balance = realBalance;\n\n    emit UserDeposit(user, token, amount);\n}\n```
MEDIUM severity: The FeiTimedMinter's constructor does not enforce the same boundaries for the `frequency` parameter . The FeiTimedMinter's constructor does not enforce the same boundaries for the `frequency` parameter as the `setFrequency` method. This discrepancy can lead to unexpected behavior and potential security issues.\n\nThe `setFrequency` method, which is accessible only to the governor or admin, enforces...

Vulnerable code:
```\nconstructor(\n    address _core,\n    address _target,\n    uint256 _incentive,\n    uint256 _frequency,\n    uint256 _initialMintAmount\n) {\n    CoreRef(_core)\n    Timed(_frequency)\n    Incentivized(_incentive)\n    RateLimitedMinter(((_initialMintAmount + _incentive) / _frequency, (_initialMintAmount + _incentive), true)\n{\n    _initTimed();\n\n    _setTarget(_target);\n    _setMintAmount(_initialMintAmount);\n}\n```\n```\nfunction setFrequency(uint256 newFrequency) external override onlyGovernorOrAdmin {\n    require(newFrequency >= MIN_MINT_FREQUENCY, "FeiTimedMinter: frequency low");\n    require(newFrequency <= MAX_MINT_FREQUENCY, "FeiTimedMinter: frequency high");\n\n    _setDuration(newFrequency);\n}\n```
MEDIUM severity: The vulnerability lies in the deployment and upgrade script, where a private key is used to broadcas. The vulnerability lies in the deployment and upgrade script, where a private key is used to broadcast a transaction. This exposure of the private key compromises the security of the deployer and upgrader accounts, as it is stored in plain text on the machine running the script. This is a critical is...

Vulnerable code:
```\nuint256 deployerPrivateKey = vm.envUint("PRIVATE_KEY");\n```\n```\nuint256 deployerPrivateKey = vm.envUint("PRIVATE_KEY");\nvm.startBroadcast(deployerPrivateKey);\n```
MEDIUM severity: The Swapper mechanism in the contract is designed to incentivize ETH-WETH swaps by offering a discou. The Swapper mechanism in the contract is designed to incentivize ETH-WETH swaps by offering a discount to bots that perform these swaps. However, this mechanism has a critical flaw that can lead to unintended consequences. When the `flash()` function is called, the contract receives pairs of tokens...

Vulnerable code:
```\namountsToBeneficiary = oracle.getQuoteAmounts(quoteParams_)\n```\n```\nConvertedQuotePair memory cqp = quoteParams_.quotePair._convert(_convertToken);\nSortedConvertedQuotePair memory scqp = cqp._sort();\n```\n```\nPairOverride memory po = _getPairOverride(scqp);\n\nif (po.scaledOfferFactor == 0) {\n    po.scaledOfferFactor = $defaultScaledOfferFactor;\n}\n```
MEDIUM severity: The `_endVote()` function in the VoteKickPolicy contract is vulnerable to a malicious attack that ca. The `_endVote()` function in the VoteKickPolicy contract is vulnerable to a malicious attack that can cause it to revert indefinitely. This occurs when a target, who has previously staked and been reported by a flagger, force-unstakes and then re-stakes their stake. This action resets the `lockedSta...

Vulnerable code:
```\nFile: contracts/OperatorTokenomics/SponsorshipPolicies/VoteKickPolicy.sol\n\nfunction _endVote(address target) internal {\n    address flagger = flaggerAddress[target];\n    bool flaggerIsGone = stakedWei[flagger] == 0;\n    bool targetIsGone = stakedWei[target] == 0;\n    uint reviewerCount = reviewers[target].length;\n\n    // release stake locks before vote resolution so that slashings and kickings during resolution aren't affected\n    if (flaggerIsGone) {\n        forfeitedStakeWei -= flagStakeWei[target];\n    } else {\n        lockedStakeWei[flagger] -= flagStakeWei[target];\n    }\n    if (targetIsGone) {\n        forfeitedStakeWei -= targetStakeAtRiskWei[target];\n    } else {\n        lockedStakeWei[target] -= targetStakeAtRiskWei[target];\n    }\n```
MEDIUM severity: The `supplyNativeToken` function in TxBuilderExtension.sol is vulnerable to a critical issue when ca. The `supplyNativeToken` function in TxBuilderExtension.sol is vulnerable to a critical issue when called after the `ACTION_DEFER_LIQUIDITY_CHECK` event. This function deposits the `msg.value` amount of ETH to the WETH contract, which is problematic if executed in a new context created by `onDeferred...

Vulnerable code:
```\nfunction supplyNativeToken(address user) internal nonReentrant {\n    WethInterface(weth).deposit{value: msg.value}();\n\n    IERC20(weth).safeIncreaseAllowance(address(ironBank), msg.value);\n\n    ironBank.supply(address(this), user, weth, msg.value);\n}\n```
MEDIUM severity: This vulnerability is related to inconsistent function naming conventions in the code. Specifically,. This vulnerability is related to inconsistent function naming conventions in the code. Specifically, the functions `includeAssimilator` and `excludeAdapter` are used to manage the assimilator list, but they do not follow a consistent naming convention.\n\nThe `includeAssimilator` function adds a new...

Vulnerable code:
```\nshell.assimilators[_derivative] = Assimilators.Assimilator(_assimilator, _numeraireAssim.ix)\n```\n```\ndelete shell.assimilators[_assimilator];\n```
MEDIUM severity: The FundraisingMultisigTemplate is configured to accept `DAI` and `ANT` token addresses upon deploym. The FundraisingMultisigTemplate is configured to accept `DAI` and `ANT` token addresses upon deployment. However, the `_ensureTokenIsContractOrETH` function, which is used to validate the provided addresses, allows for the `address(0)` constant, which is used to represent ETH. This is problematic be...

Vulnerable code:
```\nensureTokenIsContractOrETH(_dai);\nensureTokenIsContractOrETH(_ant);\n```\n```\nfunction _ensureTokenIsContractOrETH(address _token) internal view returns (bool) {\n    require(isContract(_token) || _token == ETH, ERROR_BAD_SETTINGS);\n}\n```
MEDIUM severity: The vulnerability arises when a plugin within the Vault contract becomes broken or paused, causing t. The vulnerability arises when a plugin within the Vault contract becomes broken or paused, causing the entire contract's deposit and withdrawal functionality to malfunction. This can occur due to various reasons, including temporary or permanent malfunctioning of a plugin, which can prevent it from...

Vulnerable code:
```\nmodifier whenNotPaused() {\n    _whenNotPaused();\n    _;\n}\n```\n```\nfunction withdraw(\n    address asset,\n    uint256 amount,\n    address to\n) external override whenNotPaused returns (uint256) {\n```
MEDIUM severity: The `cancelExecution` function, responsible for canceling script execution with a specified ID, lack. The `cancelExecution` function, responsible for canceling script execution with a specified ID, lacks a crucial existence check on the provided script ID. This oversight allows an attacker to manipulate the function by passing a non-existent script ID, which would result in the clearing of a storage...

Vulnerable code:
```\n/**\n * @notice Cancel script execution with ID `_delayedScriptId`\n * @param _delayedScriptId The ID of the script execution to cancel\n */\nfunction cancelExecution(uint256 _delayedScriptId) external auth(CANCEL_EXECUTION_ROLE) {\n    delete delayedScripts[_delayedScriptId];\n\n    emit ExecutionCancelled(_delayedScriptId);\n}\n```
MEDIUM severity: The vulnerability allows all operators to have ETH deposits, regardless of the cap set for them, whi. The vulnerability allows all operators to have ETH deposits, regardless of the cap set for them, which can lead to miscalculated TVL (Total Value Locked) in the LRT (Liquid Reputation Token) system. This is because the system does not properly account for the ETH deposits of operators who are not ac...

Vulnerable code:
```\nfunction getTVLForAsset(address asset) public view returns (uint256) {\n    uint256 balance = getTotalBalanceForAsset(asset);\n    if (asset == ETH_ADDRESS) {\n        return balance;\n    }\n    return convertToUnitOfAccountFromAsset(asset, balance);\n}\n\nfunction getTotalBalanceForAsset(address asset) public view returns (uint256) {\n    if (!isSupportedAsset(asset)) {\n        revert ASSET_NOT_SUPPORTED(asset);\n    }\n\n    address depositPool_ = address(depositPool());\n    if (asset == ETH_ADDRESS) {\n        return depositPool_.balance + getETHBalanceInEigenLayer();\n    }\n\n    uint256 sharesHeld = getAssetSharesHeld(asset);\n    uint256 tokensInRio = IERC20(asset).balanceOf(depositPool_);\n    uint256 tokensInEigenLayer = convertFromSharesToAsset(getAssetStrategy(asset), sharesHeld);\n\n    return tokensInRio + tokensInEigenLayer;\n}\n\nfunction getETHBalanceInEigenLayer() public view returns (uint256 balance) {\n    balance = ethBalanceInUnverifiedValidators;\n\n    IRioLRTOperatorRegistry operatorRegistry_ = operatorRegistry();\n    uint8 endAtID = operatorRegistry_.operatorCount() + 1; // Operator IDs start at 1.\n    for (uint8 id = 1; id < endAtID; ++id) {\n        balance += operatorDelegator(operatorRegistry_, id).getETHUnderManagement();\n    }\n}\n```\n```\nfunction getEigenPodShares() public view returns (int256) {\n    return eigenPodManager.podOwnerShares(address(this));\n}\n\nfunction getETHQueuedForWithdrawal() public view returns (uint256) {\n    uint256 ethQueuedSlotData;\n    assembly {\n        ethQueuedSlotData := sload(ethQueuedForUserSettlementGwei.slot)\n    }\n\n    uint64 userSettlementGwei = uint64(ethQueuedSlotData);\n    uint64 operatorExitAndScrapeGwei = uint64(ethQueuedSlotData) << 64;\n\n    return (userSettlementGwei + operatorExitAndScrapeGwei).toWei();\n}\n\nfunction getETHUnderManagement() external view returns (uint256) {\n    int256 aum = getEigenPodShares() + int256(getETHQueuedForWithdrawal());\n    if (aum < 0) {\n        return 0;\n    }\n\n    return uint256(aum);\n}\n```
MEDIUM severity: The `consultIn18Decimals()` function in the `ChainlinkARBOracle.sol` contract is vulnerable to a pot. The `consultIn18Decimals()` function in the `ChainlinkARBOracle.sol` contract is vulnerable to a potential scenario where a negative price can be delivered. This occurs when the `consult()` function is called, which verifies each answer and delivers a price that is not old, not zero, and non-negativ...

Vulnerable code:
```\npragma solidity 0.8.21;\n\nimport { SafeCast } from "@openzeppelin/contracts/utils/math/SafeCast.sol";\n\nerror BrokenTokenPriceFeed();\n\ncontract PassWithNegativePrice {\n    using SafeCast for int256;\n\n    uint256 public maxDeviations;\n    int256 public currentResponse;\n    int256 public prevResponse;\n    uint8 public decimal;\n\n    constructor(\n        int256 _currentResponse,\n        int256 _prevResponse,\n        uint8 _decimal,\n        uint256 _maxDeviations\n    ) {\n        currentResponse = _currentResponse;\n        prevResponse = _prevResponse;\n        decimal = _decimal;\n        maxDeviations = _maxDeviations;\n    }\n\n    function consultIn18Decimals() external view returns (uint256) {\n        (int256 _answer, uint8 _decimals) = consult();\n\n        return _answer.toUint256() * 1e18 / (10 ** _decimals);\n    }\n\n    function consult() internal view returns (int256, uint8) {\n        if (_badPriceDeviation(currentResponse, prevResponse)) {\n            revert BrokenTokenPriceFeed();\n        }\n\n        return (currentResponse, decimal);\n    }\n\n    function _badPriceDeviation(int256 _currentResponse, int256 _prevResponse) internal view returns (bool) {\n        uint256 _deviation;\n\n        if (_currentResponse > _prevResponse) {\n            _deviation = uint256(_currentResponse - _prevResponse) * 1e18 / uint256(_prevResponse);\n        } else {\n            _deviation = uint256(_prevResponse - _currentResponse) * 1e18 / uint256(_prevResponse);\n        }\n\n        return _deviation > maxDeviations;\n    }\n}\n```
MEDIUM severity: The vulnerability lies in the `VaultLiquidationAction.sol` contract's `_authenticateDeleverage` func. The vulnerability lies in the `VaultLiquidationAction.sol` contract's `_authenticateDeleverage` function, which allows an arbitrary account to act as the `liquidator` if they have approved any amount of funds for the contract. This is because the function does not validate the `liquidator` parameter...

Vulnerable code:
```\nFile: VaultLiquidationAction.sol\n\nfunction _authenticateDeleverage(\n    address account,\n    address vault,\n    address liquidator\n) private returns (\n    VaultConfig memory vaultConfig,\n    VaultAccount memory vaultAccount,\n    VaultState memory vaultState\n) {\n    requireValidAccount(liquidator);\n    require(liquidator!= vault);\n\n    require(account!= msg.sender);\n    require(account!= liquidator);\n\n    vaultConfig = VaultConfiguration.getVaultConfigStateful(vault);\n    require(vaultConfig.getFlag(VaultConfiguration.DISABLE_DELEVERAGE) == false);\n\n    if (vaultConfig.getFlag(VaultConfiguration.ONLY_VAULT_DELEVERAGE)) {\n        require(msg.sender == vault);\n    } else {\n        require(msg.sender == liquidator);\n    }\n\n    vaultAccount = VaultAccountLib.getVaultAccount(account, vaultConfig);\n\n    require(block.timestamp < vaultAccount.maturity, "Must Settle");\n\n    if (vaultAccount.maturity == Constants.PRIME_CASH_VAULT_MATURITY) {\n        vaultState = vaultAccount.accruePrimeCashFeesToDebtInLiquidation(vaultConfig);\n    } else {\n        vaultState = VaultStateLib.getVaultState(vaultConfig, vaultAccount.maturity);\n    }\n}\n```