Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The `claimExecutionFees` modifier in the Console automation allows users to drain the Gelato deposit. The `claimExecutionFees` modifier in the Console automation allows users to drain the Gelato deposit at a relatively low cost. This vulnerability occurs when the `feeMultiplier` is greater than zero, which enables the user to claim the execution fees associated with the gas used during the execution...

Vulnerable code:
```\nmodifier claimExecutionFees(address _wallet) {\n    uint256 startGas = gasleft();\n    if (feeMultiplier > 0) {\n        address feeToken = FeePayer._feeToken(_wallet);\n        uint256 gasUsed = startGas - gasleft();\n        (uint256 feeAmount, address recipient, Types.Executable memory feeTransferTxn) = FeePayer._buildFeeExecutable(gasUsed, feeToken);\n        emit FeeClaimed(_wallet, feeToken, feeAmount);\n        if (feeToken!= ETH) {\n            uint256 initialBalance = IERC20(feeToken).balanceOf(recipient);\n            executeSafeERC20Transfer(_wallet, feeTransferTxn);\n            if (IERC20(feeToken).balanceOf(recipient) - initialBalance < feeAmount) {\n                revert UnsuccessfulFeeTransfer(_wallet, feeToken);\n            }\n        } else {\n            uint256 initialBalance = recipient.balance;\n            Executor._executeOnWallet(_wallet, feeTransferTxn);\n            if (recipient.balance - initialBalance < feeAmount) {\n                revert UnsuccessfulFeeTransfer(_wallet, feeToken);\n            }\n        }\n    }\n}\n```
MEDIUM severity: The vulnerability arises from the potential for `rebalance()` to be executed before funds are actual. The vulnerability arises from the potential for `rebalance()` to be executed before funds are actually transferred from the xChainController to the vault. This can occur when `pushFeedbackToVault()` is invoked successfully before `xTransfer()` has completed its transfer of funds. \n\nThe `pushFeedba...

Vulnerable code:
```\npushFeedbackToVault(_chainId, _vault, _relayerFee);\nxTransfer(_asset, _amount, _vault, _chainId, _slippage, _relayerFee);\n```\n```\nAll messages are added to a Merkle root which is sent across chains every 30 minutes.\nAnd then those messages are executed by off-chain actors called routers.\n\nSo it is indeed possible that messages are received out of order (and potentially with increased latency in between due to batch times).\nFor "fast path" (unauthenticated) messages, latency is not a concern, but ordering may still be (this is an artifact of the chain itself too, btw).\nOne thing you can do is add a nonce to your messages so that you can yourself order them at destination.\n```
MEDIUM severity: The `Batcher.depositFunds` function in the Brahma-fi system of contracts is designed to limit the am. The `Batcher.depositFunds` function in the Brahma-fi system of contracts is designed to limit the amount of funds that can be deposited into the protocol. This limitation is implemented through a check that ensures the total amount of funds deposited, including pending deposits and withdrawals, does...

Vulnerable code:
```\nrequire(\n    IERC20(vaultInfo.vaultAddress).totalSupply() +\n        pendingDeposit -\n        pendingWithdrawal +\n        amountIn <=\n    vaultInfo.maxAmount,\n    "MAX_LIMIT_EXCEEDED"\n);\n```
MEDIUM severity: The `Pod.setManager()` function, responsible for updating the `manager` of a Pod contract, contains . The `Pod.setManager()` function, responsible for updating the `manager` of a Pod contract, contains a vulnerability in its validation mechanism. Specifically, the function checks if the existing `manager` in storage is not equal to the address `0` (zero address). This check is intended to ensure tha...

Vulnerable code:
```\nfunction setManager(address newManager)\n    public\n    virtual\n    onlyOwner\n    returns (bool)\n{\n    require(address(manager)!= address(0), "Pod:invalid-manager-address");\n}\n```
MEDIUM severity: The `StableOracleDAI` contract's `getPriceUSD` function calculates the average price between the Uni. The `StableOracleDAI` contract's `getPriceUSD` function calculates the average price between the Uniswap pool price for a pair and the Chainlink feed as part of its result. However, the issue lies in the fact that it uses `WETH/DAI` as the base/rate tokens for the pool, and `DAI/ETH` for the Chainli...

Vulnerable code:
```\nconstructor() {\n    priceFeedDAIETH = AggregatorV3Interface(\n        0x773616E4d11A78F511299002da57A0a94577F1f4\n    );\n}\n\nfunction getPrice() {\n    (, int256 price,,, ) = priceFeedDAIETH.latestRoundData();\n    // Multiply by 10 decimals to get 18 decimal fractional\n    // (uint80 roundID, int256 price, uint256 startedAt, uint256 timeStamp, uint80 answeredInRound) = priceFeedDAIETH.latestRoundData();\n```\n```\nuint256 DAIWethPrice = DAIEthOracle.quoteSpecificPoolsWithTimePeriod(\n    1000000000000000000, // 1 Eth\n    0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2, \n    0x6B175474E89094C44Da98b954EedeAC495271d0F, \n    pools, \n    600 \n);\n```\n```\nreturn (\n    (wethPriceUSD * 1e18) /\n    ((DAIWethPrice + uint256(price) * 1e10) / 2)\n);\n```
MEDIUM severity: The UniswapV3 sqrtRatioLimit mechanism, intended to provide slippage protection for users, is flawed. The UniswapV3 sqrtRatioLimit mechanism, intended to provide slippage protection for users, is flawed in its implementation. Unlike its intended purpose, the sqrtRatioLimit does not cause the swap to revert when reached, but instead allows the swap to partially fill. This is a known issue, as demonst...

Vulnerable code:
```\nif (amountToSwap > 0) {\n    SWAP_POOL = IUniswapV3Pool(vault.pool());\n    uint160 deltaSqrt = (param.sqrtRatioLimit * uint160(param.sellSlippage)) / uint160(Constants.DENOMINATOR);\n    SWAP_POOL.swap(\n        address(this),\n        // if withdraw token is Token0, then swap token1 -> token0 (false)\n       !isTokenA,\n        amountToSwap.toInt256(),\n        isTokenA\n           ? param.sqrtRatioLimit + deltaSqrt\n            : param.sqrtRatioLimit - deltaSqrt, // slippaged price cap\n        abi.encode(address(this))\n    );\n```
MEDIUM severity: The vulnerability is related to the `Errors.InvalidTwapPrice()` function in the `LibOracle.sol` libr. The vulnerability is related to the `Errors.InvalidTwapPrice()` function in the `LibOracle.sol` library, which is intended to be invoked when the `twapPriceInEther` variable equals zero. However, due to the presence of a division operation (`twapPrice / Constants.DECIMAL_USDC`) before the `if` state...

Vulnerable code:
```\nFile: contracts/libraries/LibOracle.sol\n\n85            uint256 twapPriceInEther = (twapPrice / Constants.DECIMAL_USDC) * 1 ether;\n86            uint256 twapPriceInv = uint256(twapPriceInEther);\n\n87            if (twapPriceInEther == 0) {\n88                revert Errors.InvalidTwapPrice();\n89            }\n```\n```\nSPDX-License-Identifier: GPL-3.0-only\n\npragma solidity 0.8.21;\n\nimport {Constants} from "contracts/libraries/Constants.sol";\nimport {Errors} from "contracts/libraries/Errors.sol";\nimport {U256} from "contracts/libraries/PRBMathHelper.sol";\nimport {OBFixture} from "test/utils/OBFixture.sol";\n\ncontract InvalidTwapPriceErrorCheck is OBFixture {\n    using U256 for uint256;\n\n    function getZeroTwapPriceInEther_IncorrectStyle_As_In_Existing_DittoProtocol()\n        internal\n        pure\n        returns (uint256 twapPriceInEther, uint256 twapPriceInv)\n    {\n        uint256 twapPrice = 0;\n        twapPriceInEther = (twapPrice / Constants.DECIMAL_USDC) * 1 ether;\n        twapPriceInv = twapPriceInEther.inv();\n        if (twapPriceInEther == 0) {\n            revert Errors.InvalidTwapPrice();\n        }\n    }\n\n    function getZeroTwapPriceInEther_CorrectStyle()\n        internal\n        pure\n        returns (uint256 twapPriceInEther, uint256 twapPriceInv)\n    {\n        uint256 twapPrice = 0;\n        twapPriceInEther = (twapPrice / Constants.DECIMAL_USDC) * 1 ether;\n        if (twapPriceInEther == 0) {\n            revert Errors.InvalidTwapPrice();\n        }\n        twapPriceInv = twapPriceInEther.inv();\n    }\n\n    function testInvalidTwapPriceErrNeverInvoked() public pure {\n        getZeroTwapPriceInEther_IncorrectStyle_As_In_Existing_DittoProtocol();\n    }\n\n    function testInvalidTwapPriceErrInvokedCorrectly() public {\n        vm.expectRevert(Errors.InvalidTwapPrice.selector);\n        getZeroTwapPriceInEther_CorrectStyle();\n    }\n}\n```
MEDIUM severity: The calculation of the Most Optimistic Matching Price (MOMP) in the context of neutral price determi. The calculation of the Most Optimistic Matching Price (MOMP) in the context of neutral price determination for a borrower is flawed. Specifically, when calculating MOMP, the total debt of the pool should be divided by the total number of loans in the pool to obtain the average loan size. However, th...

Vulnerable code:
```\nuint256 loansInPool = loans_.loans.length - 1 + auctions_.noOfAuctions;\nuint256 curMomp = _priceAt(\n    Deposits.findIndexOfSum(\n        deposits_,\n        Maths.wdiv(borrowerAccruedDebt_, loansInPool * 1e18)\n    )\n);\n```
MEDIUM severity: The CrosschainDistributor's `_settleClaim` function utilizes the `xcall` method to claim tokens on a. The CrosschainDistributor's `_settleClaim` function utilizes the `xcall` method to claim tokens on another domain. However, it fails to pay the relayer fee, which is a crucial component of the transaction relay process. This oversight results in the transaction not being relayed to the target chain,...

Vulnerable code:
```\nid = connext.xcall(\n    _recipientDomain,  # destination domain\n    _recipient,  # to\n    address(token),  # asset\n    _recipient,  # delegate, only required for self-execution + slippage\n    _amount,  # amount\n    0,  # slippage -- assumes no pools on connext\n    bytes('')\n)\n```
MEDIUM severity: The `LibChainlinkOracle` library, which interacts with the Chainlink oracle, employs a `CHAINLINK_TI. The `LibChainlinkOracle` library, which interacts with the Chainlink oracle, employs a `CHAINLINK_TIMEOUT` constant set to 14400 seconds (4 hours). This duration is four times longer than the Chainlink heartbeat, which is 3600 seconds (1 hour). This disparity can lead to a significant delay in detec...

Vulnerable code:
```\nfunction checkForInvalidTimestampOrAnswer(\n    uint256 timestamp,\n    int256 answer,\n    uint256 currentTimestamp\n) private pure returns (bool) {\n    if (timestamp == 0 || timestamp > currentTimestamp) {\n        return true;\n    }\n    if (currentTimestamp.sub(timestamp) > CHAINLINK_TIMEOUT) {\n        return true;\n    }\n    if (answer <= 0) {\n        return true;\n    }\n}\n```\n```\nuint256 public constant CHAINLINK_TIMEOUT = 14400;\n```
MEDIUM severity: The protocol's mechanism for handling fee on transfer tokens is flawed, as it fails to accurately ca. The protocol's mechanism for handling fee on transfer tokens is flawed, as it fails to accurately calculate the debt size when users opt to pay their debt in full using the `type(uint256).max` parameter. This issue arises from the protocol's reliance on measuring token balances before and after tran...

Vulnerable code:
```\nfunction doERC20TransferIn(address token, uint256 amountCall)\n    internal\n    returns (uint256)\n{\n    uint256 balanceBefore = IERC20Upgradeable(token).balanceOf(address(this));\n    IERC20Upgradeable(token).safeTransferFrom(msg.sender, address(this), amountCall);\n    uint256 balanceAfter = IERC20Upgradeable(token).balanceOf(address(this));\n    return balanceAfter - balanceBefore;\n}\n```\n```\nif (amountCall == type(uint256).max):\n    amountCall = oldDebt\n```
MEDIUM severity: The `accountFromPubkey` function in the `CheckBitcoinSigs` contract is responsible for deriving an E. The `accountFromPubkey` function in the `CheckBitcoinSigs` contract is responsible for deriving an Ethereum account address from a given public key. The function takes a 64-byte array representing the public key, performs a Keccak-256 hash on it, and then casts the resulting `bytes32` value to `uint...

Vulnerable code:
```\nfunction accountFromPubkey(bytes memory _pubkey) internal pure returns (address) {\n    require(_pubkey.length == 64, "Pubkey must be 64-byte raw, uncompressed key.");\n\n    bytes32 _digest = keccak256(_pubkey);\n    return address(uint160(uint256(_digest)));\n}\n```
MEDIUM severity: The `closeQuote` function in the `LibQuote` contract is vulnerable to a rounding error when closing . The `closeQuote` function in the `LibQuote` contract is vulnerable to a rounding error when closing a quote. This occurs when the `filledAmount` provided is too small, causing the locked balance of an account to remain unchanged despite a portion of the position being closed. This issue arises from...

Vulnerable code:
```\nFile: LibQuote.sol\n\nfunction closeQuote(Quote storage quote, uint256 filledAmount, uint256 closedPrice) internal {\n    QuoteStorage.Layout storage quoteLayout = QuoteStorage.layout();\n    AccountStorage.Layout storage accountLayout = AccountStorage.layout();\n\n    quote.modifyTimestamp = block.timestamp;\n\n    LockedValues memory lockedValues = LockedValues(\n        quote.lockedValues.cva -\n            ((quote.lockedValues.cva * filledAmount) / LibQuote.quoteOpenAmount(quote)),\n        quote.lockedValues.mm -\n            ((quote.lockedValues.mm * filledAmount) / LibQuote.quoteOpenAmount(quote)),\n        quote.lockedValues.lf -\n            ((quote.lockedValues.lf * filledAmount) / LibQuote.quoteOpenAmount(quote))\n    );\n    accountLayout.lockedBalances[quote.partyA].subQuote(quote).add(lockedValues);\n    accountLayout.partyBLockedBalances[quote.partyB][quote.partyA].subQuote(quote).add(lockedValues);\n    quote.lockedValues = lockedValues;\n\n    (bool hasMadeProfit, uint256 pnl) = LibQuote.getValueOfQuoteForPartyA(closedPrice, filledAmount, quote);\n    if (hasMadeProfit) {\n        accountLayout.allocatedBalances[quote.partyA] += pnl;\n        accountLayout.partyBAllocatedBalances[quote.partyB][quote.partyA] -= pnl;\n    } else {\n        accountLayout.allocatedBalances[quote.partyA] -= pnl;\n        accountLayout.partyBAllocatedBalances[quote.partyB][quote.partyA] += pnl;\n    }\n}\n```
MEDIUM severity: The `MultipleWinners` contract's `setNumberOfWinners` function does not enforce the minimum requirem. The `MultipleWinners` contract's `setNumberOfWinners` function does not enforce the minimum requirement of `_numberOfWinners` being greater than 0, unlike its constructor. This oversight allows an attacker or an unsuspecting administrator to set the `_numberOfWinners` variable to 0, effectively disa...

Vulnerable code:
```\nrequire(_numberOfWinners > 0, "MultipleWinners/num-gt-zero");\n```\n```\nfunction setNumberOfWinners(uint256 count) external onlyOwner {\n    _numberOfWinners = count;\n\n    emit NumberOfWinnersSet(count);\n}\n```
MEDIUM severity: The UserData for balancer pool exits is malformed, which causes all withdrawal attempts to fail, res. The UserData for balancer pool exits is malformed, which causes all withdrawal attempts to fail, resulting in users being permanently trapped. This issue arises from the encoding of UserData as an empty string, which does not contain the necessary information for exiting the pool.\n\nIn the `AuraSpe...

Vulnerable code:
```\nwAuraPools.getVault(lpToken).exitPool(\n    IBalancerPool(lpToken).getPoolId(),\n    address(this),\n    address(this),\n    IBalancerVault.ExitPoolRequest(\n        tokens,\n        minAmountsOut,\n        "",\n        false\n    )\n);\n```\n```\nfunction exactBptInForTokenOut(bytes memory self) internal pure returns (uint256 bptAmountIn, uint256 tokenIndex) {\n    (\n       ,\n        bptAmountIn,\n        tokenIndex\n    ) = abi.decode(self, (WeightedPool.ExitKind, uint256, uint256));\n}\n```
MEDIUM severity: The vulnerability allows malicious users to steal victim's funds by exploiting the rounding error an. The vulnerability allows malicious users to steal victim's funds by exploiting the rounding error and exchange rate manipulation in the LST Adaptor's `prefundedDeposit` function. This occurs when the attacker manipulates the exchange rate by depositing a small amount of ETH before the victim's trans...

Vulnerable code:
```\nfunction prefundedDeposit() external nonReentrant returns (uint256, uint256) {\n    uint256 bufferEthCache = bufferEth; // cache storage reads\n    uint256 queueEthCache = withdrawalQueueEth; // cache storage reads\n    uint256 assets = IWETH9(WETH).balanceOf(address(this)) - bufferEthCache; // amount of WETH deposited at this time\n    uint256 shares = previewDeposit(assets);\n\n    if (assets == 0) {\n        return (0, 0);\n    }\n    if (shares == 0) {\n        revert ZeroShares();\n    }\n}\n```
MEDIUM severity: The vulnerability arises when a user's collateral is insufficient to cover their loan, and a malicio. The vulnerability arises when a user's collateral is insufficient to cover their loan, and a malicious liquidator takes advantage of the `strain` parameter in the liquidation process. The `strain` value, which is not capped, allows the liquidator to manipulate the repayment amount, potentially leadi...

Vulnerable code:
```\nassembly ("memory-safe") {\n    liabilities0 := div(liabilities0, strain)  # @audit rounds down to 0 <-\n    liabilities1 := div(liabilities1, strain)  # @audit rounds down to 0 <-\n}\n```\n```\n@audit Won't be repaid in full since the loan is insolvent\n_repay(repayable0, repayable1);\n\nslot0 = (slot0 & SLOT0_MASK_POSITIONS) | SLOT0_DIRT;\n\n@audit will transfer the user 2e14 (0.5$)\npayable(callee).transfer(address(this).balance / strain);\nemit Liquidate(repayable0, repayable1, incentive1, priceX128);\n```
MEDIUM severity: The vulnerability allows an attacker to manipulate the `ERC721Power::totalPower` variable by exploit. The vulnerability allows an attacker to manipulate the `ERC721Power::totalPower` variable by exploiting the ability to call `ERC721Power::recalculateNftPower()` and `getNftPower()` for non-existent NFTs. This is achieved by taking advantage of the fact that the `getNftPower()` function returns a def...

Vulnerable code:
```\nfunction getNftPower(uint256 tokenId) public view override returns (uint256) {\n    if (block.timestamp <= powerCalcStartTimestamp) {\n        return 0;\n    }\n\n    uint256 collateral = nftInfos[tokenId].currentCollateral;\n\n    uint256 maxNftPower = getMaxPowerForNft(tokenId);\n    uint256 minNftPower = maxNftPower.ratio(collateral, getRequiredCollateralForNft(tokenId));\n    minNftPower = maxNftPower.min(minNftPower);\n\n    uint64 lastUpdate = nftInfos[tokenId].lastUpdate;\n    uint256 currentPower = nftInfos[tokenId].currentPower;\n\n    if (lastUpdate == 0) {\n        lastUpdate = powerCalcStartTimestamp;\n        currentPower = maxNftPower;\n    }\n\n    uint256 powerReductionPercent = reductionPercent * (block.timestamp - lastUpdate);\n    uint256 powerReduction = currentPower.min(maxNftPower.percentage(powerReductionPercent));\n    uint256 newPotentialPower = currentPower - powerReduction;\n\n    if (minNftPower <= newPotentialPower) {\n        return newPotentialPower;\n    }\n\n    if (minNftPower <= currentPower) {\n        return minNftPower;\n    }\n\n    return currentPower;\n}\n\nfunction recalculateNftPower(uint256 tokenId) public override returns (uint256 newPower) {\n    if (block.timestamp < powerCalcStartTimestamp) {\n        return 0;\n    }\n\n    newPower = getNftPower(tokenId);\n\n    NftInfo storage nftInfo = nftInfos[tokenId];\n\n    totalPower -= nftInfo.lastUpdate!= 0? nftInfo.currentPower : getMaxPowerForNft(tokenId);\n    totalPower += newPower;\n\n    nftInfo.lastUpdate = uint64(block.timestamp);\n    nftInfo.currentPower = newPower;\n}\n```
MEDIUM severity: The vulnerability arises when an invalid oracle version occurs, causing the `maker` position to pote. The vulnerability arises when an invalid oracle version occurs, causing the `maker` position to potentially exceed the `makerLimit`, resulting in a temporary or permanent bricking of the Market contract. This issue occurs when positions pending at the invalid oracle version are invalidated, leading...

Vulnerable code:
```\nif (context.currentPosition.global.maker.gt(context.riskParameter.makerLimit)):\n    revert MarketMakerOverLimitError()\n```
MEDIUM severity: The vulnerability lies in the `setTargetThreshold()` function, which is responsible for updating the. The vulnerability lies in the `setTargetThreshold()` function, which is responsible for updating the safe's threshold based on the `targetThreshold` and `validSignerCount`. The function fails to correctly adjust the safe's threshold when the `targetThreshold` is set above the current safe's threshol...

Vulnerable code:
```\nuint256 currentThreshold = safe.getThreshold();\nuint256 newThreshold;\nuint256 target = targetThreshold;  # save SLOADs\n\nif (validSignerCount <= target && validSignerCount!= currentThreshold) {\n    newThreshold = validSignerCount;\n} else if (validSignerCount > target && currentThreshold < target) {\n    newThreshold = target;\n}\n\nif (newThreshold > 0) {\n    // rest of code update safe threshold\n    // rest of code\n}\n```\n```\nif (safe.getThreshold()!= _getCorrectThreshold()):\n    revert SignersCannotChangeThreshold()\n```\n```\nfunction _getCorrectThreshold() internal view returns (uint256 _threshold) {\n    uint256 count = _countValidSigners(safe.getOwners());\n    uint256 min = minThreshold;\n    uint256 max = targetThreshold;\n    if (count < min) {\n        _threshold = min;\n    } else if (count > max) {\n        _threshold = max;\n    } else {\n        _threshold = count;\n    }\n}\n```
MEDIUM severity: The `RocketDAOProposal` contract's `getState` function defaults a proposal's state to `ProposalState. The `RocketDAOProposal` contract's `getState` function defaults a proposal's state to `ProposalState.Defeated` if no explicit state is provided. Although this default behavior may seem secure at first glance, it inadvertently allows for a potential attack vector. Specifically, a malicious user can e...

Vulnerable code:
```\n} else {\n    if (votesFor <= votesAgainst || votesFor < getVotesRequired(_proposalID)) {\n        return ProposalState.Defeated;\n    }\n```\n```\nfunction cancel(address _member, uint256 _proposalID) override public onlyDAOContract(getDAO(_proposalID)) {\n    require(getState(_proposalID)!= ProposalState.Executed, "Proposal has already been executed");\n    require(getState(_proposalID)!= ProposalState.Succeeded, "Proposal has already succeeded");\n    require(getProposer(_proposalID) == _member, "Proposal can only be cancelled by the proposer");\n    setBool(keccak256(abi.encodePacked(daoProposalNameSpace, "cancelled", _proposalID)), true);\n    emit ProposalCancelled(_proposalID, _member, block.timestamp);\n}\n```
MEDIUM severity: The `DynamicLiquidTokenConverter` in the zBanc codebase, which is a fork of the bancorprotocol/contr. The `DynamicLiquidTokenConverter` in the zBanc codebase, which is a fork of the bancorprotocol/contracts-solidity, may be vulnerable to potential converter type overlap with the bancorprotocol's existing converter types. This is because the `DynamicLiquidTokenConverter` was introduced with a convert...

Vulnerable code:
```\nfunction converterType() public pure override returns (uint16) {\n    return 3;\n}\n```\n```\nfunction converterType() public pure override returns (uint16) {\n    return 1;\n}\n```\n```\nfunction converterType() public pure override returns (uint16) {\n    return 2;\n}\n```