Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The vulnerability lies in the implementation of the `transmuteInstant()` function in the TokenTransm. The vulnerability lies in the implementation of the `transmuteInstant()` function in the TokenTransmuter contract. Unlike the `transmuteLinear()` function, which checks the availability of output tokens before accepting input tokens, `transmuteInstant()` does not perform any checks, allowing an atta...

Vulnerable code:
```\nrequire(\n    IERC20(outputTokenAddress).balanceOf(address(this)) >= \n    (totalAllocatedOutputToken - totalReleasedOutputToken), \n    "INSUFFICIENT_OUTPUT_TOKEN"\n);\nIERC20(inputTokenAddress).transferFrom(msg.sender, address(0), _inputTokenAmount);\n```\n```\nIERC20(inputTokenAddress).transferFrom(msg.sender, address(0), \n    _inputTokenAmount);\n\nSafeERC20.safeTransfer(IERC20(outputTokenAddress), msg.sender, \n    allocation);\n\nemit OutputTokenInstantReleased(msg.sender, allocation, \n    outputTokenAddress);\n```
MEDIUM severity: The vulnerability arises from the lack of explicit separation between ERC20 and ERC721 deposits, all. The vulnerability arises from the lack of explicit separation between ERC20 and ERC721 deposits, allowing users to exploit the system by utilizing whitelisted ERC20 tokens with a price greater than the round's `valuePerEntry`. This enables users to gain free entries for any round, as the system does...

Vulnerable code:
```\nif (isCurrencyAllowed[tokenAddress]!= 1) {\n    revert InvalidCollection();\n}\n```\n```\nif (singleDeposit.tokenType == YoloV2__TokenType.ERC721) {\n    if (price == 0) {\n        price = _getReservoirPrice(singleDeposit);\n        prices[tokenAddress][roundId] = price;\n    }\n```\n```\nuint256 entriesCount = price / round.valuePerEntry;\nif (entriesCount == 0) {\n    revert InvalidValue();\n}\n```\n```\nelse if (tokenType == TokenType.ERC721) {\n    for (uint256 j; j < itemIdsLengthForSingleCollection; ) {\n        _executeERC721TransferFrom(items[i].tokenAddress, from, to, itemIds[j]);\n        j++;\n    }\n```\n```\nfunction _executeERC721TransferFrom(address collection, address from, address to, uint256 tokenId) internal {\n    (bool status, ) = collection.call(abi.encodeCall(IERC721.transferFrom, (from, to, tokenId)));\n}\n```
MEDIUM severity: The vulnerability arises when the `sendFundsToVault()` function attempts to retrieve the balance of . The vulnerability arises when the `sendFundsToVault()` function attempts to retrieve the balance of a token on a different blockchain network than the one where the `XChainController` contract is deployed. Specifically, when `_chainId` is set to Optimism (L2), the `underlying` address is intended to...

Vulnerable code:
```\naddress underlying = getUnderlyingAddress(_vaultNumber, _chain);\nuint256 balance = IERC20(underlying).balanceOf(address(this));\n```
MEDIUM severity: The `batch_verify_multi_points` function in the code fails to properly verify the pairing check resu. The `batch_verify_multi_points` function in the code fails to properly verify the pairing check result, which can lead to the acceptance of invalid proofs. The pairing check is performed by calling the `staticcall` function, which returns a value stored in the `l_success` variable. However, the actu...

Vulnerable code:
```\nlet l_success := staticcall(sub(gas(), 2000), 8, mPtr, 0x180, 0x00, 0x20)\nmstore(add(state, state_success), and(l_success, mload(add(state, state_success))))\n```
MEDIUM severity: The ERC777 token implementation, as used in the Amp token, introduces a potential reentrancy attack . The ERC777 token implementation, as used in the Amp token, introduces a potential reentrancy attack vector. This vulnerability arises from the use of hooks to communicate with the Collateral manager, which, although trusted, can still be exploited. Specifically, a malicious actor can manipulate the...

Vulnerable code:
```\nrequire(\n    _balanceOfByPartition[_from][_fromPartition] >= _value,\n    EC_52_INSUFFICIENT_BALANCE\n);\n\nbytes32 toPartition = _fromPartition;\nif (_data.length >= 64) {\n    toPartition = _getDestinationPartition(_fromPartition, _data);\n}\n\n_callPreTransferHooks(\n    _fromPartition,\n    _operator,\n    _from,\n    _to,\n    _value,\n    _data,\n    _operatorData\n);\n\n_removeTokenFromPartition(_from, _fromPartition, _value);\n_transfer(_from, _to, _value);\n_addTokenToPartition(_to, toPartition, _value);\n\n_callPostTransferHooks(\n    toPartition,\n```
MEDIUM severity: The `linearMultiplier` and `instantMultiplier` variables, used in the `transmute` functions, are imp. The `linearMultiplier` and `instantMultiplier` variables, used in the `transmute` functions, are implemented as `uint256` data types, which restrict their ability to perform division operations on the `_inputTokenAmount`. This limitation arises from the fact that `uint256` variables can only perform...

Vulnerable code:
```\nuint256 allocation = (_inputTokenAmount * linearMultiplier) / tokenDecimalDivider;\n...\nuint256 allocation = (_inputTokenAmount * instantMultiplier) / tokenDecimalDivider;\n```
MEDIUM severity: The `Marketplace.setPrincipal` function is used to provide a principal token for the base token and . The `Marketplace.setPrincipal` function is used to provide a principal token for the base token and maturity when it has not been set yet. This function also requires specifying the protocol that the token belongs to. In the case of the `APWine` protocol, there is a specific block of code that handl...

Vulnerable code:
```\nelse if (p == uint8(Principals.Apwine)) {\n    address futureVault = IAPWineToken(a).futureVault();\n    address interestBearingToken = IAPWineFutureVault(futureVault).getIBTAddress();\n    IRedeemer(redeemer).approve(interestBearingToken);\n} else if (p == uint8(Principals.Notional)) {\n```
MEDIUM severity: This vulnerability is related to an unnecessary type correction in the `hash256` function, which is . This vulnerability is related to an unnecessary type correction in the `hash256` function, which is used to calculate the SHA-256 hash of a given input. The function is designed to return a `bytes32` value, which is the expected output of the SHA-256 algorithm.\n\nThe issue arises from the use of th...

Vulnerable code:
```\nfunction hash256(bytes memory _b) internal pure returns (bytes32) {\n    return abi.encodePacked(sha256(abi.encodePacked(_b))).toBytes32();\n}\n```
MEDIUM severity: The Token Overflow vulnerability is a critical issue that can lead to system halt or loss of funds. . The Token Overflow vulnerability is a critical issue that can lead to system halt or loss of funds. It occurs when the token supply is artificially inflated to an extremely large value, causing the safeMath reverts in functions such as `processProposal` and `cancelProposal` to fail. This can result...

Vulnerable code:
```\nfunction max(uint256 x, uint256 y) internal pure returns (uint256) {\n    return x >= y? x : y;\n}\n```
MEDIUM severity: This vulnerability occurs when a batch is canceled, resulting in the failure to return fees paid by . This vulnerability occurs when a batch is canceled, resulting in the failure to return fees paid by traders for buy orders. The issue arises from the fact that the beneficiary account is not accessible when the batch is canceled, thereby preventing the return of fees. In contrast, fees for sell orde...

Vulnerable code:
```\nuint256 fee = _value.mul(buyFeePct).div(PCT_BASE);\nuint256 value = _value.sub(fee);\n\nif (fee > 0) {\n    _transfer(_buyer, beneficiary, _collateral, fee);\n}\n_transfer(_buyer, address(reserve), _collateral, value);\n```
MEDIUM severity: The `emergencyClosePosition` function in the `PartyBFacetImpl` contract can be exploited by PartyA t. The `emergencyClosePosition` function in the `PartyBFacetImpl` contract can be exploited by PartyA to block PartyB's ability to close positions in emergency situations. This is achieved by manipulating the position's status to `QuoteStatus.CLOSE_PENDING` before PartyB can execute the `emergencyClose...

Vulnerable code:
```\nFile: PartyBFacetImpl.sol\n\nfunction emergencyClosePosition(uint256 quoteId, PairUpnlAndPriceSig memory upnlSig) internal {\n    AccountStorage.Layout storage accountLayout = AccountStorage.layout();\n    Quote storage quote = QuoteStorage.layout().quotes[quoteId];\n    require(quote.quoteStatus == QuoteStatus.OPENED, "PartyBFacet: Invalid state");\n\n    //...SNIP...\n```
MEDIUM severity: When a market is removed from a vault by setting its weight to 0, the vault's leverage in that marke. When a market is removed from a vault by setting its weight to 0, the vault's leverage in that market is unexpectedly set to its maximum possible value, putting the vault's position at risk of liquidation. This occurs because the vault's rebalancing process, which is triggered by the removal of the...

Vulnerable code:
```\nmarketCollateral = marketContext.margin\n   .add(collateral.sub(totalMargin).mul(marketContext.registration.weight));\n\nUFixed6 marketAssets = assets\n   .mul(marketContext.registration.weight)\n   .min(marketCollateral.mul(LEVERAGE_BUFFER));\n```\n```\ntarget.position = \n    marketAssets\n       .muldiv(marketContext.registration.leverage, marketContext.latestPrice.abs())\n       .max(marketContext.minPosition)\n       .min(marketContext.maxPosition);\n```\n```\nit('simple deposits and redemptions', async () => {\n  // Now we should have opened positions.\n  // The positions should be equal to (smallDeposit + largeDeposit) * leverage originalOraclePrice.\n  expect(await position()).to.equal(\n    smallDeposit.add(largeDeposit).mul(leverage).mul(4).div(5).div(originalOraclePrice),\n  );\n  expect(await btcPosition()).to.equal(\n    smallDeposit.add(largeDeposit).mul(leverage).div(5).div(btcOriginalOraclePrice),\n  );\n\n  console.log("pos1 = " + (await position()) + " pos2 = " + (await btcPosition()) + " col1 = " + (await collateralInVault()) + " col2 = " + (await btcCollateralInVault()));\n\n  // update weight\n  await vault.connect(owner).updateWeights([parse6decimal('1.0'), parse6decimal('0')]);\n\n  // do small withdrawal to trigger rebalance\n  await vault.connect(user).update(user.address, 0, smallDeposit, 0);\n  await updateOracle();\n\n  console.log("pos1 = " + (await position()) + " pos2 = " + (await btcPosition()) + " col1 = " + (await collateralInVault()) + " col2 = " + (await btcCollateralInVault()));\n})\n```\n```\npos1 = 12224846\npos2 = 206187\ncol1 = 8008000000\ncol2 = 2002000000\n\npos1 = 12224846\npos2 = 206187\ncol1 = 9209203452\ncol2 = 800796548\n```
MEDIUM severity: The vulnerability arises when a malicious recipient is added to the USDC blacklist, rendering the `c. The vulnerability arises when a malicious recipient is added to the USDC blacklist, rendering the `cancel()` function ineffective. This function is intended to send the vested USDC to the recipient and cancel future payments. However, if the recipient is blacklisted, the `cancel()` function will not...

Vulnerable code:
```\nfunction cancel() external onlyPayerOrRecipient {\n    address payer_ = payer();\n    address recipient_ = recipient();\n    IERC20 token_ = token();\n\n    uint256 recipientBalance = balanceOf(recipient_);\n\n    // This zeroing is important because without it, it's possible for recipient to obtain additional funds\n    // from this contract if anyone (e.g. payer) sends it tokens after cancellation.\n    remainingBalance = 0;\n\n    if (recipientBalance > 0) {\n        token_.safeTransfer(recipient_, recipientBalance);\n    }\n}\n```
MEDIUM severity: The `universalReceiver()` function in the LSP0 implementation deviates from the specification by con. The `universalReceiver()` function in the LSP0 implementation deviates from the specification by constructing a mapping key that may lead to the dislocation of the receiver delegate. The function generates a key using the `LSP2Utils.generateMappingKey()` method, which combines a 10-byte prefix, two...

Vulnerable code:
```\nbytes32 lsp1typeIdDelegateKey = LSP2Utils.generateMappingKey(\n    _LSP1_UNIVERSAL_RECEIVER_DELEGATE_PREFIX, bytes20(typeId));\n```
MEDIUM severity: The `_collectFees` function in the LMPVault protocol is vulnerable to a manipulation attack that can. The `_collectFees` function in the LMPVault protocol is vulnerable to a manipulation attack that can result in the loss of fees. The function only collects fees when the NAV/Share exceeds the last recorded NAV/Share, which can be exploited by malicious users to lock in the NAV/Share at a high value,...

Vulnerable code:
```\nfunction _collectFees(uint256 idle, uint256 debt, uint256 totalSupply) internal {\n    address sink = feeSink;\n    uint256 fees = 0;\n    uint256 shares = 0;\n    uint256 profit = 0;\n\n    if (totalSupply == 0) {\n        return;\n    }\n\n    uint256 currentNavPerShare = ((idle + debt) * MAX_FEE_BPS) / totalSupply;\n    uint256 effectiveNavPerShareHighMark = navPerShareHighMark;\n\n    if (currentNavPerShare > effectiveNavPerShareHighMark) {\n        profit = (currentNavPerShare - effectiveNavPerShareHighMark) * totalSupply;\n        fees = profit.mulDiv(performanceFeeBps, (MAX_FEE_BPS ** 2), Math.Rounding.Up);\n        if (fees > 0 && sink!= address(0)) {\n            shares = _convertToShares(fees, Math.Rounding.Up);\n            _mint(sink, shares);\n            emit Deposit(address(this), sink, fees, shares);\n        }\n        navPerShareHighMark = currentNavPerShare;\n        navPerShareHighMarkTimestamp = block.timestamp;\n        emit NewNavHighWatermark(currentNavPerShare, block.timestamp);\n    }\n    emit FeeCollected(fees, sink, shares, profit, idle, debt);\n}\n```
MEDIUM severity: The vulnerability in ERC5095 lies in the lack of approval for the MarketPlace to spend tokens before. The vulnerability in ERC5095 lies in the lack of approval for the MarketPlace to spend tokens before calling the `sellUnderlying` or `sellPrincipalToken` functions. These functions are responsible for transferring tokens from the msg.sender to the pool, which requires the MarketPlace to have been ap...

Vulnerable code:
```\nfunction sellUnderlying(\n    address u,\n    uint256 m,\n    uint128 a,\n    uint128 s\n) external returns (uint128) {\n    IPool pool = IPool(pools[u][m]);\n\n    uint128 expected = pool.sellBasePreview(a);\n\n    if (expected < s) {\n        revert Exception(16, expected, 0, address(0), address(0));\n    }\n\n    Safe.transferFrom(IERC20(pool.base()), msg.sender, address(pool), a);\n}\n\nfunction sellPrincipalToken(\n    address u,\n    uint256 m,\n    uint128 a,\n    uint128 s\n) external returns (uint128) {\n    IPool pool = IPool(pools[u][m]);\n\n    uint256 expected = pool.sellFYTokenPreview(a);\n\n    if (expected < s) {\n        revert Exception(16, expected, s, address(0), address(0));\n    }\n\n    Safe.transferFrom(\n        IERC20(address(pool.fyToken())),\n        msg.sender,\n        address(pool),\n        a\n    );\n}\n```\n```\nvm.startPrank(address(token))\nIERC20(Contracts.USDC).approve(address(marketplace), type(uint256).max)\nIERC20(Contracts.YIELD_TOKEN).approve(\n    address(marketplace),\n    type(uint256).max\n)\n```
MEDIUM severity: The BoundedStepwiseExponentialPriceAdapter contract's implementation of the price change calculation. The BoundedStepwiseExponentialPriceAdapter contract's implementation of the price change calculation is flawed due to a mathematical error. The intended formula, `scalingFactor * (e^x - 1)`, is incorrectly implemented as `scalingFactor * e^x - 1`. This discrepancy arises from the lack of parentheses...

Vulnerable code:
```\n(\n    uint256 initialPrice,\n    uint256 scalingFactor,\n    uint256 timeCoefficient,\n    uint256 bucketSize,\n    bool isDecreasing,\n    uint256 maxPrice,\n    uint256 minPrice\n) = getDecodedData(_priceAdapterConfigData);\n\nuint256 timeBucket = _timeElapsed / bucketSize;\n\nint256 expArgument = int256(timeCoefficient * timeBucket);\n\nuint256 expExpression = uint256(FixedPointMathLib.expWad(expArgument));\n\nuint256 priceChange = scalingFactor * expExpression - WAD;\n```
MEDIUM severity: The `RewardsDistributor` contract's `claimRewards()` function allows users to claim their rewards fo. The `RewardsDistributor` contract's `claimRewards()` function allows users to claim their rewards for a specific epoch. While the function checks if the user has already claimed rewards for that epoch, it does not verify if the user has any associated rewards at all. This oversight can lead to the `...

Vulnerable code:
```\nfor (uint256 i = 0; i < epochNumbers.length; i++) {\n    if (_claimedRewardsPerEpoch[shareId][epochNumbers[i]][_msgSender()]) {\n        revert AlreadyClaimed();\n    }\n    _claimedRewardsPerEpoch[shareId][epochNumbers[i]][_msgSender()] = true;\n    uint256 epochRewards = _availableReward(shareId, isDelegator, epochNumbers[i], _msgSender());\n    SafeERC20.safeTransfer(rewardsToken, _msgSender(), epochRewards);\n    emit ClaimedRewards(subjectType, subjectId, _msgSender(), epochNumbers[i], epochRewards);\n```
MEDIUM severity: The `TOFT::sendPacket` function in the TOFT contract allows the caller to specify multiple messages . The `TOFT::sendPacket` function in the TOFT contract allows the caller to specify multiple messages that are executed on the destination chain. The `lzCompose` function is responsible for processing these messages, including the approval message. However, this approval message can be front-run by an...

Vulnerable code:
```\nfunction sendPacket(LZSendParam calldata _lzSendParam, bytes calldata _composeMsg)\n    public\n    payable\n    whenNotPaused\n    returns (MessagingReceipt memory msgReceipt, OFTReceipt memory oftReceipt)\n{\n    (msgReceipt, oftReceipt) = abi.decode(\n        _executeModule(\n            uint8(ITOFT.Module.TOFTSender),\n            abi.encodeCall(TapiocaOmnichainSender.sendPacket, (_lzSendParam, _composeMsg)),\n            false\n        ),\n        (MessagingReceipt, OFTReceipt)\n    );\n}\n```\n```\nfunction _lzCompose(address srcChainSender_, bytes32 _guid, bytes memory oftComposeMsg_) internal {\n    // Decode OFT compose message.\n    (uint16 msgType_,, bytes memory tapComposeMsg_, bytes memory nextMsg_) = \n        TapiocaOmnichainEngineCodec.decodeToeComposeMsg(oftComposeMsg_);\n\n    if (msgType_ == MSG_REMOTE_TRANSFER) {\n        _remoteTransferReceiver(srcChainSender_, tapComposeMsg_);\n    } else if (!_extExec(msgType_, tapComposeMsg_)) {\n        if (\n            address(tapiocaOmnichainReceiveExtender)!= address(0) \n                && tapiocaOmnichainReceiveExtender.isMsgTypeValid(msgType_)\n        ) {\n            bytes memory callData = abi.encodeWithSelector(\n                ITapiocaOmnichainReceiveExtender.toeComposeReceiver.selector, \n                msgType_, \n                srcChainSender_, \n                tapComposeMsg_\n            );\n            (bool success, bytes memory returnData) = \n                address(tapiocaOmnichainReceiveExtender).delegatecall(callData);\n            if (!success) {\n                revert(_getTOEExtenderRevertMsg(returnData));\n            }\n        } else {\n            if (!_toeComposeReceiver(msgType_, srcChainSender_, tapComposeMsg_)) {\n                revert InvalidMsgType(msgType_);\n            }\n        }\n    }\n\n    emit ComposeReceived(msgType_, _guid, tapComposeMsg_);\n    if (nextMsg_.length > 0) {\n        _lzCompose(address(this), _guid, nextMsg_);\n    }\n}\n```
MEDIUM severity: The `_withdrawFromPlugin()` function in the rebalancing mechanism is vulnerable to a potential issue. The `_withdrawFromPlugin()` function in the rebalancing mechanism is vulnerable to a potential issue when `_withdrawalValues[i]` equals 0. In this scenario, the function is intended to skip rebalancing the plugin, as indicated by the condition `_withdrawalValues[i] == 0`. However, the current implem...

Vulnerable code:
```\nfunction validateWithdraw(\n    address reserveAddress,\n    uint256 amount,\n    uint256 userBalance,\n    mapping(address => DataTypes.ReserveData) storage reservesData,\n    DataTypes.UserConfigurationMap storage userConfig,\n    mapping(uint256 => address) storage reserves,\n    uint256 reservesCount,\n    address oracle\n) external view {\n    require(amount!= 0, Errors.VL_INVALID_AMOUNT);\n```
MEDIUM severity: The `withdraw` function in the strategy contracts is vulnerable to unexpected token amounts being re. The `withdraw` function in the strategy contracts is vulnerable to unexpected token amounts being returned. This occurs when the function calculates the expected amount of tokens to be withdrawn, but does not verify whether the actual amount transferred to the contract matches the expected amount. T...

Vulnerable code:
```\nfunction withdraw(uint256 _shares, uint256 _minAmount) external onlyEOAorWhitelist nonReentrant {\n    address _from = msg.sender;\n    (uint256 _amount, uint256 _withdrawalAmount, uint256 _netAmount) = _calcAmountFromShares(_shares);\n    require(_netAmount >= _minAmount, "high slippage");\n    _burn(_from, _shares);\n    _withdraw(_amount);\n    Transfers._pushFunds(reserveToken, _from, _withdrawalAmount);\n}\n```
MEDIUM severity: The UniswapV3NPM contract allows users to increase liquidity to any NFT, which can be exploited by a. The UniswapV3NPM contract allows users to increase liquidity to any NFT, which can be exploited by an attacker to prevent a position from being closed. When a position is being redeemed, the contract only decreases the initial liquidity of the NFT and then burns it. However, if the liquidity of the...

Vulnerable code:
```\nfunction increaseLiquidity(IncreaseLiquidityParams calldata params)\n    external\n    payable\n    override\n    checkDeadline(params.deadline)\n    returns (uint128 liquidity, uint256 amount0, uint256 amount1)\n{\n    Position storage position = _positions[params.tokenId];\n    PoolAddress.PoolKey memory poolKey = _poolIdToPoolKey[position.poolId];\n    IUniswapV3Pool pool;\n    (liquidity, amount0, amount1, pool) = addLiquidity(\n```\n```\nfunction _redeemPosition(\n    address _user, uint _posId\n) internal override returns (address[] memory rewardTokens, uint[] memory rewardAmts) {\n    address _positionManager = positionManager;\n    uint128 collAmt = IUniswapV3PositionManager(_positionManager).getPositionCollAmt(_user, _posId);\n\n    // 1. take lp & extra coll tokens from lending proxy\n    _takeAllCollTokens(_positionManager, _user, _posId, address(this));\n\n    UniV3ExtraPosInfo memory extraPosInfo = IUniswapV3PositionManager(_positionManager).getDecodedExtraPosInfo(_user, _posId);\n    address _uniswapV3NPM = uniswapV3NPM; // gas saving\n\n    // 2. remove underlying tokens from lp (internal remove in NPM)\n    IUniswapV3NPM(_uniswapV3NPM).decreaseLiquidity(\n        IUniswapV3NPM.DecreaseLiquidityParams({\n            tokenId: extraPosInfo.uniV3PositionId,\n            liquidity: collAmt,\n            amount0Min: 0,\n            amount1Min: 0,\n            deadline: block.timestamp\n        }\n    ));\n\n    // 3. burn LP position\n    IUniswapV3NPM(_uniswapV3NPM).burn(extraPosInfo.uniV3PositionId);\n}\n```\n```\nfunction burn(uint256 tokenId) external payable override isAuthorizedForToken(tokenId) {\n    Position storage position = _positions[tokenId];\n\n    require(position.liquidity == 0 && position.tokensOwed0 == 0 && position.tokensOwed1 == 0, 'Not cleared');\n\n    delete _positions[tokenId];\n    _burn(tokenId);\n}\n```
MEDIUM severity: The `ForgePropsMulti` struct contains an unused `isValid` field, which is always set to `true`. This. The `ForgePropsMulti` struct contains an unused `isValid` field, which is always set to `true`. This field is intended to serve as a flag indicating that the associated `bAssets` have passed a validity check. However, the code does not utilize this field in a meaningful way, as the conditional state...

Vulnerable code:
```\n/**\n * @dev All details needed to Forge with multiple bAssets\n */\nstruct ForgePropsMulti {\n    bool isValid; // Flag to signify that forge bAssets have passed validity check\n    Basset[] bAssets;\n    address[] integrators;\n    uint8[] indexes;\n}\n```\n```\nif (!props.isValid):\n    return 0\n```