Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The `withdraw` function in the `CollateralManager` contract allows a lender to withdraw their deposi. The `withdraw` function in the `CollateralManager` contract allows a lender to withdraw their deposited collateral from an escrow account associated with a bid that has been successfully repaid. However, in the event of a loan default, the function can be triggered by anyone, including the borrower,...

Vulnerable code:
```\n/**\n * @notice Withdraws deposited collateral from the created escrow of a bid that has been successfully repaid.\n * @param _bidId The id of the bid to withdraw collateral for.\n */\nfunction withdraw(uint256 _bidId) external {\n    BidState bidState = tellerV2.getBidState(_bidId);\n    console2.log("WITHDRAW %d", uint256(bidState));\n    if (bidState == BidState.PAID) {\n        _withdraw(_bidId, tellerV2.getLoanBorrower(_bidId));\n    } else if (tellerV2.isLoanDefaulted(_bidId)) {\n        _withdraw(_bidId, tellerV2.getLoanLender(_bidId));\n        emit CollateralClaimed(_bidId);\n    } else {\n        revert("collateral cannot be withdrawn");\n    }\n}\n```
MEDIUM severity: The vulnerability arises when the sequencer is unavailable on Arbitrum, allowing state changes to oc. The vulnerability arises when the sequencer is unavailable on Arbitrum, allowing state changes to occur on the L2 by bypassing the sequencer through the Delayed Inbox. Although users can still interact with the Index protocol, the operator is blocked from executing certain functions due to the alias...

Vulnerable code:
```\nL2_Alias = L1_Contract_Address + 0x1111000000000000000000000000000000001111\n```
MEDIUM severity: The `balanceOfToken` function in the provided code calculates the total balance of asset tokens for . The `balanceOfToken` function in the provided code calculates the total balance of asset tokens for a given address, taking into account both deposits and interest. However, the computation is overly conservative, potentially underestimating the actual balance. This is because it uses a two-step pro...

Vulnerable code:
```\nfunction balanceOfToken(address addr) public override returns (uint256) {\n    if (balances[addr] == 0) return 0;\n    ISushiBar bar = ISushiBar(sushiBar);\n\n    uint256 shares = bar.balanceOf(address(this));\n    uint256 totalShares = bar.totalSupply();\n\n    uint256 sushiBalance = shares.mul(ISushi(sushiAddr).balanceOf(address(sushiBar))).div(totalShares);\n    uint256 sourceShares = bar.balanceOf(address(this));\n\n    return balances[addr].mul(sushiBalance).div(sourceShares);\n}\n```
MEDIUM severity: The No Proper Trusted Setup vulnerability affects the security of the Plonk proof system, which reli. The No Proper Trusted Setup vulnerability affects the security of the Plonk proof system, which relies on a preprocessed Common Reference String (CRS) for proving and verification. The system's security is predicated on the existence of a trusted setup ceremony, where a trusted party computes the CR...

Vulnerable code:
```\nuint256 constant g2_srs_0_x_0 = 11559732032986387107991004021392285783925812861821192530917403151452391805634;\nuint256 constant g2_srs_0_x_1 = 10857046999023057135944570762232829481370756359578518086990519993285655852781;\nuint256 constant g2_srs_0_y_0 = 4082367875863433681332203403145435568316851327593401208105741076214120093531;\nuint256 constant g2_srs_0_y_1 = 8495653923123431417604973247489272438418190587263600148770280649306958101930;\n\nuint256 constant g2_srs_1_x_0 = 18469474764091300207969441002824674761417641526767908873143851616926597782709;\nuint256 constant g2_srs_1_x_1 = 17691709543839494245591259280773972507311536864513996659348773884770927133474;\nuint256 constant g2_srs_1_y_0 = 2799122126101651639961126614695310298819570600001757598712033559848160757380;\nuint256 constant g2_srs_1_y_1 = 3054480525781015242495808388429905877188466478626784485318957932446534030175;\n```
MEDIUM severity: The reactivation of gauges with previously queued rewards has been found to have an issue with the a. The reactivation of gauges with previously queued rewards has been found to have an issue with the accounting for the last cycle's rewards. Specifically, the `storedCycle` variable in the `queuedRewards` contract does not accurately reflect the current `gaugeCycle` state. This discrepancy leads to a...

Vulnerable code:
```\nuint112 completedRewards = \n    queuedRewards.storedCycle == lastCycle? \n    queuedRewards.cycleRewards : 0;\n```\n```\npriorCycleRewards = queuedRewards.priorCycleRewards + completedRewards\n```
MEDIUM severity: The Balancer LP valuation methodologies employed in various instances utilize an incorrect supply me. The Balancer LP valuation methodologies employed in various instances utilize an incorrect supply metric, specifically the `totalSupply()` function, to determine the total LP supply. This approach can lead to inaccurate valuations, as it does not accurately reflect the actual supply of LP tokens. In...

Vulnerable code:
```\nuint256 balTotalSupply = pool.balancerPool.totalSupply();\nuint256[] memory balances = new uint256[](_vaultTokens.length);\n\nif (balTotalSupply!= 0) {\n    uint256 tokenLen = _vaultTokens.length;\n    for (uint256 i = 0; i < tokenLen; i++) {\n        uint256 balance = _vaultBalances[i];\n        uint256 polBalance = (balance * balBalance) / balTotalSupply;\n        balances[i] = polBalance;\n    }\n}\n```
MEDIUM severity: The vulnerability lies in the `buyCollateralFromAuction` function, specifically in the condition tha. The vulnerability lies in the `buyCollateralFromAuction` function, specifically in the condition that checks whether to close the auction. The function only terminates the auction when the balance of the token being auctioned reaches zero. This can be exploited by malicious users to extend the aucti...

Vulnerable code:
```\nfunction buyCollateralFromAuction(address token, uint amount) override external {\n    Auction memory auction = auctions[token];\n    require(_isAuctionOngoing(auction.startedAt, auction.expiryTime), "IF.no_ongoing_auction");\n\n    uint vusdToTransfer = _calcVusdAmountForAuction(auction, token, amount);\n    address buyer = _msgSender();\n    vusd.safeTransferFrom(buyer, address(this), vusdToTransfer);\n\n    IERC20(token).safeTransfer(buyer, amount); // will revert if there wasn't enough amount as requested\n\n    if (IERC20(token).balanceOf(address(this)) == 0) {\n        auctions[token].startedAt = 0;\n    }\n}\n```
MEDIUM severity: The `TokenStaking.recoverStake` function is responsible for recovering stake that has been designate. The `TokenStaking.recoverStake` function is responsible for recovering stake that has been designated to be undelegated. The function contains a single check to ensure that the undelegation period has passed, which is determined by the `operatorParams.getUndelegationBlock()` method. This check is in...

Vulnerable code:
```\nfunction recoverStake(address _operator) public {\n    uint256 operatorParams = operators[_operator].packedParams;\n    require(\n        block.number > operators[_operator].packedParams.getUndelegationBlock().add(undelegationPeriod),\n        "Can not recover stake before undelegation period is over."\n    );\n```
MEDIUM severity: The FundRateArbitrage contract is vulnerable to inflation attacks, which can be exploited by manipul. The FundRateArbitrage contract is vulnerable to inflation attacks, which can be exploited by manipulating the index calculation. The index is calculated by dividing the net value of the contract, including USDC held, by the current supply of totalEarnUSDCBalance. This calculation can be inflated by...

Vulnerable code:
```\nfunction getIndex() public view returns (uint256) {\n    if (totalEarnUSDCBalance == 0) {\n        return 1e18;\n    } else {\n        return SignedDecimalMath.decimalDiv(getNetValue(), totalEarnUSDCBalance);\n    }\n}\n```\n```\nfunction deposit(uint256 amount) external {\n    require(amount!= 0, "deposit amount is zero");\n    uint256 feeAmount = amount * depositFeeRate;\n    if (feeAmount > 0) {\n        amount -= feeAmount;\n        IERC20(usdc).transferFrom(msg.sender, owner(), feeAmount);\n    }\n    uint256 earnUSDCAmount = amount / getIndex();\n    IERC20(usdc).transferFrom(msg.sender, address(this), amount);\n    JOJODealer(jojoDealer).deposit(0, amount, msg.sender);\n    earnUSDCBalance[msg.sender] += earnUSDCAmount;\n    jusdOutside[msg.sender] += amount;\n    totalEarnUSDCBalance += earnUSDCAmount;\n    require(getNetValue() <= maxNetValue, "net value exceed limitation");\n    uint256 quota = maxUsdcQuota[msg.sender] == 0? defaultUsdcQuota : maxUsdcQuota[msg.sender];\n    require(earnUSDCBalance[msg.sender] * getIndex() <= quota, "usdc amount bigger than quota");\n    emit DepositToHedging(msg.sender, amount, feeAmount, earnUSDCAmount);\n}\n```
MEDIUM severity: The `_isExternalLendingUnhealthy` function in the `TreasuryAction.sol` contract calculates the off-t. The `_isExternalLendingUnhealthy` function in the `TreasuryAction.sol` contract calculates the off-target percentage as a ratio of the difference between the current external lending amount and the target amount to the sum of the current external lending amount and the target amount. This calculatio...

Vulnerable code:
```\noffTargetPercentage = abs(90 - 100) / (100 + 90)\noffTargetPercentage = 10 / 190\noffTargetPercentage = 0.0526\noffTargetPercentage = 5.26\n```\n```\noffTargetPercentage = abs(90 - 100) / 100\noffTargetPercentage = 10 / 100\noffTargetPercentage = 0.1\noffTargetPercentage = 10%\n```\n```\nFile: TreasuryAction.sol\n\nfunction _isExternalLendingUnhealthy(\n    uint16 currencyId,\n    IPrimeCashHoldingsOracle oracle,\n    PrimeRate memory pr\n) internal view returns (bool isExternalLendingUnhealthy, OracleData memory oracleData, uint256 targetAmount) {\n    oracleData = oracle.getOracleData();\n\n    RebalancingTargetData memory rebalancingTargetData = \n        LibStorage.getRebalancingTargets()[currencyId][oracleData.holding];\n\n    PrimeCashFactors memory factors = \n        PrimeCashExchangeRate.getPrimeCashFactors(currencyId);\n\n    Token memory underlyingToken = \n        TokenHandler.getUnderlyingToken(currencyId);\n\n    targetAmount = \n        ExternalLending.getTargetExternalLendingAmount(\n            underlyingToken, \n            factors, \n            rebalancingTargetData, \n            oracleData, \n            pr\n        );\n\n    if (oracleData.currentExternalUnderlyingLend == 0) {\n        // If this is zero then there is no outstanding lending.\n        isExternalLendingUnhealthy = false;\n    } else {\n        uint256 offTargetPercentage = oracleData.currentExternalUnderlyingLend.toInt().sub(targetAmount.toInt()).abs().toUint().mul(uint256(Constants.PERCENTAGE_DECIMALS)).div(targetAmount.add(oracleData.currentExternalUnderlyingLend));\n\n        // prevent rebalance if change is not greater than 1%, important for health check and avoiding triggering rebalance shortly after rebalance on minimum change\n        isExternalLendingUnhealthy = \n            (targetAmount < oracleData.currentExternalUnderlyingLend) && (offTargetPercentage > 0);\n    }\n}\n```
MEDIUM severity: The `onlyEOAEx` modifier is designed to restrict calls to a function or contract to only be initiate. The `onlyEOAEx` modifier is designed to restrict calls to a function or contract to only be initiated by an externally-owned account (EOA), as opposed to a smart contract. This is typically achieved by checking the `tx.origin` variable, which is supposed to identify the original sender of the transa...

Vulnerable code:
```\nmodifier onlyEOAEx() {\n    if (!allowContractCalls &&!whitelistedContracts[msg.sender]) {\n        if (msg.sender!= tx.origin) {\n            revert NOT_EOA(msg.sender);\n        }\n    }\n}\n```
MEDIUM severity: The zAuction contract contains a hardcoded reference to the Rinkeby WETH ERC20 token address, specif. The zAuction contract contains a hardcoded reference to the Rinkeby WETH ERC20 token address, specifically `0xc778417E063141139Fce010982780140Aa0cD5Ab`. This hardcoded address is used to interact with the WETH token, which is a testnet token on the Rinkeby test network. However, this hardcoded addre...

Vulnerable code:
```\nIERC20 weth = IERC20(address(0xc778417E063141139Fce010982780140Aa0cD5Ab));\n```
MEDIUM severity: The `Harvester.harvest` function in the Convex ETH-stETH pool strategy claims and swaps reward token. The `Harvester.harvest` function in the Convex ETH-stETH pool strategy claims and swaps reward tokens into ETH without considering slippage. Specifically, the swaps for LDO, CVX, and CRV tokens are performed without any slippage protection, which can lead to significant losses due to MEV (Maximal Ex...

Vulnerable code:
```\nfunction _swapLidoForWETH(uint256 amountToSwap) internal {\n    IUniswapSwapRouter.ExactInputSingleParams memory params = IUniswapSwapRouter.ExactInputSingleParams(\n        {\n            tokenIn: address(ldo),\n            tokenOut: address(weth),\n            fee: UNISWAP_FEE,\n            recipient: address(this),\n            deadline: block.timestamp,\n            amountIn: amountToSwap,\n            amountOutMinimum: 0,\n            sqrtPriceLimitX96: 0\n        }\n    );\n    uniswapRouter.exactInputSingle(params);\n}\n```\n```\nif (cvxBalance > 0) {\n    cvxeth.exchange(1, 0, cvxBalance, 0, false);\n}\n\nif (crvBalance > 0) {\n    crveth.exchange(1, 0, crvBalance, 0, false);\n}\n```
MEDIUM severity: The `totalLend` variable in the bank tracks the total amount lent for a given token, but it fails to. The `totalLend` variable in the bank tracks the total amount lent for a given token, but it fails to account for tokens withdrawn during position liquidations. This oversight leads to an inflated value, resulting in inaccurate data on the pool. \n\nWhen a user lends a token to the Compound fork, the...

Vulnerable code:
```\nbank.totalLend += amount;\n```\n```\nuint256 liqSize = (pos.collateralSize * share) / oldShare;\nuint256 uTokenSize = (pos.underlyingAmount * share) / oldShare;\nuint256 uVaultShare = (pos.underlyingVaultShare * share) / oldShare;\n\npos.collateralSize -= liqSize;\npos.underlyingAmount -= uTokenSize;\npos.underlyingVaultShare -= uVaultShare;\n```\n```\nfunction withdraw(uint256 shareAmount)\n    external\n    override\n    nonReentrant\n    returns (uint256 withdrawAmount)\n{\n    if (shareAmount == 0) revert ZERO_AMOUNT();\n\n    _burn(msg.sender, shareAmount);\n\n    uint256 uBalanceBefore = uToken.balanceOf(address(this));\n    if (cToken.redeem(shareAmount)!= 0) revert REDEEM_FAILED(shareAmount);\n    uint256 uBalanceAfter = uToken.balanceOf(address(this));\n\n    withdrawAmount = uBalanceAfter - uBalanceBefore;\n\n    if (\n        block.timestamp <\n        config.withdrawVaultFeeWindowStartTime() +\n        config.withdrawVaultFeeWindow()\n    ) {\n        uint256 fee = (withdrawAmount * config.withdrawVaultFee()) / DENOMINATOR;\n        uToken.safeTransfer(config.treasury(), fee);\n        withdrawAmount -= fee;\n    }\n\n    uToken.safeTransfer(msg.sender, withdrawAmount);\n\n    emit Withdrawn(msg.sender, withdrawAmount, shareAmount);\n}\n```
MEDIUM severity: The vulnerability lies in the `findOrderHintId` function, which relies on the assumption that when a. The vulnerability lies in the `findOrderHintId` function, which relies on the assumption that when a previous order's type is `matched`, it must have been at the top of the orderbook. This assumption is flawed, as it does not account for the possibility of a reused order ID being used multiple times...

Vulnerable code:
```\nfunction findOrderHintId(\n    mapping(address => mapping(uint16 => STypes.Order)) storage orders,\n    address asset,\n    MTypes.OrderHint[] memory orderHintArray\n) internal returns (uint16 hintId) {\n    if (hintOrderType == O.Cancelled || hintOrderType == O.Matched) {\n        emit Events.FindOrderHintId(0);\n        continue;\n    } else if (\n        orders[asset][orderHint.hintId].creationTime == orderHint.creationTime\n    ) {\n        emit Events.FindOrderHintId(1);\n        return orderHint.hintId;\n    } else if (orders[asset][orderHint.hintId].prevOrderType == O.Matched) {\n        emit Events.FindOrderHintId(2);\n        return Constants.HEAD;\n    }\n```
MEDIUM severity: The tax refund calculation logic in the provided code is flawed, leading to incorrect tax refunds be. The tax refund calculation logic in the provided code is flawed, leading to incorrect tax refunds being issued to users. Specifically, when the user's share of the token sale (s.share) exceeds the maximum tax-free allocation (taxFreeAllc), the refund tax amount is calculated incorrectly.\n\nThe issu...

Vulnerable code:
```\nif (s.share, left) = _claim(s);\nrequire(left > 0, "TokenSale: Nothing to claim");\n\nuint256 refundTaxAmount;\nif (s.taxAmount > 0) {\n    uint256 tax = userTaxRate(s.amount, msg.sender);\n    uint256 taxFreeAllc = _maxTaxfreeAllocation(msg.sender) * PCT_BASE;\n    if (taxFreeAllc >= s.share) {\n        refundTaxAmount = s.taxAmount;\n    } else {\n        refundTaxAmount = (left * tax) / POINT_BASE;\n    }\n    usdc.safeTransferFrom(marketingWallet, msg.sender, refundTaxAmount);\n```
MEDIUM severity: The `onTokenTransfer` function in the `SponsorshipFactory` and `OperatorFactory` contracts is respon. The `onTokenTransfer` function in the `SponsorshipFactory` and `OperatorFactory` contracts is responsible for handling token transfers and contract deployments within a single transaction. However, a critical vulnerability exists in the implementation, as it does not verify whether the call originat...

Vulnerable code:
```\nif (msg.sender!= address(token)) {\n    revert AccessDeniedDATATokenOnly();\n}\n```
MEDIUM severity: The `includeAsset` function, which is accessible only to the owner, allows for the addition of new a. The `includeAsset` function, which is accessible only to the owner, allows for the addition of new assets to the `shell.numeraires` list. However, the function does not perform a check to verify if the asset already exists in the list before adding it. This oversight can lead to the creation of dupl...

Vulnerable code:
```\nfunction includeAsset(\n    address _numeraire,\n    address _nAssim,\n    address _reserve,\n    address _rAssim,\n    uint256 _weight\n) public onlyOwner {\n    shell.includeAsset(_numeraire, _nAssim, _reserve, _rAssim, _weight);\n}\n```\n```\nfunction includeAsset(\n    Shells.Shell storage shell,\n    address _numeraire,\n    address _numeraireAssim,\n    address _reserve,\n    address _reserveAssim,\n    uint256 _weight\n) internal {\n```\n```\nshell.numeraires.push(_numeraireAssimilator);\n```
MEDIUM severity: The `StrategyBase` contract defines two pairs of functions, `sharesToUnderlyingView` and `underlying. The `StrategyBase` contract defines two pairs of functions, `sharesToUnderlyingView` and `underlyingToSharesView`, which are intended to be used for calculating the equivalent amounts of tokens and shares, respectively. These functions are declared as `view` in the `IStrategy` interface, which means...

Vulnerable code:
```\n/**\n * @notice Used to convert an amount of underlying tokens to the equivalent amount of shares in this strategy.\n * @notice In contrast to `underlyingToSharesView`, this function may make state modifications\n * @param amountUnderlying is the amount of `underlyingToken` to calculate its conversion into strategy shares\n * @dev Implementation for these functions in particular may vary significantly for different strategies\n */\nfunction underlyingToShares(uint256 amountUnderlying) external view returns (uint256);\n```\n```\n/**\n * @notice Used to convert an amount of underlying tokens to the equivalent amount of shares in this strategy.\n * @notice In contrast to `underlyingToSharesView`, this function may make state modifications\n * @param amountUnderlying is the amount of `underlyingToken` to calculate its conversion into strategy shares\n * @dev Implementation for these functions in particular may vary significantly for different strategies\n */\nfunction underlyingToShares(uint256 amountUnderlying) external view virtual returns (uint256) {\n    return underlyingToSharesView(amountUnderlying);\n}\n```\n```\n/**\n * @notice Used to convert a number of shares to the equivalent amount of underlying tokens for this strategy.\n * @notice In contrast to `sharesToUnderlyingView`, this function may make state modifications\n * @param amountShares is the amount of shares to calculate its conversion into the underlying token\n * @dev Implementation for these functions in particular may vary significantly for different strategies\n */\nfunction sharesToUnderlying(uint256 amountShares) public view virtual override returns (uint256) {\n    return sharesToUnderlyingView(amountShares);\n}\n```
MEDIUM severity: The `TBTCSystem.requestNewKeep` function, used by each new `Deposit` contract upon creation, lacks a. The `TBTCSystem.requestNewKeep` function, used by each new `Deposit` contract upon creation, lacks access controls, making it vulnerable to unauthorized access. This function calls `BondedECDSAKeepFactory.openKeep`, which sets the `Deposit` contract as the "owner" of the newly created keep, a permis...

Vulnerable code:
```\nfunction requestNewKeep(uint256 _m, uint256 _n, uint256 _bond)\n    external\n    payable\n    returns (address)\n{\n    IBondedECDSAKeepVendor _keepVendor = IBondedECDSAKeepVendor(keepVendor);\n    IBondedECDSAKeepFactory _keepFactory = IBondedECDSAKeepFactory(_keepVendor.selectFactory());\n    return _keepFactory.openKeep.value(msg.value)(_n, _m, msg.sender, _bond);\n}\n```
MEDIUM severity: The `redeemToken` function is responsible for redeeming SUSHI tokens from the yield source and retur. The `redeemToken` function is responsible for redeeming SUSHI tokens from the yield source and returning them to the caller. The function takes an amount of SUSHI as input and calculates the corresponding amount of xSUSHI to be burned in exchange for the requested SUSHI. However, due to the nature o...

Vulnerable code:
```\nfunction redeemToken(uint256 amount) public override returns (uint256) {\n    ISushiBar bar = ISushiBar(sushiBar);\n    ISushi sushi = ISushi(sushiAddr);\n\n    uint256 totalShares = bar.totalSupply();\n    uint256 barSushiBalance = sushi.balanceOf(address(bar));\n    uint256 requiredShares = amount * totalShares / barSushiBalance;\n\n    uint256 barBeforeBalance = bar.balanceOf(address(this));\n    uint256 sushiBeforeBalance = sushi.balanceOf(address(this));\n\n    bar.leave(requiredShares);\n\n    uint256 barAfterBalance = bar.balanceOf(address(this));\n    uint256 sushiAfterBalance = sushi.balanceOf(address(this));\n\n    uint256 barBalanceDiff = barBeforeBalance - barAfterBalance;\n    uint256 sushiBalanceDiff = sushiAfterBalance - sushiBeforeBalance;\n\n    balances[msg.sender] = balances[msg.sender] - barBalanceDiff;\n    sushi.transfer(msg.sender, sushiBalanceDiff);\n    return sushiBalanceDiff;\n}\n```
MEDIUM severity: The `assignDeposits` function in the RocketDepositPool appears to be a gas-intensive operation, invo. The `assignDeposits` function in the RocketDepositPool appears to be a gas-intensive operation, involving multiple external calls, with a significant portion of these calls occurring within a loop. This function is responsible for assigning deposits to minipools, and its performance is heavily depen...

Vulnerable code:
```\nfor (uint256 i = 0; i < rocketDAOProtocolSettingsDeposit.getMaximumDepositAssignments(); ++i) {\n    getAndCheckNextAvailableMinipoolCapacity();\n}\n```
MEDIUM severity: This vulnerability is related to the presence of unused code in a smart contract. Specifically, the . This vulnerability is related to the presence of unused code in a smart contract. Specifically, the `_deployAccount` function is defined with two parameters, `salt` and `value`, but the `value` parameter is not utilized within the function. The function only uses the `salt` parameter to create a new...

Vulnerable code:
```\nreturn _deployAccount(\n    salt,\n    0\n);\n\nfunction _deployAccount(\n    bytes32 salt,\n    uint256 value\n)\ninternal\nreturns (address)\n{\n    return address(new Account{salt: salt, value: value}());\n}\n```