Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The vulnerability lies in the `AssetProxyOwner` contract's handling of transaction confirmations. Sp. The vulnerability lies in the `AssetProxyOwner` contract's handling of transaction confirmations. Specifically, changing the owners or required confirmations for a transaction can cause a previously confirmed transaction to become unconfirmed, effectively rendering it unexecutable until a new confir...

Vulnerable code:
```\nfunction executeTransaction(uint256 transactionId)\n    public\n    notExecuted(transactionId)\n    fullyConfirmed(transactionId)\n```\n```\nfunction isConfirmed(uint256 transactionId)\n    public\n    view\n    returns (bool)\n{\n    uint256 count = 0;\n    for (uint256 i = 0; i < owners.length; i++) {\n        if (confirmations[transactionId][owners[i]]) {\n            count += 1;\n        }\n        if (count == required) {\n            return true;\n        }\n    }\n    return false;\n}\n```\n```\nfunction confirmTransaction(uint256 transactionId)\n    public\n    ownerExists(msg.sender)\n    transactionExists(transactionId)\n    notConfirmed(transactionId, msg.sender)\n    notFullyConfirmed(transactionId)\n{\n    confirmations[transactionId][msg.sender] = true;\n    emit Confirmation(msg.sender, transactionId);\n    if (isConfirmed(transactionId)) {\n        _setConfirmationTime(transactionId, block.timestamp);\n    }\n}\n```
MEDIUM severity: The Stargate `STG` rewards are not accurately accounted for by the `StakedStargateAM.sol` contract. . The Stargate `STG` rewards are not accurately accounted for by the `StakedStargateAM.sol` contract. Specifically, when the `deposit()` function is called, the `LP_STAKING_TIME` contract clears and sends rewards to the caller, but the `StakedStargateAM` contract does not update its internal state to...

Vulnerable code:
```\nuint256 currentRewardGlobal = _getCurrentReward(positionState_.asset);\nuint256 deltaReward = currentRewardGlobal - assetState_.lastRewardGlobal;\n```\n```\nfunction _getCurrentReward(address asset) internal view override returns (uint256 currentReward) {\n    currentReward = LP_STAKING_TIME.pendingEmissionToken(assetToPid[asset], address(this));\n}\n```\n```\nfunction testFork_WrongRewards() public {\n    uint256 initBalance = 1000 * 10 ** USDbC.decimals();\n\n    vm.startPrank(users.accountOwner);\n    deal(address(USDbC), users.accountOwner, initBalance);\n\n    USDbC.approve(address(router), initBalance);\n    router.addLiquidity(poolId, initBalance, users.accountOwner);\n\n    uint256 stakedAmount = ERC20(address(pool)).balanceOf(users.accountOwner);\n    ERC20(address(pool)).approve(address(stakedStargateAM), stakedAmount);\n    uint256 tokenId = stakedStargateAM.mint(address(pool), uint128(stakedAmount) / 4);\n\n    vm.warp(block.timestamp + 10 days);\n\n    uint256 initialRewards = stakedStargateAM.rewardOf(tokenId);\n    stakedStargateAM.increaseLiquidity(tokenId, 1);\n\n    vm.expectRevert();\n    stakedStargateAM.burn(tokenId);\n\n    vm.warp(block.timestamp + 10 days);\n    uint256 currentRewards = stakedStargateAM.rewardOf(tokenId);\n    stakedStargateAM.burn(tokenId);\n\n    assert(currentRewards - initialRewards < 1e10);\n\n    vm.stopPrank();\n}\n```
MEDIUM severity: The vulnerability allows an attacker to manipulate the deposit queue and cause a loss of funds for u. The vulnerability allows an attacker to manipulate the deposit queue and cause a loss of funds for users. This is achieved by exploiting the `_mintShares` function in the `Carousel.sol` contract, which calls the `_mint` function from the `ERC1155.sol` contract. The `_mint` function, in turn, calls t...

Vulnerable code:
```\nfunction _mintShares(\n    address to,\n    uint256 id,\n    uint256 amount\n) internal {\n    _mint(to, id, amount, EMPTY);\n    _mintEmissions(to, id, amount);\n}\n```\n```\nfunction _mint(address to, uint256 id, uint256 amount, bytes memory data) internal virtual {\n    require(to!= address(0), "ERC1155: mint to the zero address");\n\n    address operator = _msgSender();\n    uint256[] memory ids = _asSingletonArray(id);\n    uint256[] memory amounts = _asSingletonArray(amount);\n\n    _beforeTokenTransfer(operator, address(0), to, ids, amounts, data);\n\n    _balances[id][to] += amount;\n    emit TransferSingle(operator, address(0), to, id, amount);\n\n    _afterTokenTransfer(operator, address(0), to, ids, amounts, data);\n\n    _doSafeTransferAcceptanceCheck(operator, address(0), to, id, amount, data);\n}\n```
MEDIUM severity: The `withdrawFromDeposit` function in the TribalChief contract contains a critical vulnerability tha. The `withdrawFromDeposit` function in the TribalChief contract contains a critical vulnerability that can be exploited to manipulate the reward debt calculation. Specifically, the `user.rewardDebt` value is incorrectly calculated by subtracting the product of `user.virtualAmount` and `pool.accTribeP...

Vulnerable code:
```\nuint128 virtualAmountDelta = uint128((amount * poolDeposit.multiplier) / SCALE_FACTOR);\n\npoolDeposit.amount -= amount;\nuser.rewardDebt = user.rewardDebt - toSigned128(user.virtualAmount * pool.accTribePerShare) / toSigned128(ACC_TRIBE_PRECISION);\nuser.virtualAmount -= virtualAmountDelta;\npool.virtualTotalSupply -= virtualAmountDelta;\n```
MEDIUM severity: The deadline check mechanism in the CurveSpell and IChiSpell contracts is ineffective, allowing for . The deadline check mechanism in the CurveSpell and IChiSpell contracts is ineffective, allowing for outdated slippage and the unexpected execution of pending transactions. This vulnerability arises from the use of `type(uint256).max` as the deadline in the `swapExactTokensForTokens` function in Curv...

Vulnerable code:
```\n{\n    uint256 rewards = _doCutRewardsFee(CRV);\n    _ensureApprove(CRV, address(swapRouter), rewards);\n    swapRouter.swapExactTokensForTokens(\n        rewards,\n        0,\n        swapPath,\n        address(this),\n        type(uint256).max\n    );\n}\n```\n```\nSWAP_POOL.swap(\n    address(this),\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 MetaStable Pool's leverage vault deployment process may be hindered due to the absence of Balanc. The MetaStable Pool's leverage vault deployment process may be hindered due to the absence of Balancer Oracle functionality. Specifically, the `MetaStable2TokenVaultMixin` contract, which inherits from `TwoTokenPoolMixin`, relies on the `getOracleMiscData` function to retrieve information about the...

Vulnerable code:
```\nFile: MetaStable2TokenVaultMixin.sol\n\nabstract contract MetaStable2TokenVaultMixin is TwoTokenPoolMixin {\n    constructor(NotionalProxy notional_, AuraVaultDeploymentParams memory params)\n        TwoTokenPoolMixin(notional_, params)\n    {\n        (address _, address _, address _, address _, bool oracleEnabled) = \n            IMetaStablePool(address(BALANCER_POOL_TOKEN)).getOracleMiscData();\n        require(oracleEnabled);\n    }\n```
MEDIUM severity: The vulnerability is a `CREATE2` address collision attack that allows an attacker to drain the funds. The vulnerability is a `CREATE2` address collision attack that allows an attacker to drain the funds from a lending pool. This attack exploits the fact that the `CREATE2` salt is user-supplied and can be brute-forced to find a collision with an undeployed account address. The attacker can then deplo...

Vulnerable code:
```\naccount = address(\n    new Proxy({\n        salt: keccak256(abi.encodePacked(salt, tx.origin))\n    })(\n        versionInformation[accountVersion].implementation\n    )\n);\n```
MEDIUM severity: The vulnerability lies in the handling of user rewards in the `withdraw()` function of the smart con. The vulnerability lies in the handling of user rewards in the `withdraw()` function of the smart contract. Specifically, the `rewarder.onReward()` function is called before the user's account is updated to reflect the withdrawn amount. This allows an attacker to exploit the system by depositing a la...

Vulnerable code:
```\nuser.amount = _amt;\nuser.rewardDebt = (_amt * pool.accRewardPerShare) / ACC_TOKEN_PRECISION;\nuser.rewardsOwed = rewardsOwed;\n```\n```\nif (address(rewarder)!= address(0)) {\n    rewarder.onReward(0, msg.sender, msg.sender, pending, user.amount);\n}\n\n_burn(msg.sender, _shares);\n\nuint256 userAmount = balanceOf(msg.sender);\n\nif (userAmount == 0) {\n    user.amount = 0;\n} else {\n    user.amount -= r;\n}\n```
MEDIUM severity: The ShortLongSpell contract's `_deposit` function contains an incorrect balance check, which renders. The ShortLongSpell contract's `_deposit` function contains an incorrect balance check, which renders the contract non-functional. The issue arises from the fact that `swapToken` is always set to `vault.uToken`, and `borrowToken` is always required to be `vault.uToken`, resulting in `swapToken` being...

Vulnerable code:
```\nuint256 strTokenAmt = _doBorrow(param.borrowToken, param.borrowAmount);\n\n    // Swap borrowed token to strategy token\n    IERC20Upgradeable swapToken = ISoftVault(strategy.vault).uToken();\n\n    PSwapLib.megaSwap(augustusSwapper, tokenTransferProxy, swapData);\n\n    strTokenAmt = swapToken.balanceOf(address(this)) - strTokenAmt;\n```
MEDIUM severity: The NodeRegistry's uniqueness check for node registration relies on hashing the provided `_url` and . The NodeRegistry's uniqueness check for node registration relies on hashing the provided `_url` and verifying if someone already registered with that hash. However, this approach is insufficient for URLs, as slight variations in the URL can result in different hashes, yet still represent the same en...

Vulnerable code:
```\nbytes32 urlHash = keccak256(bytes(_url));\n\nrequire(!urlIndex[urlHash].used && signerIndex[_signer].stage == Stages.NotInUse, \n    "a node with the same url or signer is already registered");\n```
MEDIUM severity: The `SWSupplyManager` contract's `setMaxSupplies` function allows the `owner` to limit the supply of. The `SWSupplyManager` contract's `setMaxSupplies` function allows the `owner` to limit the supply of a specific token ID by setting a new maximum supply. However, this function has a critical flaw that can lead to unexpected behavior. Specifically, it does not prevent the `maxSupply` from being set...

Vulnerable code:
```\nfunction setMaxSupplies(uint256[] calldata _ids, uint256[] calldata _newMaxSupplies) external onlyOwner() {\n    require(_ids.length == _newMaxSupplies.length, "SWSupplyManager#setMaxSupply: INVALID_ARRAYS_LENGTH");\n\n    for (uint256 i = 0; i < _ids.length; i++) {\n        if (maxSupply[_ids[i]] > 0) {\n            require(\n                0 < _newMaxSupplies[i] && _newMaxSupplies[i] < maxSupply[_ids[i]],\n                "SWSupplyManager#setMaxSupply: INVALID_NEW_MAX_SUPPLY"\n            );\n        }\n        maxSupply[_ids[i]] = _newMaxSupplies[i];\n    }\n\n    emit MaxSuppliesChanged(_ids, _newMaxSupplies);\n}\n```\n```\nfunction burn(\n    uint256 _id,\n    uint256 _amount)\n  external\n{\n    _burn(msg.sender, _id, _amount);\n}\n```
MEDIUM severity: The Yearn protocol's approval mechanism for token transfers involves a redundant `approve` call. Spe. The Yearn protocol's approval mechanism for token transfers involves a redundant `approve` call. Specifically, the code checks if the allowance for a token transfer is less than the balance of the token held by the contract, and if so, it issues a zero-value approval followed by a maximum-value appr...

Vulnerable code:
```\nif (token.allowance(address(this), address(v)) < token.balanceOf(address(this))) {\n    token.safeApprove(address(v), 0);\n    token.safeApprove(address(v), type(uint256).max);\n}\n```
MEDIUM severity: The vulnerability lies in the implementation of the `acceptProposedOwner` function in the `ProposedO. The vulnerability lies in the implementation of the `acceptProposedOwner` function in the `ProposedOwnable` contract. The function is designed to transfer ownership of the contract to a new account (`newOwner`) after a two-step ownership transfer process. However, the current implementation does not...

Vulnerable code:
```\n/**\n * @notice Transfers ownership of the contract to a new account (`newOwner`).\n * Can only be called by the current owner.\n */\nfunction acceptProposedOwner() public virtual onlyOwner {\n    require((block.timestamp - _proposedTimestamp) > _delay, "#APO:030");\n    _setOwner(_proposed);\n}\n```\n```\nfunction renounced() public view override returns (bool) {\n    return owner() == address(0);\n}\n```\n```\nmodifier onlyOwner() {\n    require(owner() == msg.sender, "#OO:029");\n    _;\n}\n```
MEDIUM severity: The vulnerability allows an attacker to manipulate the creation of a Signer Gate (HSG) by creating a. The vulnerability allows an attacker to manipulate the creation of a Signer Gate (HSG) by creating a duplicate contract using the same parameters as the intended HSG. This is achieved by frontrunning the creation transaction with a malicious request, which results in the creation of a contract with...

Vulnerable code:
```\nbytes memory initializeParams = abi.encode(\n    _ownerHatId, \n    _signersHatId, \n    _safe, \n    hatsAddress, \n    _minThreshold, \n    _targetThreshold, \n    _maxSigners, \n    version\n);\n\nhsg = moduleProxyFactory.deployModule(\n    hatsSignerGateSingleton, \n    abi.encodeWithSignature("setUp(bytes)", \n    initializeParams), \n    _saltNonce\n);\n```\n```\nproxy = createProxy(masterCopy, keccak256(abi.encodePacked(keccak256(initializer), saltNonce)))\n```\n```\nfunction createProxy(address target, bytes32 salt) internal returns (address result) {\n    if (address(target) == address(0)) revert ZeroAddress(target);\n    if (address(target).code.length == 0) revert TargetHasNoCode(target);\n    bytes memory deployment = abi.encodePacked(\n        hex"602d8060093d393df3363d3d373d3d363d73", target, hex"5af43d82803e903d91602b57fd5bf3"\n    );\n    assembly {\n        result := create2(0, add(deployment, 0x20), mload(deployment), salt)\n    }\n    if (result == address(0)) revert TakenAddress(result);\n}\n```
MEDIUM severity: The vulnerability lies in the way interest is calculated and applied to the lien amount in the LienT. The vulnerability lies in the way interest is calculated and applied to the lien amount in the LienToken contract. When a borrower partially repays a lien, the `_payment` function updates the lien's amount to include the accrued interest, but fails to update the lien's last timestamp. This leads to...

Vulnerable code:
```\nLien storage lien = lienData[lienId];\nlien.amount = _getOwed(lien)\n```\n```\nif (isPublicVault) {\n    IPublicVault(lienOwner).beforePayment(lienId, paymentAmount);\n}\n\nif (lien.amount > paymentAmount) {\n    lien.amount -= paymentAmount;\n    lien.last = block.timestamp.safeCastTo32();\n    if (isPublicVault) {\n        IPublicVault(lienOwner).afterPayment(lienId);\n    }\n}\n```\n```\nfunction beforePayment(uint256 lienId, uint256 amount) public onlyLienToken {\n    _handleStrategistInterestReward(lienId, amount);\n    uint256 lienSlope = LIEN_TOKEN().calculateSlope(lienId);\n    if (lienSlope > slope) {\n        slope = 0;\n    } else {\n        slope -= lienSlope;\n    }\n    last = block.timestamp;\n}\n```\n```\nfunction calculateSlope(uint256 lienId) public view returns (uint256) {\n    Lien memory lien = lienData[lienId];\n    uint256 end = lien.start + lien.duration;\n    uint256 owedAtEnd = _getOwed(lien, end);\n    return (owedAtEnd - lien.amount).mulDivDown(1, end - lien.last);\n}\n```\n```\nfunction _getOwed(Lien memory lien, uint256 timestamp)\n    internal\n    view\n    returns (uint256)\n{\n    return lien.amount + _getInterest(lien, timestamp);\n}\n```\n```\nfunction _getInterest(Lien memory lien, uint256 timestamp)\n    internal\n    view\n    returns (uint256)\n{\n    if (!lien.active) {\n        return uint256(0);\n    }\n    uint256 delta_t;\n    if (block.timestamp >= lien.start + lien.duration) {\n        delta_t = uint256(lien.start + lien.duration - lien.last);\n    } else {\n        delta_t = uint256(timestamp.safeCastTo32() - lien.last);\n    }\n    return delta_t.mulDivDown(lien.rate, 1).mulDivDown(lien.amount, INTEREST_DENOMINATOR);\n}\n```
MEDIUM severity: The `_cancelAllBids` function in the English Periodic Auction smart contract allows the highest bidd. The `_cancelAllBids` function in the English Periodic Auction smart contract allows the highest bidder to withdraw their collateral without ensuring that they are not the current highest bidder. This is in contrast to the `_cancelBid` function, which includes a check to prevent the highest bidder fr...

Vulnerable code:
```\nrequire(\n    bidder!== l.highestBids[tokenId][round].bidder,\n    'EnglishPeriodicAuction: Cannot cancel bid if highest bidder'\n);\n```\n```\n/**\n * @notice Cancel bids for all rounds\n */\nfunction _cancelAllBids(uint256 tokenId, address bidder) internal {\n    EnglishPeriodicAuctionStorage.Layout storage l = EnglishPeriodicAuctionStorage.layout();\n\n    uint256 currentAuctionRound = l.currentAuctionRound[tokenId];\n\n    for (uint256 i = 0; i <= currentAuctionRound; i++) {\n        Bid storage bid = l.bids[tokenId][i][bidder];\n\n        if (bid.collateralAmount > 0) {\n            // Make collateral available to withdraw\n            l.availableCollateral[bidder] += bid.collateralAmount;\n\n            // Reset collateral and bid\n            bid.collateralAmount = 0;\n            bid.bidAmount = 0;\n        }\n    }\n}\n```
MEDIUM severity: The `SwapHandler.swapForTau` function in the system lacks input validation for the `_rewardProportio. The `SwapHandler.swapForTau` function in the system lacks input validation for the `_rewardProportion` parameter, allowing a malicious `keeper` to manipulate the distribution of TAU tokens. This vulnerability enables the `keeper` to erase the debt of users by choosing an arbitrary value for `_reward...

Vulnerable code:
```\n_withholdTau((tauReturned * _rewardProportion) / Constants.PERCENT_PRECISION)\n```
MEDIUM severity: The `beforeTokenTransfer` function in TokenFaucet is vulnerable to potential issues with internal ac. The `beforeTokenTransfer` function in TokenFaucet is vulnerable to potential issues with internal accounting and token drip calculations when the `to` and `from` addresses are the same. This is because the current implementation does not properly handle the scenario where `to` equals `from`, which c...

Vulnerable code:
```\nif (token == address(measure) && from!= address(0)):\n    drip()\n```
MEDIUM severity: The `swapExactTokensForETH` function is vulnerable to an incorrect return value check. Specifically,. The `swapExactTokensForETH` function is vulnerable to an incorrect return value check. Specifically, the code attempts to verify that the amount of tokens received from a swap is greater than the minimum amount expected from this swap (`sp.amountOut`) by comparing the balance of the `tokenOut` contr...

Vulnerable code:
```\nuint amountOut = IWETH10(WETH).balanceOf(address(this));\n\nrequire(\n    IWETH10(sp.tokenOut).balanceOf(address(this)).sub(balanceBefore) >= sp.amountOut,\n    'DAOfiV1Router: INSUFFICIENT_OUTPUT_AMOUNT'\n);\n```
MEDIUM severity: The removal of multisig members using the TYPE_DEL_OWNER operation in the Mozaic Multisig (senate) c. The removal of multisig members using the TYPE_DEL_OWNER operation in the Mozaic Multisig (senate) code can lead to data structure corruption. This vulnerability arises from the implementation of the `contains` function, which returns the index of the owner in the `councilMembers` array, but actuall...

Vulnerable code:
```\nif (proposals[_proposalId].actionType == TYPE_DEL_OWNER) {\n    (address _owner) = abi.decode(proposals[_proposalId].payload, (address));\n    require(contains(_owner)!= 0, "Invalid owner address");\n    uint index = contains(_owner);\n    for (uint256 i = index; i < councilMembers.length - 1; i++) {\n        councilMembers[i] = councilMembers[i + 1];\n    }\n    councilMembers.pop();\n    proposals[_proposalId].executed = true;\n    isCouncil[_owner] = false;\n}\n```\n```\nfunction contains(address _owner) public view returns (uint) {\n    for (uint i = 1; i <= councilMembers.length; i++) {\n        if (councilMembers[i - 1] == _owner) {\n            return i;\n        }\n    }\n    return 0;\n}\n```
MEDIUM severity: The `__add()`, `__mul()`, and `__div()` functions in the LibFixedMath library perform arithmetic ope. The `__add()`, `__mul()`, and `__div()` functions in the LibFixedMath library perform arithmetic operations on 256-bit signed integers, but they fail to detect certain types of overflows. Specifically, the functions do not account for all possible overflow scenarios, leading to potential errors and...

Vulnerable code:
```\nfunction _add(int256 a, int256 b) private pure returns (int256 c) {\n    c = a + b;\n    if (c > 0 && a < 0 && b < 0) {\n        LibRichErrors.rrevert(LibFixedMathRichErrors.BinOpError(\n            LibFixedMathRichErrors.BinOpErrorCodes.SUBTRACTION_OVERFLOW,\n            a,\n            b\n        ));\n    }\n    if (c < 0 && a > 0 && b > 0) {\n        LibRichErrors.rrevert(LibFixedMathRichErrors.BinOpError(\n            LibFixedMathRichErrors.BinOpErrorCodes.ADDITION_OVERFLOW,\n            a,\n            b\n        ));\n    }\n}\n```\n```\nfunction _mul(int256 a, int256 b) private pure returns (int256 c) {\n    if (a == 0) {\n        return 0;\n    }\n    c = a * b;\n    if (c / a!= b) {\n        LibRichErrors.revert(LibFixedMathRichErrors.BinOpError(\n            LibFixedMathRichErrors.BinOpErrorCodes.MULTIPLICATION_OVERFLOW,\n            a,\n            b\n        ));\n    }\n}\n```\n```\nfunction _div(int256 a, int256 b) private pure returns (int256 c) {\n    if (b == 0) {\n        LibRichErrors.revert(LibFixedMathRichErrors.BinOpError(\n            LibFixedMathRichErrors.BinOpErrorCodes.DIVISION_BY_ZERO,\n            a,\n            b\n        ));\n    }\n    c = a / b;\n}\n```
MEDIUM severity: The vulnerability lies in the way DAOfiV1Factory creates unique pair contracts. The factory uses a c. The vulnerability lies in the way DAOfiV1Factory creates unique pair contracts. The factory uses a combination of five parameters - `baseToken`, `quoteToken`, `slopeNumerator`, `n`, and `fee` - to determine the salt used in the `create2` opcode. However, the limited number of accepted values for `n`...

Vulnerable code:
```\nrequire(getPair(baseToken, quoteToken, slopeNumerator, n, fee) == address(0), 'DAOfiV1: PAIR_EXISTS');\n\nbytes memory bytecode = type(DAOfiV1Pair).creationCode;\nbytes32 salt = keccak256(abi.encodePacked(baseToken, quoteToken, slopeNumerator, n, fee));\n\nassembly {\n    pair := create2(0, add(bytecode, 32), mload(bytecode), salt)\n}\n\nIDAOv1Pair(pair).initialize(router, baseToken, quoteToken, pairOwner, slopeNumerator, n, fee);\npairs[salt] = pair;\n```