Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The `hedgeDelta()` function in the code contains a critical flaw in its dust check mechanism. Specif. The `hedgeDelta()` function in the code contains a critical flaw in its dust check mechanism. Specifically, the check is performed on the `wethBalance` variable, which is not the actual amount used in the transaction. Instead, the actual amount used is `_delta`, which is calculated as the minimum of...

Vulnerable code:
```\nif (inversed) {\n    uint256 wethBalance = amount1Current;\n} else {\n    uint256 wethBalance = amount0Current;\n}\nif (wethBalance < minAmount) {\n    return 0;\n}\n```\n```\nuint256 deltaToUse = _delta > int256(wethBalance)? uint256(wethBalance) : uint256(_delta);\n_createUniswapRangeOrder(rangeOrder, deltaToUse, inversed);\n```
MEDIUM severity: This vulnerability arises from the assumption made by some providers that the protocols will no long. This vulnerability arises from the assumption made by some providers that the protocols will no longer incentivize users with extra rewards. Specifically, certain providers, excluding the `CompoundProvider`, have neglected to claim the `COMP` incentives, leaving the `claim` function empty. This over...

Vulnerable code:
```\nfunction claim(address _aToken, address _claimer) public override returns (bool) {\n    return true;\n}\n```
MEDIUM severity: This vulnerability is related to the inconsistent use of `transfer` and `transferFrom` functions in . This vulnerability is related to the inconsistent use of `transfer` and `transferFrom` functions in the `clear` function. The `transfer` function is used to transfer Ether from the `msg.sender` to the `owner`, whereas the `transferFrom` function is used to transfer Ether from the `msg.sender` to the...

Vulnerable code:
```\nfunction clear(uint256 reqID) external returns (uint256 loanID) {\n    Request storage req = requests[reqID];\n\n    factory.newEvent(reqID, CoolerFactory.Events.Clear);\n\n    if (!req.active) {\n        revert Deactivated();\n    } else {\n        req.active = false;\n\n        uint256 interest = interestFor(req.amount, req.interest, req.duration);\n        uint256 collat = collateralFor(req.amount, req.loanToCollateral);\n        uint256 expiration = block.timestamp + req.duration;\n\n        loanID = loans.length;\n        loans.push(\n            Loan(req, req.amount + interest, collat, expiration, true, msg.sender)\n        );\n        debt.transferFrom(msg.sender, owner, req.amount);\n    }\n}\n```
MEDIUM severity: The vulnerability is related to redundant double casts in the provided smart contract code. Specific. The vulnerability is related to redundant double casts in the provided smart contract code. Specifically, the code is casting variables to their respective contract types, which is unnecessary and can lead to potential issues.\n\nIn the first instance, the `_rocketStorageAddress` variable is already...

Vulnerable code:
```\nconstructor(RocketStorageInterface _rocketStorageAddress) {\n    rocketStorage = RocketStorageInterface(_rocketStorageAddress);\n}\n```\n```\nfunction burnToken(ERC20Burnable _tokenAddress, uint256 _amount) override external onlyLatestNetworkContract {\n    bytes32 contractKey = keccak256(abi.encodePacked(getContractName(msg.sender), _tokenAddress));\n    tokenBalances[contractKey] = tokenBalances[contractKey].sub(_amount);\n    ERC20Burnable tokenContract = ERC20Burnable(_tokenAddress);\n}\n```\n```\nconstructor(RocketStorageInterface _rocketStorageAddress, IERC20 _rocketTokenRPLFixedSupplyAddress) public RocketBase(_rocketStorageAddress) ERC20("Rocket Pool Protocol", "RPL") {\n    version = 1;\n    rplFixedSupplyContract = IERC20(_rocketTokenRPLFixedSupplyAddress);\n}\n```
MEDIUM severity: The Flood mechanism, a critical component of the Beanstalk protocol, is susceptible to a denial-of-s. The Flood mechanism, a critical component of the Beanstalk protocol, is susceptible to a denial-of-service (DoS) attack by a frontrunner. This attack exploits a vulnerability in the `Weather::sop` function, which is responsible for adjusting the Beanstalk Farm's Bean supply when the farm is oversatu...

Vulnerable code:
```\nfunction getDeltaB() internal view returns (int256 deltaB) {\n    uint256[2] memory balances = C.curveMetapool().get_balances();\n    uint256 d = getDFroms(balances);\n    deltaB = getDeltaBWithD(balances[0], d);\n}\n```
MEDIUM severity: The ERC4626-compliant contract, wfCashERC4626, exhibits unexpected behavior when certain functions a. The ERC4626-compliant contract, wfCashERC4626, exhibits unexpected behavior when certain functions are called during a specific time window. This window occurs when the fCash has matured, but the global settlement has not yet been executed. The global settlement is triggered only when the first acco...

Vulnerable code:
```\nFile: wfCashBase.sol\n\nfunction _getMaturedCashValue(uint256 fCashAmount) internal view returns (uint256) {\n    if (!hasMatured()) {\n        return 0;\n    }\n    // If the fCash has matured we use the cash balance instead.\n    (uint16 currencyId, uint40 maturity) = getDecodedID();\n    PrimeRate memory pr = NotionalV2.getSettlementRate(currencyId, maturity);\n\n    // fCash has not yet been settled\n    if (pr.supplyFactor == 0) {\n        return 0;\n    }\n```\n```\nFile: wfCashERC4626.sol\n\nfunction totalAssets() public view override returns (uint256) {\n    if (hasMatured()) {\n        uint256 primeCashValue = _getMaturedCashValue(totalSupply());\n        require(primeCashValue < uint256(type(int256).max);\n        int256 externalValue = NotionalV2.convertCashBalanceToExternal(\n            getCurrencyId(), int256(primeCashValue), true\n        );\n        return externalValue >= 0? uint256(externalValue) : 0;\n    }\n```
MEDIUM severity: The `DepositLog` class, inherited by `TBTCSystem`, lacks access control mechanisms, allowing any ent. The `DepositLog` class, inherited by `TBTCSystem`, lacks access control mechanisms, allowing any entity to emit log events on the `TBTCSystem`. This vulnerability enables unauthorized parties, including users, client-software, or other system components, to manipulate log events, potentially leading...

Vulnerable code:
```\nfunction approvedToLog(address _caller) public pure returns (bool) {\n    return true;\n}\n```
MEDIUM severity: The ChainlinkAggregator's binary search algorithm for finding the roundId with a timestamp closest t. The ChainlinkAggregator's binary search algorithm for finding the roundId with a timestamp closest to the targetTimestamp is flawed. This issue arises when a phase switchover occurs, necessitating the search for a roundId with a timestamp greater than the targetTimestamp. The algorithm's inability t...

Vulnerable code:
```\nminRoundId = 1\nmaxRoundId = 1001\n\nwhile minRoundId + 1 < maxRoundId:\n    maxRoundId = maxRoundId // 2\n    print(f"-> minRoundId={minRoundId}\nmaxRoundId={maxRoundId}")\n\n    minRoundId += 1\n```
MEDIUM severity: The `GMXVault` can be blocked by a malicious actor if they deploy an unpayable contract and make a `. The `GMXVault` can be blocked by a malicious actor if they deploy an unpayable contract and make a `depositNative` call with a high slippage parameter. This allows the malicious actor to cancel the deposit, which will result in the vault being stuck in the `Deposit` state, effectively blocking it fr...

Vulnerable code:
```\nfunction depositNative(GMXTypes.DepositParams memory dp) external payable nonReentrant {\n    GMXDeposit.deposit(_store, dp, true);\n}\n```\n```\n_dc.user = payable(msg.sender)\n```\n```\n(bool success,) = self.depositCache.user.call(\n    value: address(this).balance\n);\nrequire(success, "Transfer failed.");\n```
MEDIUM severity: The `claim()` function in the Vesting.sol contract is vulnerable to reentrancy attacks due to its ex. The `claim()` function in the Vesting.sol contract is vulnerable to reentrancy attacks due to its execution order. The function first checks if the caller has already claimed by verifying if `s.index` has been set to `vestingPoints.length`. However, before updating `s.index`, the function executes a...

Vulnerable code:
```\nfunction claim() external {\n    address sender = msg.sender;\n\n    UserDetails storage s = userdetails[sender];\n    require(s.userDeposit!= 0, "No Deposit");\n    require(s.index!= vestingPoints.length, "already claimed");\n\n    uint256 pctAmount;\n    uint256 i = s.index;\n    for (i; i <= vestingPoints.length - 1; i++) {\n        if (block.timestamp >= vestingPoints[i][0]) {\n            pctAmount += (s.userDeposit * vestingPoints[i][1]) / 10000;\n        } else {\n            break;\n        }\n    }\n\n    if (pctAmount!= 0) {\n        if (address(token) == address(1)) {\n            (bool sent, ) = payable(sender).call{value: pctAmount}("");\n            require(sent, "Failed to send BNB to receiver");\n        } else {\n            token.safeTransfer(sender, pctAmount);\n        }\n        s.index = uint128(i);\n        s.amountClaimed += pctAmount;\n    }\n}\n```
MEDIUM severity: The vulnerability lies in the handling of NFTs that are transferred to a bull contract address that . The vulnerability lies in the handling of NFTs that are transferred to a bull contract address that does not accept ERC721 tokens. When a bull contract address is unable to receive an NFT, the protocol attempts to store the NFT in the `withdrawableCollectionTokenId` mapping for later withdrawal. How...

Vulnerable code:
```\ntry {\n    IERC721(order.collection).safeTransferFrom(bear, bull, tokenId);\n} catch (bytes memory) {\n    IERC721(order.collection).safeTransferFrom(bear, address(this), tokenId);\n    withdrawableCollectionTokenId[order.collection][tokenId] = bull;\n}\n\nuint bearAssetAmount = order.premium + order.collateral;\nif (bearAssetAmount > 0) {\n    IERC20(order.asset).safeTransfer(bear, bearAssetAmount);\n}\n```\n```\nfunction withdrawToken(bytes32 orderHash, uint tokenId) public {\n    address collection = matchedOrders[uint(orderHash)].collection;\n\n    address recipient = withdrawableCollectionTokenId[collection][tokenId];\n\n    // Transfer NFT to recipient\n    IERC721(collection).safeTransferFrom(address(this), recipient, tokenId);\n\n    // This token is not withdrawable anymore\n    withdrawableCollectionTokenId[collection][tokenId] = address(0);\n\n    emit WithdrawnToken(orderHash, tokenId, recipient);\n}\n```
MEDIUM severity: The "Hats can be overwritten" vulnerability allows an attacker to modify the properties of a previou. The "Hats can be overwritten" vulnerability allows an attacker to modify the properties of a previously created and minted hat, which is a critical breach of the immutability principle. This vulnerability arises when a non-existent admin is created, enabling the creation of a child hat with the same...

Vulnerable code:
```\nfunction _createHat(\n    uint256 _id,\n    string calldata _details,\n    uint32 _maxSupply,\n    address _eligibility,\n    address _toggle,\n    bool _mutable,\n    string calldata _imageURI\n) internal returns (Hat memory hat) {\n    hat.details = _details;\n    hat.maxSupply = _maxSupply;\n    hat.eligibility = _eligibility;\n    hat.toggle = _toggle;\n    hat.imageURI = _imageURI;\n    hat.config = _mutable? uint96(3 << 94) : uint96(1 << 95);\n    _hats[_id] = hat;\n\n    emit HatCreated(\n        _id,\n        _details,\n        _maxSupply,\n        _eligibility,\n        _toggle,\n        _mutable,\n        _imageURI\n    );\n}\n```
MEDIUM severity: The vulnerability allows users to deposit "0" ether to any round without incurring additional gas co. The vulnerability allows users to deposit "0" ether to any round without incurring additional gas costs. This is achieved by exploiting the fact that the `depositETHIntoMultipleRounds` function does not increment the `entryIndex` when the deposited amount is "0". This can lead to an unfair winner se...

Vulnerable code:
```\nfor (uint256 i; i < numberOfRounds; ++i) {\n    uint256 roundId = _unsafeAdd(startingRoundId, i);\n    Round storage round = rounds[roundId];\n    uint256 roundValuePerEntry = round.valuePerEntry;\n    if (roundValuePerEntry == 0) {\n        (,, roundValuePerEntry) = _writeDataToRound({roundId: roundId, roundValue: 0});\n    }\n\n    _incrementUserDepositCount(roundId, round);\n\n    uint256 depositAmount = amounts[i];\n\n    if (depositAmount % roundValuePerEntry!= 0) {\n        revert InvalidValue();\n    }\n    uint256 entriesCount = _depositETH(round, roundId, roundValuePerEntry, depositAmount);\n    expectedValue += depositAmount;\n\n    entriesCounts[i] = entriesCount;\n}\n\nif (expectedValue!= msg.value) {\n    revert InvalidValue();\n}\n```\n```\nif (depositAmount % roundValuePerEntry!= 0):\n    revert InvalidValue()\n```\n```\nfunction test_deposit0ToRounds() external {\n    vm.deal(user2, 1 ether);\n    vm.deal(user3, 1 ether);\n\n    // First round starts normally\n    vm.prank(user2);\n    yolo.deposit{value: 1 ether}(1, _emptyDepositsCalldata());\n\n    // User3 will deposit 1 ether to the current round (1) and 0, 0 to round 2 and round 3\n    uint256[] memory amounts = new uint256[](3);\n    amounts[0] = 1 ether;\n    amounts[1] = 0;\n    amounts[2] = 0;\n    vm.prank(user3);\n    yolo.depositETHIntoMultipleRounds{value: 1 ether}(amounts);\n\n    // Check user3 indeed managed to deposit 0 ether to round 2\n    IYoloV2.Deposit[] memory deposits = _getDeposits(2);\n    assertEq(deposits.length, 1);\n    IYoloV2.Deposit memory deposit = deposits[0];\n    assertEq(uint8(deposit.tokenType), uint8(IYoloV2.YoloV2__TokenType.ETH));\n    assertEq(deposit.tokenAddress, address(0));\n    assertEq(deposit.tokenId, 0);\n    assertEq(deposit.tokenAmount, 0);\n    assertEq(deposit.depositor, user3);\n    assertFalse(deposit.withdrawn);\n    assertEq(deposit.currentEntryIndex, 0);\n\n    // Check user3 indeed managed to deposit 0 ether to round 3\n    deposits = _getDeposits(3);\n    assertEq(deposits.length, 1);\n    deposit = deposits[0];\n    assertEq(uint8(deposit.tokenType), uint8(IYoloV2.YoloV2__TokenType.ETH));\n    assertEq(deposit.tokenAddress, address(0));\n    assertEq(deposit.tokenId, 0);\n    assertEq(deposit.tokenAmount, 0);\n    assertEq(deposit.depositor, user3);\n    assertFalse(deposit.withdrawn);\n    assertEq(deposit.currentEntryIndex, 0);\n}\n```
MEDIUM severity: The vulnerability lies in the fee management mechanism of CoW Swap strategies, specifically in the `. The vulnerability lies in the fee management mechanism of CoW Swap strategies, specifically in the `initiateSwap()` function. The fee is set in the strategy contracts and then passed to this function, which is generated by `_buildInitiateSwapExecutable()`. This function is responsible for initiating...

Vulnerable code:
```\nTypes.Executable({\n    callType: Types.CallType.DELEGATECALL,\n    target: dcaCoWAutomation,\n    value: 0,\n    data: abi.encodeCall(\n        DCACoWAutomation.initiateSwap,\n        (params.tokenIn, params.tokenOut, swapRecipient, amountIn, minAmountOut, swapFee)\n    )\n})\n```\n```\nfunction setSwapFee(uint256 _swapFee) external {\n    _onlyGov();\n    if (_swapFee > 10_000) {\n        revert InvalidSlippage();\n    }\n    swapFee = _swapFee;\n}\n\nif (feeBps > 0) {\n    if (feeBps > 1_000) {\n        revert FeeTooHigh();\n    }\n    amountIn = amountToSwap * (MAX_BPS - feeBps) / MAX_BPS;\n```
MEDIUM severity: The vulnerability allows stakers to avoid validator penalties and slashing events by requesting a wi. The vulnerability allows stakers to avoid validator penalties and slashing events by requesting a withdrawal before the TVL drop occurs. This is possible due to the way the `EigenPod::verifyBalanceUpdates()` and `EigenPod::verifyAndProcessWithdrawals()` functions update the `podOwnerShares` variable...

Vulnerable code:
```\nimport { IRioLRTOperatorRegistry } from 'contracts/interfaces/IRioLRTOperatorRegistry.sol';\nimport { RioLRTOperatorDelegator } from 'contracts/restaking/RioLRTOperatorDelegator.sol';\nimport { CredentialsProofs, BeaconWithdrawal } from 'test/utils/beacon-chain/MockBeaconChain.sol';\n```\n```\nIRioLRTOperatorRegistry.StrategyShareCap[] public emptyStrategyShareCaps;\n\nfunction test_avoidInstantPriceDrop() public {\n    // Add two operators with 1 validator each\n    uint8[] memory operatorIds = addOperatorDelegators(\n        reETH.operatorRegistry,\n        address(reETH.rewardDistributor),\n        2,\n        emptyStrategyShareCaps,\n        1\n    );\n    address operatorAddress0 = address(uint160(1));\n\n    // Deposit ETH so there's 74ETH in the deposit pool\n    uint256 depositAmount = 2 * ETH_DEPOSIT_SIZE - address(reETH.depositPool).balance;\n    uint256 amountToWithdraw = 10 ether;\n    reETH.coordinator.depositETH{value: amountToWithdraw + depositAmount}();\n\n    // Stake the 64ETH on the validators, 32ETH each and 10 ETH stay in the deposit pool\n    vm.prank(EOA, EOA);\n    reETH.coordinator.rebalance(ETH_ADDRESS);\n\n    // Attacker notices a validator is going receive penalties and immediately requests a withdrawal of 10ETH\n    reETH.coordinator.requestWithdrawal(ETH_ADDRESS, amountToWithdraw);\n\n    // Validator gets some penalties and Eigenlayer notified\n    // IMPORTANT: The following block of code is a simulation of what would happen if a validator balances gets lowered because of penalties\n    // and `verifyBalanceUpdates()` gets called on Eigenlayer. It uses another bug to achieve an instant loss of TVL.\n\n    // ~~~Start penalties simulation~~~\n    {\n        // Verify validators credentials of the two validators\n        verifyCredentialsForValidators(reETH.operatorRegistry, 1, 1);\n        verifyCredentialsForValidators(reETH.operatorRegistry, 2, 1);\n\n        // Cache current TVL and ETH Balance\n        uint256 TVLBefore = reETH.coordinator.getTVL();\n\n        // Operator calls `undelegate()` on Eigenlayer\n        // IMPORTANT: This achieves the same as calling `verifyBalanceUpdates()` on Eigenlayer after a validator suffered penalties,\n        // an instant drop in TVL.\n        IRioLRTOperatorRegistry.OperatorPublicDetails memory details = reETH.operatorRegistry.getOperatorDetails(operatorIds[0]);\n        vm.prank(operatorAddress0);\n        delegationManager.undelegate(details.delegator);\n\n        // TVL dropped\n        uint256 TVLAfter = reETH.coordinator.getTVL();\n\n        assertLt(TVLAfter, TVLBefore);\n    }\n```
MEDIUM severity: This vulnerability allows an attacker to prevent a liquidation transaction from being executed by fr. This vulnerability allows an attacker to prevent a liquidation transaction from being executed by frontrunning the transaction and slightly modifying their position to cause the liquidation amount to exceed the maximum allowed. The attacker can achieve this by increasing their collateral or decreasi...

Vulnerable code:
```\nfunction liquidate(\n    address _account,\n    uint256 _debtAmount,\n    uint256 _minExchangeRate\n) external onlyLiquidator whenNotPaused updateReward(_account) returns (bool) {\n    if (_debtAmount == 0) {\n        revert wrongLiquidationAmount();\n    }\n\n    UserDetails memory accDetails = userDetails[_account];\n\n    if (_debtAmount > accDetails.debt) {\n        _debtAmount = accDetails.debt;\n    }\n\n    (uint256 collateralToLiquidate, uint256 liquidationSurcharge) = _calcLiquidation(\n        accDetails.collateral,\n        accDetails.debt,\n        _debtAmount\n    );\n```\n```\nfunction _calcLiquidation(\n    uint256 _accountCollateral,\n    uint256 _accountDebt,\n    uint256 _debtToLiquidate\n) internal view returns (uint256 collateralToLiquidate, uint256 liquidationSurcharge) {\n    if (_debtToLiquidate > _getMaxLiquidation(_accountCollateral, _accountDebt, price, decimals, totalLiquidationDiscount)) {\n        revert wrongLiquidationAmount();\n    }\n    // rest of code\n```\n```\nfunction _getMaxLiquidation(\n    uint256 _collateral,\n    uint256 _debt,\n    uint256 _price,\n    uint8 _decimals,\n    uint256 _liquidationDiscount\n) internal pure returns (uint256 maxRepay) {\n    maxRepay = \n        ((MAX_LIQ_COLL_RATIO * _debt) - ((_collateral * _price * Constants.PRECISION) / (10 ** _decimals))) /\n        (MAX_LIQ_COLL_RATIO - _liquidationDiscount);\n\n    if (maxRepay > _debt) {\n        maxRepay = _debt;\n    }\n\n    return maxRepay;\n```
MEDIUM severity: The Oracle Slippage Rate setting, `oraclePriceDeviationLimitPercent`, is intended to determine the a. The Oracle Slippage Rate setting, `oraclePriceDeviationLimitPercent`, is intended to determine the acceptable deviation between the spot and oracle prices for the purpose of comparing the spot price with the oracle price in the `_checkPriceLimit` function. This setting is crucial for ensuring the ac...

Vulnerable code:
```\nfunction _checkPriceLimit(\n    StrategyContext memory strategyContext,\n    uint256 oraclePrice,\n    uint256 poolPrice\n) internal pure {\n    uint256 lowerLimit = (oraclePrice * \n        (VaultConstants.VAULT_PERCENT_BASIS - \n            strategyContext.vaultSettings.oraclePriceDeviationLimitPercent)) / \n        VaultConstants.VAULT_PERCENT_BASIS;\n    uint256 upperLimit = (oraclePrice * \n        (VaultConstants.VAULT_PERCENT_BASIS + \n            strategyContext.vaultSettings.oraclePriceDeviationLimitPercent)) / \n        VaultConstants.VAULT_PERCENT_BASIS;\n\n    if (poolPrice < lowerLimit || upperLimit < poolPrice) {\n        revert Errors.InvalidPrice(oraclePrice, poolPrice);\n    }\n}\n```\n```\nFile: Curve2TokenPoolUtils.sol\n\nfunction _checkPrimarySecondaryRatio(\n    StrategyContext memory strategyContext,\n    uint256 primaryAmount,\n    uint256 secondaryAmount,\n    uint256 primaryPoolBalance,\n    uint256 secondaryPoolBalance\n) private pure {\n    uint256 totalAmount = primaryAmount + secondaryAmount;\n    uint256 totalPoolBalance = primaryPoolBalance + secondaryPoolBalance;\n\n    uint256 primaryPercentage = primaryAmount * CurveConstants.CURVE_PRECISION / totalAmount;\n    uint256 expectedPrimaryPercentage = primaryPoolBalance * CurveConstants.CURVE_PRECISION / totalPoolBalance;\n\n    strategyContext._checkPriceLimit(expectedPrimaryPercentage, primaryPercentage);\n\n    uint256 secondaryPercentage = secondaryAmount * CurveConstants.CURVE_PRECISION / totalAmount;\n    uint256 expectedSecondaryPercentage = secondaryPoolBalance * CurveConstants.CURVE_PRECISION / totalPoolBalance;\n\n    strategyContext._checkPriceLimit(expectedSecondaryPercentage, secondaryPercentage);\n}\n```
MEDIUM severity: The `_calculateClaim()` function is responsible for calculating the amount of emissions a specific v. The `_calculateClaim()` function is responsible for calculating the amount of emissions a specific veSatin is entitled to claim. The function is designed to distribute emissions only to veSatin tokens that have been locked for a duration exceeding the minimum lock duration for reward, `minLockDurati...

Vulnerable code:
```\nif ((lockEndTime - oldUserPoint.ts) > (minLockDurationForReward)):\n    toDistribute += (balanceOf * tokensPerWeek[weekCursor]) / veSupply[weekCursor]\n    weekCursor += WEEK\n```
MEDIUM severity: The vulnerability lies in the implementation of the `borrowSecondaryCurrencyToVault` function, which. The vulnerability lies in the implementation of the `borrowSecondaryCurrencyToVault` function, which restricts vaults from borrowing single secondary currencies. The function utilizes a `require` statement to ensure that both secondary currencies are whitelisted in the `VaultConfig.secondaryBorrowCu...

Vulnerable code:
```\nrequire(\n    currencies[0]!= 0 &&\n    currencies[1]!= 0\n);\n```