Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The `castVote` function in the Governance contract allows any user to cast a vote, regardless of whe. The `castVote` function in the Governance contract allows any user to cast a vote, regardless of whether they have any votes or not. This is because the function does not verify the user's voting power before processing the vote. The `staking.getVotes` function, which retrieves the user's voting pow...

Vulnerable code:
```\nfunction _castVote(address _voter, uint256 _proposalId, uint8 _support) internal returns (uint) {\n    if (state(_proposalId)!= ProposalState.Active) {\n        revert InvalidStatus();\n    }\n\n    if (_support > 2) {\n        revert InvalidInput();\n    }\n\n    Proposal storage proposal = proposals[_proposalId];\n\n    Receipt storage receipt = proposal.receipts[_voter];\n    if (receipt.hasVoted) {\n        revert AlreadyVoted();\n    }\n\n    uint24 votes = (staking.getVotes(_voter)).toUint24();\n\n    if (_support == 0) {\n        proposal.againstVotes = proposal.againstVotes + votes;\n    } else if (_support == 1) {\n        proposal.forVotes = proposal.forVotes + votes;\n    } else if (_support == 2) {\n        proposal.abstainVotes = proposal.abstainVotes + votes;\n    }\n\n    receipt.hasVoted = true;\n    receipt.support = _support;\n    receipt.votes = votes;\n\n    totalCommunityScoreData.votes++;\n    userCommunityScoreData[_voter].votes++;\n\n    return votes;\n}\n```
MEDIUM severity: This vulnerability is characterized by the presence of numerous functions that are defined in the co. This vulnerability is characterized by the presence of numerous functions that are defined in the codebase but lack any actual implementation. Specifically, these functions are accompanied by a revert statement with a message indicating that they are not implemented. This practice can lead to comple...

Vulnerable code:
```\nfunction getAllDelegationRequests() external returns(uint[] memory) {\n    revert("Not implemented");\n}\n\nfunction getDelegationRequestsForValidator(uint validatorId) external returns(uint[] memory) {\n    revert("Not implemented");\n}\n```
MEDIUM severity: The XMozToken's `_beforeTokenTransfer` function is designed to restrict token transfers to only whit. The XMozToken's `_beforeTokenTransfer` function is designed to restrict token transfers to only whitelisted addresses or minting events. However, a closer examination of the code reveals a critical flaw. Despite the intention to prohibit transfers from non-whitelisted addresses, the current implemen...

Vulnerable code:
```\n/**\n * @dev Hook override to forbid transfers except from whitelisted addresses and minting\n */\nfunction _beforeTokenTransfer(address from, address to, uint256 /*amount*/) internal view override {\n    require(from == address(0) || _transferWhitelist.contains(from) || _transferWhitelist.contains(to), "transfer: not allowed");\n}\n```
MEDIUM severity: The MultiInvoker contract, a derivative of the Kept contract, fails to accurately calculate and refu. The MultiInvoker contract, a derivative of the Kept contract, fails to accurately calculate and refund the calldata fee to the keeper. This issue arises from the `_calldataFee` function, which is overridden in the Kept_Arbitrum and Kept_Optimism contracts, but not in the MultiInvoker contract. As a...

Vulnerable code:
```\nmodifier keep(\n    KeepConfig memory config,\n    bytes calldata applicableCalldata,\n    uint256 applicableValue,\n    bytes memory data\n) {\n    uint256 startGas = gasleft();\n\n    uint256 applicableGas = startGas - gasleft();\n    (UFixed18 baseFee, UFixed18 calldataFee) = (\n        _baseFee(applicableGas, config.multiplierBase, config.bufferBase),\n        _calldataFee(applicableCalldata, config.multiplierCalldata, config.bufferCalldata)\n    );\n\n    UFixed18 keeperFee = UFixed18.wrap(applicableValue).add(baseFee).add(calldataFee).mul(_etherPrice());\n    _raiseKeeperFee(keeperFee, data);\n    keeperToken().push(msg.sender, keeperFee);\n\n    emit KeeperCall(msg.sender, applicableGas, applicableValue, baseFee, calldataFee, keeperFee);\n}\n```
MEDIUM severity: This vulnerability occurs when the codebase contains checks to ensure that certain numerical values . This vulnerability occurs when the codebase contains checks to ensure that certain numerical values do not exceed the maximum value that can be represented by a specific data type. Specifically, the checks use the `max` property of the data type, which is inclusive, meaning that the maximum value it...

Vulnerable code:
```\nrequire(accumulatedNOTEPerNToken < uint128.max);\n```\n```\nrequire(blockTime < type(uint32).max);\n```\n```\nrequire(totalSupply <= uint96.max);\nrequire(blockTime <= uint32.max);\n```
MEDIUM severity: The `_repayLoan` function, responsible for repaying a loan, is vulnerable to failure if the lender's. The `_repayLoan` function, responsible for repaying a loan, is vulnerable to failure if the lender's address is blacklisted by the loan token. This is because the function directly transfers the loan token to the lender using the `safeTransferFrom` method, which may be blocked by the token's blackli...

Vulnerable code:
```\nfunction _repayLoan() internal virtual {\n    bid.loanDetails.lendingToken.safeTransferFrom(\n        _msgSenderForMarket(bid.marketplaceId),\n        lender,\n        paymentAmount\n    );\n```\n```\nfunction getLoanLender(uint256 _bidId)\n    public\n    view\n    returns (address lender_)\n{\n    lender_ = bids[_bidId].lender;\n\n    if (lender_ == address(lenderManager)) {\n        return lenderManager.ownerOf(_bidId);\n    }\n}\n```
MEDIUM severity: The AaveLeverageStrategyExtension relies solely on oracle base slippage parameters to determine the . The AaveLeverageStrategyExtension relies solely on oracle base slippage parameters to determine the slippage tolerance during rebalancing, which can lead to significant losses due to sandwich attacks. Specifically, the strategy uses the oracle's price data to calculate the minimum repay units, witho...

Vulnerable code:
```\nfunction _calculateMinRepayUnits(\n    uint256 _collateralRebalanceUnits,\n    uint256 _slippageTolerance,\n    ActionInfo memory _actionInfo\n) internal pure returns (uint256) {\n    return (\n        _collateralRebalanceUnits\n           .preciseMul(_actionInfo.collateralPrice)\n           .preciseDiv(_actionInfo.borrowPrice)\n           .preciseMul(\n                PreciseUnitMath.preciseUnit().sub(_slippageTolerance)\n            )\n    );\n}\n```
MEDIUM severity: The `checkMembership` function in the Merkle tree implementation allows for the existence proof of t. The `checkMembership` function in the Merkle tree implementation allows for the existence proof of the same leaf node in multiple locations within the tree. This is achieved by iteratively constructing a hypothetical root hash using the `leaf`, `index`, and `proof` parameters. The function uses a ps...

Vulnerable code:
```\nuint256 j = index;\n\nfor (uint256 i = 32; i <= proof.length; i += 32) {\n    assembly {\n        proofElement := mload(add(proof, i))\n    }\n    if (j % 2 == 0) {\n        computedHash = keccak256(abi.encodePacked(NODE_SALT, computedHash, proofElement));\n    } else {\n        computedHash = keccak256(abi.encodePacked(NODE_SALT, proofElement, computedHash));\n    }\n    j = j / 2;\n}\n```\n```\nit('should accidentally allow different indices to use the same proof', async () => {\n  const rootHash = this.merkleTree.root;\n  const proof = this.merkleTree.getInclusionProof(leaves[2]);\n\n  const result = await this.merkleContract.checkMembership(\n    leaves[2],\n    2,\n    rootHash,\n    proof,\n  );\n  expect(result).to.be.true;\n\n  const nextResult = await this.merkleContract.checkMembership(\n    leaves[2],\n    6,\n    rootHash,\n    proof,\n  );\n  expect(nextResult).to.be.true;\n\n  const nextNextResult = await this.merkleContract.checkMembership(\n    leaves[2],\n    10,\n    rootHash,\n    proof,\n  );\n  expect(nextNextResult).to.be.true;\n});\n```
MEDIUM severity: The FlashLoanLiquidate.JOJOFlashLoan function in the provided smart contract lacks a crucial mechani. The FlashLoanLiquidate.JOJOFlashLoan function in the provided smart contract lacks a crucial mechanism for controlling slippage when swapping USDC. Slippage refers to the difference between the expected and actual amount received after a swap operation. In the absence of slippage control, an attacke...

Vulnerable code:
```\nfunction JOJOFlashLoan(\n    address asset,\n    uint256 amount,\n    address to,\n    bytes calldata param\n) external {\n    (address approveTarget, address swapTarget, uint256 minReceive, bytes memory data) = abi.decode(param, (address, address, uint256, bytes));\n    IERC20(asset).approve(approveTarget, amount);\n    (bool success,) = swapTarget.call(data);\n    if (success == false) {\n        assembly {\n            let ptr := mload(0x40)\n            let size := returndatasize()\n            returndatacopy(ptr, 0, size)\n            revert(ptr, size)\n        }\n    }\n    uint256 USDCAmount = IERC20(USDC).balanceOf(address(this));\n    require(USDCAmount >= minReceive, "receive amount is too small");\n}\n\nfunction repayJUSD(\n    address asset,\n    uint256 amount,\n    address to,\n    bytes memory param\n) external {\n    IERC20(asset).safeTransferFrom(msg.sender, address(this), amount);\n    uint256 minReceive;\n    if (asset!= USDC) {\n        (address approveTarget, address swapTarget, uint256 minAmount, bytes memory data) = abi.decode(param, (address, address, uint256, bytes));\n        IERC20(asset).approve(approveTarget, amount);\n        (bool success,) = swapTarget.call(data);\n        if (success == false) {\n            assembly {\n                let ptr := mload(0x40)\n                let size := returndatasize()\n                returndatacopy(ptr, 0, size)\n                revert(ptr, size)\n            }\n        }\n        minReceive = minAmount;\n    }\n\n    uint256 USDCAmount = IERC20(USDC).balanceOf(address(this));\n    require(USDCAmount >= minReceive, "receive amount is too small");\n```
MEDIUM severity: The `claimDefaulted` function, responsible for processing unclaimed tokens, may fail to deliver the . The `claimDefaulted` function, responsible for processing unclaimed tokens, may fail to deliver the expected outcome due to a critical flaw in its implementation. Specifically, the function deletes the loan data (`loans[loanID_]`) without first verifying whether the loan has an unclaimed token (`loa...

Vulnerable code:
```\nfunction claimDefaulted(uint256 loanID_) external returns (uint256, uint256, uint256) {\n    Loan memory loan = loans[loanID_];\n    delete loans[loanID_];\n}\n```
MEDIUM severity: The `StakingRewardsManager::topUp(...)` function, responsible for simultaneously topping up multiple. The `StakingRewardsManager::topUp(...)` function, responsible for simultaneously topping up multiple `StakingRewards` contracts, exhibits a critical issue in its distribution mechanism. The function iterates over the provided indices of the `StakingRewards` contracts in the `stakingContracts` array,...

Vulnerable code:
```\nfunction topUp(\n    address source,\n    uint256[] memory indices\n) external onlyRole(EXECUTOR_ROLE) {\n    for (uint i = 0; i < indices.length; i++) {\n        StakingRewards staking = stakingContracts[i];\n        StakingConfig memory config = stakingConfigs[staking];\n\n        staking.setRewardsDuration(config.rewardsDuration);\n\n        rewardToken.transferFrom(\n            source,\n            address(staking),\n            config.rewardAmount\n        );\n\n        staking.notifyRewardAmount(config.rewardAmount);\n\n        emit ToppedUp(staking, config);\n    }\n}\n```
MEDIUM severity: The vulnerability lies in the logic of removing an owner from a personal account in the PersonalAcco. The vulnerability lies in the logic of removing an owner from a personal account in the PersonalAccountRegistry. Specifically, when an owner is removed, only the `removedAtBlockNumber` value is updated, whereas the `added` flag remains set to `true`. This allows the removed owner to continue being c...

Vulnerable code:
```\naccounts[account].owners[owner].removedAtBlockNumber = block.number;\n\nemit AccountOwnerRemoved(account, owner);\n```\n```\nfunction _verifySender(\n    address account\n) \nprivate \nreturns (address) {\n    address sender = _getContextSender();\n\n    if (!accounts[account].owners[sender].added) {\n        require(accounts[account].salt == 0);\n        bytes32 salt = keccak256(abi.encodePacked(sender));\n        require(account == _computeAccountAddress(salt));\n        accounts[account].salt = salt;\n        accounts[account].owners[sender].added = true;\n        emit AccountOwnerAdded(account, sender);\n    }\n\n    return sender;\n}\n```
MEDIUM severity: The vulnerability lies in the `openPosition` function of the PartyB's pending locked balance calcula. The vulnerability lies in the `openPosition` function of the PartyB's pending locked balance calculation. When a position is partially filled, an accounting error occurs, leading to the loss of assets for PartyB.\n\nThe issue arises when the `openPosition` function removes the balance already filled...

Vulnerable code:
```\nFile: PartyBFacetImpl.sol\n\nfunction openPosition(\n    uint256 quoteId,\n    uint256 filledAmount,\n    uint256 openedPrice,\n    PairUpnlAndPriceSig memory upnlSig\n) internal returns (uint256 currentId) {\n    //...SNIP...\n\n    LibQuote.removeFromPendingQuotes(quote);\n\n    //...SNIP...\n\n    if (quote.partyA == quote.partyB) {\n        quoteLayout.quoteIdsOf[quote.partyA].push(currentId);\n    } else {\n        accountLayout.pendingLockedBalances[quote.partyA].sub(filledLockedValues);\n        accountLayout.partyBPendingLockedBalances[quote.partyB][quote.partyA].sub(filledLockedValues);\n    }\n```
MEDIUM severity: The vulnerability lies in the Auction#_computeTotalRewards function, where the calculation of total . The vulnerability lies in the Auction#_computeTotalRewards function, where the calculation of total rewards is susceptible to precision loss due to the use of floating-point arithmetic. This precision loss can lead to a discrepancy between the calculated total rewards and the actual total rewards, r...

Vulnerable code:
```\nfor (uint256 i = 0; i < numRecipients; ) {\n    expectedTotalValue += amounts[i];\n\n    unchecked {\n        i++;\n    }\n}\n\nif (msg.value!= expectedTotalValue) {\n    revert INVALID_DEPOSIT();\n}\n```\n```\nuint256 totalBPS = _founderRewardBps + referralRewardsBPS + builderRewardsBPS;\n\n// Calculate total rewards\nsplit.totalRewards = (_finalBidAmount * totalBPS) / BPS_PER_100_PERCENT;\n\n// Initialize arrays\nsplit.recipients = new address[](arraySize);\nsplit.amounts = new uint256[](arraySize);\nsplit.reasons = new bytes4[](arraySize);\n\n// Set builder reward\nsplit.recipients[0] = builderRecipient;\nsplit.amounts[0] = (_finalBidAmount * builderRewardsBPS) / BPS_PER_100_PERCENT;\n\n// Set referral reward\nsplit.recipients[1] = _currentBidRefferal!= address(0)? _currentBidRefferal : builderRecipient;\nsplit.amounts[1] = (_finalBidAmount * referralRewardsBPS) / BPS_PER_100_PERCENT;\n\n// Set founder reward if enabled\nif (hasFounderReward) {\n    split.recipients[2] = founderReward.recipient;\n    split.amounts[2] = (_finalBidAmount * _founderRewardBps) / BPS_PER_100_PERCENT;\n}\n```\n```\nsplit.totalRewards = (19000) / 100000 = 190 / 100 = 0.19\n\nsplit.amounts[0] = (9500) / 100000 = 95 / 100 = 0.95\nsplit.amounts[1] = (9500) / 100000 = 95 / 100 = 0.95\n```\n```\nif (split.totalRewards!= 0) {\n    rewardsManager.depositBatch(\n        value: split.totalRewards\n    )(split.recipients, split.amounts, split.reasons, "");\n}\n```
MEDIUM severity: The Bancor formula update mechanism allows shareholders to modify the formula contract, which can le. The Bancor formula update mechanism allows shareholders to modify the formula contract, which can lead to unpredictable price fluctuations within the current batch. This vulnerability arises from the fact that the formula update can occur at any time, including during an ongoing batch, without any s...

Vulnerable code:
```\nfunction updateFormula(IBancorFormula _formula) external auth(UPDATE_FORMULA_ROLE) {\n    require(isContract(_formula), ERROR_CONTRACT_IS_EOA);\n\n    _updateFormula(_formula);\n}\n```
MEDIUM severity: The `Redemptions are blocked when L2 sequencers are down` vulnerability occurs when the `Logic::rede. The `Redemptions are blocked when L2 sequencers are down` vulnerability occurs when the `Logic::redeemTokensWithPayload` function fails to verify the sender's identity correctly, leading to potential downtime and disruption of the redemption process. Specifically, the function relies on the `msg.sen...

Vulnerable code:
```\nrequire(\n    msg.sender.toUniversalAddress() == deposit.mintRecipient,\n    "caller must be mintRecipient"\n);\n```
MEDIUM severity: The vulnerability lies in the implementation of access control mechanisms in the RocketDAOProtocolSe. The vulnerability lies in the implementation of access control mechanisms in the RocketDAOProtocolSettings and RocketDAONodeTrustedSettings contracts. Specifically, the `onlyDAOProtocolProposal` and `onlyDAONodeTrustedProposal` modifiers, which are intended to restrict state-changing operations to a...

Vulnerable code:
```\nmodifier onlyDAOProtocolProposal {\n    if (getBool(keccak256(abi.encodePacked(settingNameSpace, "deployed")))) {\n        require(getContractAddress('rocketDAOProtocolProposals') == msg.sender, "Only DAO Protocol Proposals contract can update a setting");\n    }\n}\n```\n```\nmodifier onlyDAONodeTrustedProposal {\n    if (getBool(keccak256(abi.encodePacked(settingNameSpace, "deployed")))) {\n        require(getContractAddress('rocketDAONodeTrustedProposals') == msg.sender, "Only DAO Node Trusted Proposals contract can update a setting");\n    }\n}\n```
MEDIUM severity: The HardVault protocol, as designed, intends to deposit underlying assets into Compound, a decentral. The HardVault protocol, as designed, intends to deposit underlying assets into Compound, a decentralized lending platform, to generate interest. This process is expected to occur through the `deposit` function, which accepts an underlying token amount and issues a share token in return. Conversely,...

Vulnerable code:
```\n/**\n * @notice Deposit underlying assets on Compound and issue share token\n * @param amount Underlying token amount to deposit\n * @return shareAmount cToken amount\n */\nfunction deposit(address token, uint256 amount) {\n    // rest of code\n}\n\n/**\n * @notice Withdraw underlying assets from Compound\n * @param shareAmount Amount of cTokens to redeem\n * @return withdrawAmount Amount of underlying assets withdrawn\n */\nfunction withdraw(address token, uint256 shareAmount) {\n    // rest of code\n}\n```
MEDIUM severity: The `BalancedVault` contract is vulnerable to a loss of funds and a global settlement flywheel/user . The `BalancedVault` contract is vulnerable to a loss of funds and a global settlement flywheel/user settlement flywheel desynchronization issue. This occurs when an epoch becomes "stale", causing new deposits and redemptions to be treated as "pending". A malicious user can exploit this by making an...

Vulnerable code:
```\nit('pending deposit pushed by 1 epoch causing shares difference', async () => {\n    const smallDeposit = utils.parseEther('1000')\n    const smallestDeposit = utils.parseEther('0.000001')\n\n    await updateOracleEth() // epoch now stale\n    await vault.connect(user).deposit(smallDeposit, user.address)\n    await updateOracleBtc()\n    await vault.sync()\n\n    await updateOracleEth() // epoch now stale\n    await vault.connect(user2).deposit(smallestDeposit, user.address)\n    await updateOracleBtc()\n    await vault.sync()\n\n    await updateOracle()\n    await vault.syncAccount(user.address)\n\n    const totalSupply = await vault.totalSupply()\n    const balanceUser1 = await vault.balanceOf(user.address)\n    const balanceUser2 = await vault.balanceOf(user2.address)\n\n    console.log(totalSupply);\n    console.log(balanceUser1.add(balanceUser2));\n})\n```
MEDIUM severity: The `LiquidityMining` contract's `investDAI` function allows an attacker to manipulate the policy bo. The `LiquidityMining` contract's `investDAI` function allows an attacker to manipulate the policy book address, enabling them to siphon all funds without investing any DAI. This vulnerability arises from the fact that the `policyBookAddr` parameter is not properly validated before being used to inte...

Vulnerable code:
```\nfunction investDAI(uint256 _tokensAmount, address _policyBookAddr) external override {\n    //...\n```\n```\nIPolicyBook(_policyBookAddr).addLiquidityFromLM(msg.sender, _tokensAmount)\n```
MEDIUM severity: The `NodeRegistry.registerNodeFor()` function lacks essential security measures, specifically replay. The `NodeRegistry.registerNodeFor()` function lacks essential security measures, specifically replay protection and expiration, allowing an owner to register a node with a signer that is not the owner. This vulnerability enables the owner to submit a node with properties, including the URL, to multi...

Vulnerable code:
```\nbytes32 tempHash = keccak256(\n    abi.encodePacked(\n        _url,\n        _props,\n        _timeout,\n        _weight,\n        msg.sender\n    )\n);\n```
MEDIUM severity: The Curve vault's `TwoTokenPoolUtils._getTimeWeightedPrimaryBalance` function is responsible for cal. The Curve vault's `TwoTokenPoolUtils._getTimeWeightedPrimaryBalance` function is responsible for calculating the total value of the LP Pool tokens denominated in the primary token. However, when the Curve vault comprises tokens with different decimals, this function can produce incorrect results, le...

Vulnerable code:
```\nFile: TwoTokenPoolUtils.sol\n\nfunction _getTimeWeightedPrimaryBalance(\n    TwoTokenPoolContext memory poolContext,\n    StrategyContext memory strategyContext,\n    uint256 poolClaim,\n    uint256 oraclePrice,\n    uint256 spotPrice\n) internal view returns (uint256 primaryAmount) {\n    strategyContext._checkPriceLimit(oraclePrice, spotPrice);\n\n    uint256 totalSupply = poolContext.poolToken.totalSupply();\n    uint256 primaryBalance = poolContext.primaryBalance * poolClaim / totalSupply;\n    uint256 secondaryBalance = poolContext.secondaryBalance * poolClaim / totalSupply;\n\n    uint256 secondaryAmountInPrimary = secondaryBalance * strategyContext.poolClaimPrecision / oraclePrice;\n\n    uint256 primaryPrecision = 10 ** poolContext.primaryDecimals;\n    primaryAmount = (primaryBalance + secondaryAmountInPrimary) * primaryPrecision / strategyContext.poolClaimPrecision;\n}\n```\n```\nprimaryBalance = poolContext.primaryBalance * poolClaim / totalSupply;\nsecondaryBalance = poolContext.secondaryBalance * poolClaim / totalSupply;\n```\n```\nsecondaryAmountInPrimary = secondaryBalance * strategyContext.poolClaimPrecision / oraclePrice;\n\nsecondaryAmountInPrimary = (50 * 10**18) / (1 * 10**18)\n\nsecondaryAmountInPrimary = (50 * 10**6)\n\nsecondaryAmountInPrimary = 50 * 10**6\n```\n```\nprimaryAmount = (primaryBalance + secondaryAmountInPrimary) * primaryPrecision / strategyContext.poolClaimPrecision;\n\nprimaryAmount = ((50 * 10**18) + (50 * 10**6)) * 10**18 / 10**18\n\nprimaryAmount = ((50 * 10**18) + (50 * 10**6))  # cancel out the 10^18\nprimaryAmount = 50 DAI + 0.00000000005 DAI = 50.00000000005 DAI\n```\n```\nprimaryBalance = poolContext.primaryBalance * poolClaim / totalSupply;\nsecondaryBalance = poolContext.secondaryBalance * poolClaim / totalSupply;\n```\n```\nsecondaryAmountInPrimary = secondaryBalance * strategyContext.poolClaimPrecision / oraclePrice;\n\nsecondaryAmountInPrimary = (50 * 10**18) / (1 * 10**18)\n\nsecondaryAmountInPrimary = 50 * 10**18\n```\n```\nprimaryAmount = (primaryBalance + secondaryAmountInPrimary) * primaryPrecision / strategyContext.poolClaimPrecision;\n\nprimaryAmount = ((50 * 10**6) + (50 * 10**18)) * 10**6 / 10**18\nprimaryAmount = ((50 * 10**6) + (50 * 10**18)) / 10**12\nprimaryAmount = 50000000.00005\n```