Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The vulnerability arises when a user attempts to upgrade their wallet using the `upgradeWalletType(). The vulnerability arises when a user attempts to upgrade their wallet using the `upgradeWalletType()` function, but an upgrade target has not been set up. This function relies on the `_upgradablePaths` mapping to determine the next wallet type for the user. However, there is a critical oversight in...

Vulnerable code:
```\nfunction upgradeWalletType() external {\n    if (!isWallet(msg.sender)) {\n        revert WalletDoesntExist(msg.sender);\n    }\n    uint8 fromWalletType = _walletDataMap[msg.sender].walletType;\n    _setWalletType(msg.sender, _upgradablePaths[fromWalletType]);\n    emit WalletUpgraded(msg.sender, fromWalletType, _upgradablePaths[fromWalletType]);\n}\n```\n```\nfunction _setWalletType(address _wallet, uint8 _walletType) private {\n    _walletDataMap[_wallet].walletType = _walletType;\n}\n```\n```\nfunction isWallet(address _wallet) public view returns (bool) {\n    WalletData memory walletData = _walletDataMap[_wallet];\n    if (walletData.walletType == 0 || walletData.feeToken == address(0)) {\n        return false;\n    }\n    return true;\n}\n```
MEDIUM severity: The vulnerability identified is a lack of proper access control in certain functions, which allows u. The vulnerability identified is a lack of proper access control in certain functions, which allows unauthorized access to critical system functionalities. Specifically, the `setIDOLContract` function is declared as `public`, permitting anyone to execute it, regardless of their privileges. This can l...

Vulnerable code:
```\nfunction setIDOLContract(address contractAddress) public {\n    require(address(_IDOLContract) == address(0), "IDOL contract is already registered");\n    _setStableCoinContract(contractAddress);\n}\n```
MEDIUM severity: The exponential and logarithmic price adapters in the system are prone to returning incorrect pricin. The exponential and logarithmic price adapters in the system are prone to returning incorrect pricing when used with token pricing of different decimal places. This is because the resolution of the underlying `expWad` and `lnWad` functions is not suitable for tokens with varying decimal places.\n\nT...

Vulnerable code:
```\nfunction _calculateQuoteAssetQuantity(bool isSellAuction, uint256 _componentQuantity, uint256 _componentPrice) private pure returns (uint256) {\n    return isSellAuction\n       ? _componentQuantity.preciseMulCeil(_componentPrice)\n        : _componentQuantity.preciseMul(_componentPrice);\n}\n```\n```\n1e18 * price / 1e18 = 2000e6\n```\n```\nprice = 2000e6\n```\n```\nprice = dp = 18 - component_dp + quote_dp\n```\n```\nuint256 expExpression = uint256(FixedPointMathLib.expWad(expArgument));\n\nif (scalingFactor > type(uint256).max / expExpression) {\n    return _getBoundaryPrice(isDecreasing, maxPrice, minPrice);\n}\n\nuint256 priceChange = scalingFactor * expExpression - WAD;\n\nif (isDecreasing) {\n    if (priceChange > initialPrice) {\n        return minPrice;\n    }\n    return FixedPointMathLib.max(initialPrice - priceChange, minPrice);\n```\n```\nexpWad(1e6) - WAD = 1e6\nexpWad(5e6) - WAD = 5e6\nexpWad(10e6) - WAD = 10e6\nexpWad(1000e6) - WAD = 1000e6\n```
MEDIUM severity: The `_joinPoolAndStake` function in `Boosted3TokenPoolUtils.sol` relies heavily on the `deposit` fun. The `_joinPoolAndStake` function in `Boosted3TokenPoolUtils.sol` relies heavily on the `deposit` function of the `AuraBooster` contract to handle token staking. However, when interacting with the `AuraBooster` contract to deposit tokens and stake them, the function does not properly handle the retur...

Vulnerable code:
```\nstakingContext.auraBooster.deposit(stakingContext.auraPoolId, bptMinted, true)\n```\n```\n/**\n * Deposits an "_amount" to a given gauge (specified by _pid), mints a `DepositToken`\n * and subsequently stakes that on Convex BaseRewardPool\n */\nfunction deposit(uint256 _pid, uint256 _amount, bool _stake) public returns(bool) {\n```
MEDIUM severity: The `openLoan()` function in the smart contract contains a critical calculation error in the calcula. The `openLoan()` function in the smart contract contains a critical calculation error in the calculation of `totalUSDborrowed`. Specifically, it uses the `isoUSDLoaned` variable to calculate `totalUSDborrowed`, which can be exploited by an attacker to bypass the security check and loan ISOUSD withou...

Vulnerable code:
```\nfunction openLoan(\n    ) external override whenNotPaused {\n    uint256 colInUSD = priceCollateralToUSD(currencyKey, _colAmount \n        + collateralPosted[_collateralAddress][msg.sender]);\n    uint256 totalUSDborrowed = _USDborrowed \n        + (isoUSDLoaned[_collateralAddress][msg.sender] * virtualPrice) / LOAN_SCALE;\n    // @audit should be isoUSDLoanAndInterest[_collateralAddress][msg.sender]\n    require(totalUSDborrowed >= ONE_HUNDRED_DOLLARS, "Loan Requested too small");\n    uint256 borrowMargin = (totalUSDborrowed * minOpeningMargin) / LOAN_SCALE;\n    require(colInUSD >= borrowMargin, "Minimum margin not met!");\n}\n```
MEDIUM severity: The governance system allows users to delegate their voting power to other users. However, the staki. The governance system allows users to delegate their voting power to other users. However, the staking mechanism lacks a checkpoint mechanism, which creates a vulnerability. Specifically, users are prohibited from delegating or unstaking their votes during an active proposal if their delegate has al...

Vulnerable code:
```\nmodifier lockedWhileVotesCast() {\n    uint[] memory activeProposals = governance.getActiveProposals();\n    for (uint i = 0; i < activeProposals.length; i++) {\n        if (governance.getReceipt(activeProposals[i], getDelegate(msg.sender)).hasVoted) {\n            revert TokenLocked();\n        }\n        (, address proposer, ) = governance.getProposalData(activeProposals[i]);\n        if (proposer == getDelegate(msg.sender)) {\n            revert TokenLocked();\n        }\n    }\n}\n```
MEDIUM severity: The vulnerability arises from an incorrect implementation of the checks in the `GMXChecks::beforeReb. The vulnerability arises from an incorrect implementation of the checks in the `GMXChecks::beforeRebalanceChecks` function, which allows a rebalance to occur when `delta` or `debtRatio` is equal to their respective limits. This is because the function does not account for the inclusive nature of the...

Vulnerable code:
```\nfunction beforeRebalanceChecks(\n  GMXTypes.Store storage self,\n  GMXTypes.RebalanceType rebalanceType\n) external view {\n  if (\n    self.status!= GMXTypes.Status.Open &&\n    self.status!= GMXTypes.Status.Rebalance_Open\n  ) {\n    revert Errors.NotAllowedInCurrentVaultStatus();\n  }\n\n  if (rebalanceType == GMXTypes.RebalanceType.Delta && \n      self.delta == GMXTypes.Delta.Neutral) {\n    if (\n      self.rebalanceCache.healthParams.deltaBefore < self.deltaUpperLimit &&\n      self.rebalanceCache.healthParams.deltaBefore > self.deltaLowerLimit\n    ) {\n      revert Errors.InvalidRebalancePreConditions();\n    }\n  } else if (rebalanceType == GMXTypes.RebalanceType.Debt) {\n    if (\n      self.rebalanceCache.healthParams.debtRatioBefore < self.debtRatioUpperLimit &&\n      self.rebalanceCache.healthParams.debtRatioBefore > self.debtRatioLowerLimit\n    ) {\n      revert Errors.InvalidRebalancePreConditions();\n    }\n  } else {\n    revert Errors.InvalidRebalanceParameters();\n  }\n}\n```\n```\nfunction afterRebalanceChecks(\n  GMXTypes.Store storage self\n) external view {\n  // Guards: check that delta is within limits for Neutral strategy\n  if (self.delta == GMXTypes.Delta.Neutral) {\n    int256 _delta = GMXReader.delta(self);\n\n    if (_delta > self.deltaUpperLimit || _delta < self.deltaLowerLimit) {\n      revert Errors.InvalidDelta();\n    }\n  }\n\n  // Guards: check that debt is within limits for Long/Neutral strategy\n  uint256 _debtRatio = GMXReader.debtRatio(self);\n\n  if (_debtRatio > self.debtRatioUpperLimit || _debtRatio < self.debtRatioLowerLimit) {\n    revert Errors.InvalidDebtRatio();\n  }\n}\n```
MEDIUM severity: The `pendingRewards` function in the WAuraPools contract retrieves a fresh count of reward tokens ea. The `pendingRewards` function in the WAuraPools contract retrieves a fresh count of reward tokens each time it is called. This mechanism is problematic because it does not account for the possibility of reward tokens being removed from the underlying Aura/Convex pools. As a result, if reward tokens...

Vulnerable code:
```\nuint extraRewardsCount = IAuraRewarder(crvRewarder).extraRewardsLength();\n\ntokens = new address[](extraRewardsCount + 1);\nrewards = new uint256[](extraRewardsCount + 1);\n\ntokens[0] = IAuraRewarder(crvRewarder).rewardToken();\nrewards[0] = _getPendingReward(\n    stCrvPerShare,\n    crvRewarder,\n    amount,\n    lpDecimals\n);\n\nfor (uint i = 0; i < extraRewardsCount; i++) {\n    address rewarder = IAuraRewarder(crvRewarder).extraRewards(i);\n    uint256 stRewardPerShare = accExtPerShare[tokenId][i];\n    tokens[i + 1] = IAuraRewarder(rewarder).rewardToken();\n    rewards[i + 1] = _getPendingReward(\n        stRewardPerShare,\n        rewarder,\n        amount,\n        lpDecimals\n    );\n}\n```
MEDIUM severity: The vulnerability allows an attacker to intentionally send malformed withdrawal data to the LegacyMe. The vulnerability allows an attacker to intentionally send malformed withdrawal data to the LegacyMessagePasser, causing the migration process to halt and return an error. This is possible because the data for the migration is sourced from every call made to the LegacyMessagePasser address, and the...

Vulnerable code:
```\nif addr == dump.MessagePasserAddress:\n    statedumper.WriteMessage(caller.Address(), input)\n```\n```\nselector := crypto.Keccak256([]byte("relayMessage(address,address,bytes,uint256)"))[0:4]\nif!bytes.Equal(data[0:4], selector) {\n    return fmt.Errorf("invalid selector: %x", data[0:4])\n}\n\nmsgSender := data[len(data)-len(predeploys.L2CrossDomainMessengerAddr):]\nif!bytes.Equal(msgSender, predeploys.L2CrossDomainMessengerAddr.Bytes()) {\n    return errors.New("invalid msg.sender")\n```\n```\nfunction passMessageToL1(bytes memory _message) external {\n    sentMessages[keccak256(abi.encodePacked(_message, msg.sender))] = true;\n}\n```\n```\nfor slot := range slotsAct {\n    _, ok := slotsInp[slot]\n    if!ok {\n        return nil, fmt.Errorf("unknown storage slot in state: %s", slot)\n    }\n}\n```
MEDIUM severity: The `Crowdinvesting` contract's `initialize()` function receives parameters to set up the contract, . The `Crowdinvesting` contract's `initialize()` function receives parameters to set up the contract, including `tokenPrice`, `minAmountPerBuyer`, `lastBuyDate`, and `currency`. However, the contract lacks proper validation of these parameters during initialization, which can lead to potential securit...

Vulnerable code:
```\nrequire(_arguments.tokenPrice!= 0, "_tokenPrice needs to be a non-zero amount");\n```\n```\nrequire(\n    _arguments.minAmountPerBuyer <= _arguments.maxAmountPerBuyer,\n    "_minAmountPerBuyer needs to be smaller or equal to _maxAmountPerBuyer"\n);\n```\n```\nlastBuyDate = _arguments.lastBuyDate\n```\n```\nfunction _checkAndDeliver(uint256 _amount, address _tokenReceiver) internal {\n    require(tokensSold + _amount <= maxAmountOfTokenToBeSold, "Not enough tokens to sell left");\n    require(tokensBought[_tokenReceiver] + _amount >= minAmountPerBuyer, "Buyer needs to buy at least minAmount");\n    require(\n        tokensBought[_tokenReceiver] + _amount <= maxAmountPerBuyer,\n        "Total amount of bought tokens needs to be lower than or equal to maxAmount"\n    );\n\n    if (lastBuyDate!= 0 && block.timestamp > lastBuyDate) {\n        revert("Last buy date has passed: not selling tokens anymore.");\n    }\n\n    tokensSold += _amount;\n    tokensBought[_tokenReceiver] += _amount;\n\n    token.mint(_tokenReceiver, _amount);\n}\n```\n```\nrequire(address(_arguments.currency)!= address(0), "currency cannot be zero address");\n```
MEDIUM severity: The Swap Fees Bypass vulnerability in the system allows liquidity providers to circumvent the intend. The Swap Fees Bypass vulnerability in the system allows liquidity providers to circumvent the intended fee structure for swapping between assets. This is achieved by exploiting the `redeemMasset` function, which enables traders to convert mAssets back into a proportional amount of bAssets without in...

Vulnerable code:
```\nsettleRedemption(\n    _recipient,\n    _mAssetQuantity,\n    props.bAssets,\n    bAssetQuantities,\n    props.indexes,\n    props.integrators,\n    false\n)\n```
MEDIUM severity: The `submitData` function, responsible for processing data submissions, allows for the submission of. The `submitData` function, responsible for processing data submissions, allows for the submission of compressed data with an empty value in the `_submissionData` parameter. This unexpected behavior may lead to undefined system behavior, as the function is not designed to handle such input. The prese...

Vulnerable code:
```\nfunction submitData(\n    SubmissionData calldata _submissionData\n) \nexternal \nwhenTypeNotPaused(PROVING_SYSTEM_PAUSE_TYPE)\nwhenTypeNotPaused(GENERAL_PAUSE_TYPE)\nonlyRole(OPERATOR_ROLE)\n{\n    _submitData(_submissionData);\n}\n```
MEDIUM severity: The Lender#lend for Sense functionality in the provided code exhibits a critical vulnerability due t. The Lender#lend for Sense functionality in the provided code exhibits a critical vulnerability due to a mismatch between the decimals of the Sense principal token and the ERC5095 vault it mints shares to. This disparity in decimals can be exploited on the USDC market to mint an excessive number of s...

Vulnerable code:
```\nuint256 received;\n\n{\n    // Get the starting balance of the principal token\n    uint256 starting = token.balanceOf(address(this));\n\n    // Swap those tokens for the principal tokens\n    ISensePeriphery(x).swapUnderlyingForPTs(adapter, s, lent, r);\n\n    // Calculate number of principal tokens received in the swap\n    received = token.balanceOf(address(this)) - starting;\n\n    // Verify that we received the principal tokens\n    if (received < r) {\n        revert Exception(11, 0, 0, address(0), address(0));\n    }\n}\n\n// Mint the Illuminate tokens based on the returned amount\nIERC5095(principalToken(u, m)).authMint(msg.sender, received);\n```
MEDIUM severity: The `getPriceUSD` function in the `StableOracleDAI` contract returns a price value that is incorrect. The `getPriceUSD` function in the `StableOracleDAI` contract returns a price value that is incorrectly scaled up by a factor of `1e10`, resulting in an unintended 28 decimal places instead of the intended 18. This issue arises from the assumption that the `DAIWethPrice` variable, which is obtained f...

Vulnerable code:
```\nfunction getPriceUSD() external view override returns (uint256) {\n    address[] memory pools = new address[](1);\n    pools[0] = 0x60594a405d53811d3BC4766596EFD80fd545A270;\n    uint256 DAIWethPrice = DAIEthOracle.quoteSpecificPoolsWithTimePeriod(\n        1000000000000000000, // 1 Eth\n        0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2, // WETH (base token)\n        0x6B175474E89094C44Da98b954EedeAC495271d0F, // DAI (quote token)\n        pools, // DAI/WETH pool uni v3\n        600 // period\n    );\n\n    uint256 wethPriceUSD = ethOracle.getPriceUSD();\n\n    uint80 roundID;\n    int256 price;\n    uint256 startedAt;\n    uint256 timeStamp;\n    uint80 answeredInRound;\n    (roundID, price, startedAt, timeStamp, answeredInRound) = priceFeedDAIETH.latestRoundData();\n\n    return (wethPriceUSD * 1e18) / ((DAIWethPrice + uint256(price) * 1e10) / 2);\n}\n```
MEDIUM severity: The vulnerability arises from the arithmetic underflow error that occurs when calculating the `ercDe. The vulnerability arises from the arithmetic underflow error that occurs when calculating the `ercDebtAtOraclePrice` in the `MarginCallSecondaryFacet` contract. This error occurs when the `ercDebtAtOraclePrice` is calculated using the cached Oracle price, which is not updated with the retrieved spot...

Vulnerable code:
```\nfunction getSavedOrSpotOraclePrice(address asset) internal view returns (uint256) {\n    if (LibOrders.getOffsetTime() - getTime(asset) < 15 minutes) {\n        return getPrice(asset);\n    } else {\n        return getOraclePrice(asset);\n    }\n}\n```\n```\nfunction _secondaryLiquidationHelper(MTypes.MarginCallSecondary memory m) private {\n    m.liquidatorCollateral = m.short.collateral;\n    if (m.cRatio > 1 ether) {\n        uint88 ercDebtAtOraclePrice = \n            m.short.ercDebt.mulU88(LibOracle.getPrice(m.asset)); // eth\n        m.liquidatorCollateral = ercDebtAtOraclePrice;\n        if (m.cRatio > m.minimumCR) {\n            address remainingCollateralAddress = m.shorter;\n            s.vaultUser[m.vault][remainingCollateralAddress].ethEscrowed += \n                m.short.collateral - ercDebtAtOraclePrice;\n        } else {\n            address remainingCollateralAddress = address(this);\n            s.vaultUser[m.vault][remainingCollateralAddress].ethEscrowed += \n                m.short.collateral - ercDebtAtOraclePrice;\n        }\n    }\n    LibShortRecord.disburseCollateral(\n        m.asset,\n        m.shorter,\n        m.short.collateral,\n        m.short.zethYieldRate,\n        m.short.updatedAt\n    );\n    LibShortRecord.deleteShortRecord(m.asset, m.shorter, m.short.id);\n}\n```
MEDIUM severity: The vulnerability arises when the reward token is identical to one of the pool tokens, preventing th. The vulnerability arises when the reward token is identical to one of the pool tokens, preventing the protocol from reinvesting such tokens. This issue occurs during the reinvestment process, where the `reinvestReward` function is executed once for each reward token. The `trades` listing must have t...

Vulnerable code:
```\nFile: SingleSidedLPVaultBase.sol\n\nfunction reinvestReward(\n    SingleSidedRewardTradeParams[] calldata trades,\n    uint256 minPoolClaim\n) external whenNotLocked onlyRole(REWARD_REINVESTMENT_ROLE) returns (\n    address rewardToken,\n    uint256 amountSold,\n    uint256 poolClaimAmount\n) {\n    _checkPriceAndCalculateValue();\n\n    require(trades.length == NUM_TOKENS());\n\n    (rewardToken, amountSold, poolClaimAmount) = _executeRewardTrades(trades);\n}\n```\n```\nfunction executeRewardTrades(\n    IERC20[] memory tokens,\n    SingleSidedRewardTradeParams[] calldata trades,\n    address rewardToken,\n    address poolToken\n) external returns (uint256[] memory amounts, uint256 amountSold) {\n    amounts = new uint256[](trades.length);\n    for (uint256 i = 0; i < trades.length; i++) {\n        require(trades[i].sellToken == rewardToken);\n        if (trades[i].amount == 0) continue;\n        if (trades[i].buyToken == poolToken) continue;\n        require(trades[i].buyToken == address(tokens[i]));\n    }\n}\n```\n```\ntokens = [\n    "crvUSD",\n    "WETH",\n    "CRV"\n]\n```\n```\ntrades[0] = {\n    "sellToken": CRV,\n    "buyToken": "crvUSD",\n    "amount": 1000\n}\n\ntrades[1] = {\n    "sellToken": CRV,\n    "buyToken": "WETH",\n    "amount": 1000\n}\n\ntrades[1] = {\n    "sellToken": CRV,\n    "buyToken": "CRV",\n    "amount": 0\n```\n```\nFile: SingleSidedLPVaultBase.sol\n\nfunction _executeRewardTrades(SingleSidedRewardTradeParams[] calldata trades) internal returns (\n    address rewardToken,\n    uint256 amountSold,\n    uint256[] memory amounts\n) {\n    rewardToken = trades[0].sellToken;\n    if (_isInvalidRewardToken(rewardToken)) revert Errors.InvalidRewardToken(rewardToken);\n    (IERC20[] memory tokens, /* */) = TOKENS();\n    (amounts, amountSold) = StrategyUtils.executeRewardTrades(\n        tokens, trades, rewardToken, address(POOL_TOKEN())\n    );\n}\n```\n```\nFile: AuraStakingMixin.sol\n\nfunction _isInvalidRewardToken(address token) internal override view returns (bool) {\n    return (\n        token == TOKEN_1 ||\n        token == TOKEN_2 ||\n        token == TOKEN_3 ||\n        token == TOKEN_4 ||\n        token == TOKEN_5 ||\n        token == address(AURA_BOOSTER) ||\n        token == address(AURA_REWARD_POOL) ||\n        token == address(Deployments.WETH)\n    );\n}\n```\n```\nFile: ConvexStakingMixin.sol\n\nfunction _isInvalidRewardToken(address token) internal override view returns (bool) {\n    return (\n        token == TOKEN_1 ||\n        token == TOKEN_2 ||\n        token == address(CURVE_POOL_TOKEN) ||\n        token == address(CONVEX_REWARD_POOL) ||\n        token == address(CONVEX_BOOSTER) ||\n        token == Deployments.ALT_ETH_ADDRESS\n    );\n}\n```
MEDIUM severity: The existing circuit breaker implementation in the BondBaseSDA.sol contract is flawed, allowing a fa. The existing circuit breaker implementation in the BondBaseSDA.sol contract is flawed, allowing a faster taker to extract payout tokens from the market at an excessive rate. This vulnerability arises when the market maker's debt buffer is breached, yet the market is not immediately closed. Instead,...

Vulnerable code:
```\nFile: BondBaseSDA.sol\n\nif (term.maxDebt < market.totalDebt) {\n    _close(id_);\n} else {\n    // If market will continue, the control variable is tuned to expend remaining capacity over remaining market duration\n    _tune(id_, currentTime, price);\n}\n```
MEDIUM severity: The vulnerability occurs when a vault is removed from the registry, leaving behind an orphaned `_vau. The vulnerability occurs when a vault is removed from the registry, leaving behind an orphaned `_vaultsByType` state. This state is not cleared during the removal process, which can lead to unexpected behavior when attempting to re-add the vault to the registry. Specifically, the `addVault` function...

Vulnerable code:
```\nfunction removeVault(address vaultAddress) external onlyUpdater {\n    Errors.verifyNotZero(vaultAddress, "vaultAddress");\n\n    if (!_vaults.remove(vaultAddress)) {\n        revert VaultNotFound(vaultAddress);\n    }\n\n    address asset = ILMPVault(vaultAddress).asset();\n\n    if (_vaultsByAsset[asset].length() == 1) {\n        _assets.remove(asset);\n    }\n\n    if (!_vaultsByAsset[asset].remove(vaultAddress)) {\n        revert VaultNotFound(vaultAddress);\n    }\n\n    emit VaultRemoved(asset, vaultAddress);\n```\n```\nif (!_vaultsByType[vaultType].add(vaultAddress)) {\n    revert VaultAlreadyExists(vaultAddress);\n}\n```
MEDIUM severity: The DynamicLiquidTokenConverter's `reduceWeight` function is vulnerable to reentrancy attacks due to. The DynamicLiquidTokenConverter's `reduceWeight` function is vulnerable to reentrancy attacks due to an ineffective reentrancy protection mechanism. The function calls the `_protected` function, which is intended to prevent reentrant calls by checking the `locked` state variable. However, this check...

Vulnerable code:
```\nfunction reduceWeight(IERC20Token _reserveToken)\n    public\n    validReserve(_reserveToken)\n    ownerOnly\n{\n    _protected();\n}\n```\n```\ncontract ReentrancyGuard {\n    bool private locked = false;\n\n    // ensures instantiation only by sub-contracts\n    constructor() internal {}\n\n    // protects a function against reentrancy attacks\n    modifier protected() {\n        _protected();\n        locked = true;\n        _;\n        locked = false;\n    }\n\n    // error message binary size optimization\n    function _protected() internal view {\n        require(!locked, "ERR_REENTRANCY");\n    }\n}\n```
MEDIUM severity: This vulnerability allows attackers to drain users over time by donating a negligible amount of ERC2. This vulnerability allows attackers to drain users over time by donating a negligible amount of ERC20 tokens. The issue arises in the Console automation model's DCA (Dollar-Cost Averaging) strategy, which relies on a swapping trigger defined in the `canInitSwap` function.\n\nThe `canInitSwap` functi...

Vulnerable code:
```\nfunction canInitSwap(address subAccount, address inputToken, uint256 interval, uint256 lastSwap)\n    external\n    view\n    returns (bool)\n{\n    if (hasZeroBalance(subAccount, inputToken)) {\n        return false;\n    }\n    return ((lastSwap + interval) < block.timestamp);\n}\n```