Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The `Oracle.observe` function in the `Oracle.sol` contract contains a potential overflow risk in the. The `Oracle.observe` function in the `Oracle.sol` contract contains a potential overflow risk in the calculation of the `secondsPerLiquidityCumulativeX128` return value. This calculation involves the subtraction of two `uint160` values, `liqCumR` and `liqCumL`, and the multiplication of the result b...

Vulnerable code:
```\nliqCumL + uint160(\n    ((liqCumR - liqCumL) * delta) / denom)\n```\n```\nbeforeOrAt.secondsPerLiquidityCumulativeX128 +\n    uint160(\n        (\n            uint256(\n                atOrAfter.secondsPerLiquidityCumulativeX128\n                - beforeOrAt.secondsPerLiquidityCumulativeX128\n            )\n            * targetDelta\n        )\n        / observationTimeDelta\n    )\n```\n```\nsecondsPerLiquidityCumulativeX128: \n    last.secondsPerLiquidityCumulativeX128 + \n    ((uint160(delta) << 128) / (liquidity > 0? liquidity : 1))\n```\n```\n(liqCumR - liqCumL) * delta = 3.4e38 * 86400 * 86400 > 1.5e48\n```
MEDIUM severity: The `transferEther` function within the `LootBox` contract is vulnerable to being exploited due to i. The `transferEther` function within the `LootBox` contract is vulnerable to being exploited due to its public accessibility. This function is responsible for transferring Ether to a specified address, and it is currently exposed to external calls. \n\nThe function is called from within the `plunder`...

Vulnerable code:
```\nfunction transferEther(address payable to, uint256 amount) public {\n    to.transfer(amount);\n\n    emit TransferredEther(to, amount);\n}\n```
MEDIUM severity: When a flash loan is executed, the `wagmiLeverageFlashCallback` function is responsible for handling. When a flash loan is executed, the `wagmiLeverageFlashCallback` function is responsible for handling the repayment operation. This function acquires a certain amount of `saleToken` through a flash loan and then converts it into `holdToken` using the `_v3SwapExact` function. The amount of `holdToken`...

Vulnerable code:
```\nuint256 holdTokenAmtIn = _v3SwapExact(\n    v3SwapExactParams({\n        isExactInput: false,\n        fee: decodedData.fee,\n        tokenIn: decodedData.holdToken,\n        tokenOut: decodedData.saleToken,\n        amount: amountToPay\n    })\n);\n\ndecodedData.holdTokenDebt -= \n    decodedData.zeroForSaleToken \n   ? decodedData.amounts.amount1 \n    : decodedData.amounts.amount0;\n\n(decodedData.routes.strict && holdTokenAmtIn > decodedData.holdTokenDebt) \n   ? revert(ErrLib.ErrorCode.SWAP_AFTER_FLASH_LOAN_FAILED)\n```\n```\ntransfer the flashBalance to the recipient\ndecodedData.saleToken.safeTransfer(decodedDataExt.recipient, flashBalance)\n\ninvoke the WagmiLeverage callback function with updated parameters\nIWagmiLeverageFlashCallback(decodedDataExt.recipient).wagmiLeverageFlashCallback(\n    flashBalance,\n    interest,\n    decodedDataExt.originData\n)\n```
MEDIUM severity: The vulnerability audit reveals that several functions within the codebase lack essential input vali. The vulnerability audit reveals that several functions within the codebase lack essential input validation routines, compromising the integrity of the system. Specifically, the functions `includeAsset`, `includeAssimilator`, and `swapByOrigin` do not perform adequate checks on the input arguments be...

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    Assimilators.Assimilator storage _numeraireAssimilator = shell.assimilators[_numeraire];\n\n    _numeraireAssimilator.addr = _numeraireAssim;\n    _numeraireAssimilator.ix = uint8(shell.numeraires.length);\n\n    shell.numeraires.push(_numeraireAssimilator);\n\n    Assimilators.Assimilator storage _reserveAssimilator = shell.assimilators[_reserve];\n\n    _reserveAssimilator.addr = _reserveAssim;\n    _reserveAssimilator.ix = uint8(shell.reserves.length);\n\n    shell.reserves.push(_reserveAssimilator);\n\n    shell.weights.push(_weight.divu(1e18).add(uint256(1).divu(1e18)));\n}\n```\n```\nfunction includeAssimilator(\n    address _numeraire,\n    address _derivative,\n    address _assimilator\n) public onlyOwner {\n    shell.includeAssimilator(_numeraire, _derivative, _assimilator);\n}\n```\n```\nfunction includeAssimilator(\n    Shells.Shell storage shell,\n    address _numeraire,\n    address _derivative,\n    address _assimilator\n) internal {\n    Assimilators.Assimilator storage _numeraireAssim = shell.assimilators[_numeraire];\n\n    shell.assimilators[_derivative] = Assimilators.Assimilator(_assimilator, _numeraireAssim.ix);\n}\n```\n```\nfunction swapByOrigin(address _o, address _t, uint256 _oAmt, uint256 _mTAmt, uint256 _dline) public notFrozen returns (uint256 tAmt_) {\n    return transferByOrigin(_o, _t, _dline, _mTAmt, _oAmt, msg.sender);\n}\n```\n```\nfunction transferByOrigin(\n    address _origin,\n    address _target,\n    uint256 _dline,\n    uint256 _mTAmt,\n    uint256 _oAmt,\n    address _rcpnt\n) public notFrozen nonReentrant returns (uint256 tAmt_) {\n    Assimilators.Assimilator memory _o = shell.assimilators[_origin];\n    Assimilators.Assimilator memory _t = shell.assimilators[_target];\n\n    if (_o.ix == _t.ix) {\n        return _t.addr.outputNumeraire(_rcpnt, _o.addr.intakeRaw(_oAmt));\n    }\n```\n```\nfunction intakeRaw(uint256 _amount) public returns (int128 amount_, int128 balance_) {\n    dai.transferFrom(msg.sender, address(this), _amount);\n\n    amount_ = _amount.divu(1e18);\n}\n```\n```\nfunction outputNumeraire(address _dst, int128 _amount) public returns (uint256 amount_) {\n    amount_ = _amount * 1e18;\n\n    dai.transfer(_dst, uint256(amount_));\n\n    return amount_;\n}\n```
MEDIUM severity: The vulnerability lies in the inability to convert between custom and non-custom funds, which is a l. The vulnerability lies in the inability to convert between custom and non-custom funds, which is a limitation imposed by the `Funds.create()` and `Funds.createCustom()` functions. These functions enforce a restriction that there can only be one fund per account, as evident from the `require` stateme...

Vulnerable code:
```\nfunction create(\n    uint256 maxLoanDur_,\n    uint256 maxFundDur_,\n    address arbiter_,\n    bool compoundEnabled_,\n    uint256 amount_\n) external returns (bytes32 fund) {\n    require(fundOwner[msg.sender].lender!= msg.sender || msg.sender == deployer);\n    // Only allow one loan fund per address\n```\n```\nfunction createCustom(\n    uint256 minLoanAmt_,\n    uint256 maxLoanAmt_,\n    uint256 minLoanDur_,\n    uint256 maxLoanDur_,\n    uint256 maxFundDur_,\n    uint256 liquidationRatio_,\n    uint256 interest_,\n    uint256 penalty_,\n    uint256 fee_,\n    address arbiter_,\n    bool compoundEnabled_,\n    uint256 amount_\n) external returns (bytes32 fund) {\n    require(fundOwner[msg.sender].lender!= msg.sender || msg.sender == deployer);\n    // Only allow one loan fund per address\n```
MEDIUM severity: The Beanstalk protocol utilizes an internal virtual balance system to reduce transaction fees when u. The Beanstalk protocol utilizes an internal virtual balance system to reduce transaction fees when using tokens that are intended to remain within the protocol. The `LibTransfer` library manages every transfer between accounts, considering both the origin 'from' and destination 'to' modes of the in-...

Vulnerable code:
```\nif (fromMode == From.EXTERNAL && toMode == To.EXTERNAL) {\n    uint256 beforeBalance = token.balanceOf(recipient);\n    token.safeTransferFrom(sender, recipient, amount);\n    return token.balanceOf(recipient).sub(beforeBalance);\n}\n\namount = receiveToken(token, amount, sender, fromMode);\nsendToken(token, amount, recipient, toMode);\nreturn amount;\n```
MEDIUM severity: The vulnerability arises from a flawed bounty calculation mechanism in the `BountyV2` contract. Spec. The vulnerability arises from a flawed bounty calculation mechanism in the `BountyV2` contract. Specifically, the `_calculateMaximumBountyAmount` function incorrectly assigns the same bounty amount to every node, regardless of the actual validator's performance. This is because the calculation formu...

Vulnerable code:
```\nreturn \n    epochPoolSize\n   .add(_bountyWasPaidInCurrentEpoch)\n   .mul(\n        delegationController.getAndUpdateEffectiveDelegatedToValidator(\n            nodes.getValidatorId(nodeIndex),\n            currentMonth\n        )\n    )\n   .div(effectiveDelegatedSum);\n```
MEDIUM severity: The `confirmDeposit` and `confirmWithdraw` functions in the BaseTradeExecutor contract violate the ". The `confirmDeposit` and `confirmWithdraw` functions in the BaseTradeExecutor contract violate the "checks-effects-interactions" pattern, a fundamental principle in secure programming. This pattern ensures that a function's effects (e.g., modifying state variables) are separated from its interaction...

Vulnerable code:
```\nfunction confirmDeposit() public override onlyKeeper {\n    require(depositStatus.inProcess, "DEPOSIT_COMPLETED");\n    _confirmDeposit();\n    depositStatus.inProcess = false;\n}\n```\n```\nfunction confirmWithdraw() public override onlyKeeper {\n    require(withdrawalStatus.inProcess, "WIHDRW_COMPLETED");\n    _confirmWithdraw();\n    withdrawalStatus.inProcess = false;\n}\n```
MEDIUM severity: The `RewardDistributor` contract's requirement for the `onlyOwner` method `_setDistributionFactors` . The `RewardDistributor` contract's requirement for the `onlyOwner` method `_setDistributionFactors` to be called by an EOA (External Ownable Account) creates a potential roadblock for the eventual transition of the Owner role to a smart contract. This limitation arises from the fact that the `_setDi...

Vulnerable code:
```\n/**\n * @notice Update each iToken's distribution speed according to current global speed\n * @dev Only EOA can call this function\n */\nfunction updateDistributionSpeed() public override {\n    require(msg.sender == tx.origin, "only EOA can update speeds");\n    require(!paused, "Can not update speeds when paused");\n\n    _updateDistributionSpeed();\n}\n```
MEDIUM severity: The vulnerability allows an attacker to steal the reward of the actual game winner by force-ending t. The vulnerability allows an attacker to steal the reward of the actual game winner by force-ending the game. This is achieved by exploiting the game's mechanism for determining the winner, which is based on the index of the agents. The attacker can manipulate the game state by minting agents with lo...

Vulnerable code:
```\nuint256 activeAgents = gameInfo.activeAgents;\n\nif (activeAgents == 1) {\n    revert GameOver();\n```\n```\nuint256 agentId = agents[1].agentId;\n_agentOwnership(agentId);\n```\n```\nfunction test_forceWin() public {\n    address attacker = address(1337);\n\n    // Prefund attacker and user1\n    vm.deal(user1, PRICE * MAX_MINT_PER_ADDRESS);\n    vm.deal(attacker, PRICE * MAX_MINT_PER_ADDRESS);\n\n    // MINT some agents\n    vm.warp(_mintStart());\n    // Attacker wants to make sure he owns a bunch of agents with low IDs!!\n    vm.prank(attacker);\n    infiltration.mint{value: PRICE * 30}({quantity: 30});\n    // For simplicity, we mint only 1 agent to user 1 here, but it could be more, they could get wounded, etc.\n    vm.prank(user1);\n    infiltration.mint{value: PRICE * 1}({quantity: 1});\n    // Attacker also wants a bunch of agents with the highest IDs, as they are getting swapped with the killed agents (move forward)\n    vm.prank(attacker);\n    infiltration.mint{value: PRICE * 30}({quantity: 30});\n\n    vm.warp(_mintEnd());\n\n    // Start the game\n    vm.prank(owner);\n    infiltration.startGame();\n\n    vm.prank(VRF_COORDINATOR);\n    uint256[] memory randomWords = new uint256[](1);\n    randomWords[0] = 69_420;\n    VRFConsumerBaseV2(address(infiltration)).rawFulfillRandomWords(_computeVrfRequestId(1), randomWords);\n\n    // Now we are in round 2. We do have 1 wounded agent (but we can imagine any of our agent got wounded, doesn't really matter)\n\n    // We know with our HARDCODED RANDOMNESS that AGENT 3 gets wounded!!\n\n    // Whenever we get in a situation, that we own all active agents, but 1 and our agent has a lower index, we can instant win the game!!\n    // This is done by escaping all agents, at once, except the lowest index\n    uint256[] memory escapeIds = new uint256[](59);\n    escapeIds[0] = 1;\n    escapeIds[1] = 2;\n    uint256 i = 4; // Skipping our wounded AGENT 3\n    for (; i < 31;) {\n        escapeIds[i - 2] = i;\n        unchecked {++i;}\n    }\n    // Skipping 31 as this owned by user1\n    unchecked {++i\n```
MEDIUM severity: The `Harvester.rewardTokens` function in the `ConvexPositionHandler` contract does not account for L. The `Harvester.rewardTokens` function in the `ConvexPositionHandler` contract does not account for LDO tokens, which are a crucial part of the reward token list. This oversight results in a critical vulnerability, as the `harvester.harvest` function will not be able to execute its `_swapLidoForWETH`...

Vulnerable code:
```\naddress[] memory rewardTokens = harvester.rewardTokens();\n\nfor (uint256 i = 0; i < rewardTokens.length; i++) {\n    uint256 balance = IERC20(rewardTokens[i]).balanceOf(address(this));\n\n    if (balance > 0) {\n        IERC20(rewardTokens[i]).safeTransfer(\n            address(harvester),\n            balance\n        );\n    }\n}\n\nharvester.harvest();\n```\n```\nfunction rewardTokens() external pure override returns (address[] memory) {\n    address[] memory rewards = new address[](2);\n    rewards[0] = address(crv);\n    rewards[1] = address(cvx);\n    return rewards;\n}\n```
MEDIUM severity: The `RewardsDistributor` function in the `NodeRunner` module contains a redundant code block that ch. The `RewardsDistributor` function in the `NodeRunner` module contains a redundant code block that checks the same condition twice. Specifically, the function adjusts the `fees[]` array for a node by checking if `fees[1].sinceEpoch` is not equal to 0. This check is performed twice in a row, with the...

Vulnerable code:
```\nif (fees[1].sinceEpoch!= 0) {\n    if (Accumulators.getCurrentEpochNumber() < fees[1].sinceEpoch + delegationParamsEpochDelay) {\n        revert SetDelegationFeeNotReady();\n    }\n}\n\nif (fees[1].sinceEpoch!= 0) {\n    fees[0] = fees[1];\n}\n```
MEDIUM severity: The `checkAfterExecution()` function is designed to ensure that the safe's threshold is not modified. The `checkAfterExecution()` function is designed to ensure that the safe's threshold is not modified by a transaction executed by signers. However, a vulnerability exists in the implementation that allows signers to bypass this check and change the threshold within a transaction.\n\nThe `_getCorrect...

Vulnerable code:
```\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 `ERC5095.deposit` function in the provided smart contract does not adequately verify the amount . The `ERC5095.deposit` function in the provided smart contract does not adequately verify the amount of shares received by the user after depositing base tokens. This oversight can lead to a loss of funds for the user. \n\nThe function allows users to deposit base tokens and receive shares in return....

Vulnerable code:
```\nfunction deposit(address r, uint256 a) external override returns (uint256) {\n    if (block.timestamp > maturity) {\n        revert Exception(\n            21,\n            block.timestamp,\n            maturity,\n            address(0),\n            address(0)\n        );\n    }\n    uint128 shares = Cast.u128(previewDeposit(a));\n    Safe.transferFrom(IERC20(underlying), msg.sender, address(this), a);\n    uint128 returned = IMarketPlace(marketplace).sellUnderlying(\n        underlying,\n        maturity,\n        Cast.u128(a),\n        shares - (shares / 100)\n    );\n    _transfer(address(this), r, returned);\n    return returned;\n```\n```\nuint128 returned = \n    IMarketPlace(marketplace).sellUnderlying(\n        underlying, \n        maturity, \n        Cast.u128(a), \n        shares - (shares / 100)\n    );\n```
MEDIUM severity: The `setCustomContract` function in the smart contract allows the owner to define a custom ERC20 con. The `setCustomContract` function in the smart contract allows the owner to define a custom ERC20 contract for the native token. However, this function does not verify whether the target contract has already been defined as a bridge to a native token or not. This design flaw enables the owner to expl...

Vulnerable code:
```\nfunction setCustomContract(\n    address _nativeToken,\n    address _targetContract\n) external onlyOwner isNewToken(_nativeToken) {\n    nativeToBridgedToken[_nativeToken] = _targetContract;\n    bridgedToNativeToken[_targetContract] = _nativeToken;\n    emit CustomContractSet(_nativeToken, _targetContract);\n}\n```\n```\n} else {\n    bridgedToken = nativeMappingValue;\n    if (nativeMappingValue == EMPTY) {\n        bridgedToken = deployBridgedToken(_nativeToken, _tokenMetadata);\n        bridgedToNativeToken[bridgedToken] = _nativeToken;\n        nativeToBridgedToken[_nativeToken] = bridgedToken;\n    }\n    BridgedToken(bridgedToken).mint(_recipient, _amount);\n}\n```
MEDIUM severity: The project's documentation is severely lacking, with sparse or non-existent inline comments through. The project's documentation is severely lacking, with sparse or non-existent inline comments throughout the codebase. Furthermore, the technical documentation outlining the system's design rationale is scarce, making it challenging to comprehend the intricate relationships between components and the...

Vulnerable code:
```\nrequire(nodeRefundBalance == 0, "Refund balance not zero")\n```\n```\nrocketMinipoolManager.removeVacantMinipool()\n```\n```\nif (ownerCalling) {\n    _finalise();\n}\n```
MEDIUM severity: The code snippet in the provided file, `contracts/strategy/gmx/GMXChecks.sol`, contains instances wh. The code snippet in the provided file, `contracts/strategy/gmx/GMXChecks.sol`, contains instances where incorrect error messages are used for reverts. Specifically, the `revert` statements in lines 68-69, 74-75, and 351-352 are using the `Errors.InsufficientDepositAmount` error message in situations...

Vulnerable code:
```\nif (self.depositCache.depositParams.amt == 0)\n    revert Errors.InsufficientDepositAmount();\n\nif (depositValue == 0)\n    revert Errors.InsufficientDepositAmount();\n\nif (self.compoundCache.depositValue == 0)\n    revert Errors.InsufficientDepositAmount();\n```
MEDIUM severity: The `StrategyManager` contract's `initialize` function computes a domain separator using the EIP-712. The `StrategyManager` contract's `initialize` function computes a domain separator using the EIP-712 domain separator format, which is used for signature verification. The domain separator is computed by hashing a string, the chain ID, and the contract's address. However, this approach has a critica...

Vulnerable code:
```\nbytes32 public DOMAIN_SEPARATOR;\n```\n```\nfunction initialize(\n    address initialOwner,\n    address initialStrategyWhitelister,\n    IPauserRegistry _pauserRegistry,\n    uint256 initialPausedStatus,\n    uint256 _withdrawalDelayBlocks\n) \n    external\n    initializer\n{\n    DOMAIN_SEPARATOR = keccak256(abi.encode(DOMAIN_TYPEHASH, bytes("EigenLayer"), block.chainid, address(this)));\n}\n```\n```\nbytes32 public constant DOMAIN_TYPEHASH = \n    keccak256("EIP712Domain(string name,uint256 chainId,address verifyingContract)");\n```\n```\nDOMAIN_SEPARATOR = keccak256(abi.encode(DOMAIN_TYPEHASH, bytes("EigenLayer"), block.chainid, address(this)))\n```\n```\nbytes32 public constant DOMAIN_TYPEHASH = \n    keccak256("EIP712Domain(string name,uint256 chainId,address verifyingContract)");\n```
MEDIUM severity: The vulnerability allows an attacker to fully block the `PublicVault.processEpoch` function, prevent. The vulnerability allows an attacker to fully block the `PublicVault.processEpoch` function, preventing users from receiving their funds. This is achieved by manipulating the `WithdrawProxy` shares and total supply.\n\nWhen a liquidity provider redeems their shares from the `PublicVault`, the `redee...

Vulnerable code:
```\nfunction redeemFutureEpoch(\n    uint256 shares,\n    address receiver,\n    address owner,\n    uint64 epoch\n) public virtual returns (uint256 assets) {\n    require(epoch >= currentEpoch, "Exit epoch too low");\n\n    require(msg.sender == owner, "Only the owner can redeem");\n\n    ERC20(address(this)).safeTransferFrom(owner, address(this), shares);\n\n    _deployWithdrawProxyIfNotDeployed(epoch);\n\n    emit Withdraw(msg.sender, receiver, owner, assets, shares);\n\n    WithdrawProxy(withdrawProxies[epoch]).mint(receiver, shares);\n}\n```\n```\nif (withdrawProxies[currentEpoch]!= address(0)) {\n    uint256 proxySupply = WithdrawProxy(withdrawProxies[currentEpoch]).totalSupply();\n\n    liquidationWithdrawRatio = proxySupply.mulDivDown(1e18, totalSupply());\n\n    if (liquidationAccountants[currentEpoch]!= address(0)) {\n        LiquidationAccountant(liquidationAccountants[currentEpoch]).setWithdrawRatio(liquidationWithdrawRatio);\n    }\n\n    uint256 withdrawAssets = convertToAssets(proxySupply);\n\n    uint256 withdrawLiquidations = liquidationsExpectedAtBoundary[currentEpoch].mulDivDown(liquidationWithdrawRatio, 1e18);\n    withdrawReserve = withdrawAssets - withdrawLiquidations;\n\n    _burn(address(this), proxySupply);\n\n    _decreaseYIntercept(withdrawAssets);\n}\n```
MEDIUM severity: The PeriodicPrizeStrategy's `canStartAward()` and `canCompleteAward()` functions exhibit inconsisten. The PeriodicPrizeStrategy's `canStartAward()` and `canCompleteAward()` functions exhibit inconsistent behavior when compared to their corresponding modifiers, `requireCanStartAward()` and `requireCanCompleteAward()`. This discrepancy can lead to unexpected outcomes and potential security vulnerabili...

Vulnerable code:
```\nfunction canStartAward() external view returns (bool) {\n    return _isPrizePeriodOver() &&!isRngRequested();\n}\n```\n```\nmodifier requireCanStartAward() {\n    require(_isPrizePeriodOver(), "PeriodicPrizeStrategy/prize-period-not-over");\n    require(!isRngRequested() || isRngTimedOut(), "PeriodicPrizeStrategy/rng-already-requested");\n}\n```\n```\nfunction canCompleteAward() external view returns (bool) {\n    return isRngRequested() && isRngCompleted();\n}\n```\n```\nmodifier requireCanCompleteAward() {\n    require(_isPrizePeriodOver(), "PeriodicPrizeStrategy/prize-period-not-over");\n    require(isRngRequested(), "PeriodicPrizeStrategy/rng-not-requested");\n    require(isRngCompleted(), "PeriodicPrizeStrategy/rng-not-complete");\n}\n```