Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The vulnerability is an instant arbitrage opportunity that arises due to the discrepancy in the valu. The vulnerability is an instant arbitrage opportunity that arises due to the discrepancy in the values of rETH and stETH. In the DittoETH system, users can choose to withdraw their zETH as either rETH or stETH, based on which one is worth more at the time of withdrawal. The system does not enforce a...

Vulnerable code:
```\nFile: BridgeRouterFacet.sol\n\nfunction withdraw(address bridge, uint88 zethAmount)\n    external\n    nonReentrant\n    onlyValidBridge(bridge)\n{\n    if (zethAmount == 0) revert Errors.ParameterIsZero();\n    uint88 fee;\n    uint256 withdrawalFee = bridge.withdrawalFee();\n    uint256 vault;\n    if (bridge == rethBridge || bridge == stethBridge) {\n        vault = Vault.CARBON;\n    } else {\n        vault = s.bridge[bridge].vault;\n    }\n    if (withdrawalFee > 0) {\n        fee = zethAmount.mulU88(withdrawalFee);\n        zethAmount -= fee;\n        s.vaultUser[vault][address(this)].ethEscrowed += fee;\n    }\n    uint88 ethAmount = _ethConversion(vault, zethAmount);\n    vault.removeZeth(zethAmount, fee);\n    IBridge(bridge).withdraw(msg.sender, ethAmount);\n    emit Events.Withdraw(bridge, msg.sender, zethAmount, fee);\n}\n\nfunction _ethConversion(uint256 vault, uint88 amount) private view returns (uint88) {\n    uint256 zethTotalNew = vault.getZethTotal();\n    uint88 zethTotal = s.vault[vault].zethTotal;\n    if (zethTotalNew >= zethTotal) {\n        return amount;\n    } else {\n        return amount.mulU88(zethTotalNew).divU88(zethTotal);\n    }\n}\n```
MEDIUM severity: The vulnerability lies in the `_submitBid()` function, which retrieves bid parameters from the `mark. The vulnerability lies in the `_submitBid()` function, which retrieves bid parameters from the `marketRegistry` without ensuring that the market settings are stable during the bid submission process. This allows market owners to potentially manipulate the bid parameters, including the payment cycle,...

Vulnerable code:
```\nfunction _submitBid() {\n    (bid.terms.paymentCycle, bidPaymentCycleType[bidId]) = marketRegistry.getPaymentCycle(_marketplaceId);\n\n    bid.terms.APR = _APR;\n\n    bidDefaultDuration[bidId] = marketRegistry.getPaymentDefaultDuration(_marketplaceId);\n\n    bidExpirationTime[bidId] = marketRegistry.getBidExpirationTime(_marketplaceId);\n\n    bid.paymentType = marketRegistry.getPaymentType(_marketplaceId);\n\n    bid.terms.paymentCycleAmount = V2Calculations.calculatePaymentCycleAmount(\n        bid.paymentType,\n        bidPaymentCycleType[bidId],\n        _principal,\n        _duration,\n        bid.terms.paymentCycle,\n        _APR\n    );\n```
MEDIUM severity: The `_deleteLienPosition` function is a publicly accessible method that lacks proper access control,. The `_deleteLienPosition` function is a publicly accessible method that lacks proper access control, allowing any user to execute it and delete any lien associated with a specified collateral ID and position. This function does not verify the identity or permissions of the caller, making it vulnerab...

Vulnerable code:
```\nfunction _deleteLienPosition(uint256 collateralId, uint256 position) public {\n    uint256[] storage stack = liens[collateralId];\n    require(position < stack.length, "index out of bounds");\n\n    emit RemoveLien(\n        stack[position],\n        lienData[stack[position]].collateralId,\n        lienData[stack[position]].position\n    );\n\n    for (uint256 i = position; i < stack.length - 1; i++) {\n        stack[i] = stack[i + 1];\n    }\n    stack.pop();\n}\n```
MEDIUM severity: The `rebind` function in the `BPool` contract enforces bounds on the `denorm` value, which represent. The `rebind` function in the `BPool` contract enforces bounds on the `denorm` value, which represents the weight of a token. Specifically, it checks that the `denorm` value falls within the range defined by `MIN_WEIGHT` and `MAX_WEIGHT`. \n\n`MIN_WEIGHT` is set to `1 BONE`, which is a reasonable min...

Vulnerable code:
```\nfunction rebind(address token, uint balance, uint denorm)\n    public\n{\n    _logs_\n    _lock_\n\n    require(msg.sender == _controller, "ERR_NOT_CONTROLLER");\n    require(_records[token].bound, "ERR_NOT_BOUND");\n    require(!_finalized, "ERR_IS_FINALIZED");\n\n    require(denorm >= MIN_WEIGHT, "ERR_MIN_WEIGHT");\n    require(denorm <= MAX_WEIGHT, "ERR_MAX_WEIGHT");\n    require(balance >= MIN_BALANCE, "ERR_MIN_BALANCE");\n```
MEDIUM severity: The `Anchor` contract, generated by the `Registry` contract, is not functioning as expected when dep. The `Anchor` contract, generated by the `Registry` contract, is not functioning as expected when deployed using the `CREATE3` operation. Specifically, the `Registry` contract's `msg.sender` is not the intended `Registry` contract, but rather a proxy contract generated by Solady during the deployment...

Vulnerable code:
```\nfunction test_Audit_createProfile() public {\n    // create profile\n    bytes32 newProfileId = registry().createProfile(nonce, name, metadata, profile1_owner(), profile1_members());\n    Registry.Profile memory profile = registry().getProfileById(newProfileId);\n    Anchor _anchor = Anchor(payable(profile.anchor));\n\n    console.log("registry address: %s", address(registry()));\n    console.log("anchor address: %s", profile.anchor);\n    console.log("anchor.registry: %s", address(_anchor.registry()));\n\n    emit log_named_bytes32("profile.id", profile.id);\n    emit log_named_bytes32("anchor.profile.id", _anchor.profileId());\n\n    Anchor _anchor_proxy = Anchor(payable(address(_anchor.registry())));\n    assertEq(address(registry()), address(_anchor.registry()), "wrong anchor registry");\n}\n```\n```\nconstructor(bytes32 _profileId) {\n    registry = Registry(msg.sender);\n    profileId = _profileId;\n}\n```
MEDIUM severity: The `TokenBridge` contract's `initialize` function lacks a crucial check for validating the initiali. The `TokenBridge` contract's `initialize` function lacks a crucial check for validating the initializing parameters, specifically `_securityCouncil`, `_messageService`, `_tokenBeacon`, and `_reservedTokens`. This oversight allows for the possibility of setting these addresses to invalid values, such...

Vulnerable code:
```\nfunction initialize(\n    address _securityCouncil,\n    address _messageService,\n    address _tokenBeacon,\n    address[] calldata _reservedTokens\n) external initializer {\n    _Pausable_init();\n    _Ownable_init();\n    setMessageService(_messageService);\n    tokenBeacon = _tokenBeacon;\n    for (uint256 i = 0; i < _reservedTokens.length; i++) {\n        setReserved(_reservedTokens[i]);\n    }\n    _transferOwnership(_securityCouncil);\n}\n```
MEDIUM severity: The `Gas Optimization on Transfers` vulnerability in TokenFaucet's `_captureNewTokensForUser` functi. The `Gas Optimization on Transfers` vulnerability in TokenFaucet's `_captureNewTokensForUser` function occurs when two consecutive transfers for the same user occur within the same block. This scenario results in redundant storage writes, as the `UserState` is updated twice, with no changes to the n...

Vulnerable code:
```\nuint256 deltaExchangeRateMantissa = uint256(exchangeRateMantissa).sub(userState.lastExchangeRateMantissa);\n\nuint128 newTokens = FixedPoint.multiplyUintByMantissa(userMeasureBalance, deltaExchangeRateMantissa).toUint128();\n\nuserStates[user] = UserState({\n    lastExchangeRateMantissa: exchangeRateMantissa,\n    balance: uint256(userState.balance).add(newTokens).toUint128()\n});\n```
MEDIUM severity: The `LienToken._payment` function, which is used by `LienToken.makePayment` and `AuctionHouse` when . The `LienToken._payment` function, which is used by `LienToken.makePayment` and `AuctionHouse` when a lien is liquidated, increases the user's debt by setting `lien.amount` to the result of `_getOwed(lien)`. This calculation includes accrued interests, effectively adding the interest to the original...

Vulnerable code:
```\nfunction _payment(\n    uint256 collateralId,\n    uint8 position,\n    uint256 paymentAmount,\n    address payer\n) internal returns (uint256) {\n    if (paymentAmount == uint256(0)) {\n        return uint256(0);\n    }\n\n    uint256 lienId = liens[collateralId][position];\n    Lien storage lien = lienData[lienId];\n    uint256 end = (lien.start + lien.duration);\n    require(\n        block.timestamp < end || address(msg.sender) == address(AUCTION_HOUSE),\n        "cannot pay off an expired lien"\n    );\n\n    address lienOwner = ownerOf(lienId);\n    bool isPublicVault = IPublicVault(lienOwner).supportsInterface(\n        type(IPublicVault).interfaceId\n    );\n\n    lien.amount = _getOwed(lien);\n\n    address payee = getPayee(lienId);\n    if (isPublicVault) {\n        IPublicVault(lienOwner).beforePayment(lienId, paymentAmount);\n    }\n    if (lien.amount > paymentAmount) {\n        lien.amount -= paymentAmount;\n        lien.last = block.timestamp.safeCastTo32();\n        if (isPublicVault) {\n            IPublicVault(lienOwner).afterPayment(lienId);\n        }\n    } else {\n        if (isPublicVault &&!AUCTION_HOUSE.auctionExists(collateralId)) {\n            IPublicVault(lienOwner).decreaseEpochLienCount(\n                IPublicVault(lienOwner).getLienEpoch(end)\n            );\n        }\n        // delete liens\n        _deleteLienPosition(collateralId, position);\n        delete lienData[lienId]; // full delete\n\n        _burn(lienId);\n    }\n\n    TRANSFER_PROXY.tokenTransferFrom(WETH, payer, payee, paymentAmount);\n\n    emit Payment(lienId, paymentAmount);\n    return paymentAmount;\n```
MEDIUM severity: The `afterWithdrawChecks` mechanism is a crucial safeguard to ensure that essential health parameter. The `afterWithdrawChecks` mechanism is a crucial safeguard to ensure that essential health parameters are within acceptable ranges. However, its application is conditional upon the user's withdrawal preference, specifically, whether they choose to withdraw in tokenA or tokenB. This limitation can le...

Vulnerable code:
```\n69\nif (\n    self.withdrawCache.withdrawParams.token == address(self.tokenA) ||\n    self.withdrawCache.withdrawParams.token == address(self.tokenB)\n) {\n    70    // Else if user wants to withdraw in LP token, the tokensToUser is already previously\n    71    // set in GMXWithdraw.withdraw()\n    72    if (\n    73      self.withdrawCache.withdrawParams.token == address(self.tokenA) ||\n    74      self.withdrawCache.withdrawParams.token == address(self.tokenB)\n    75    ) {\n\n    104      GMXChecks.afterWithdrawChecks(self);\n    105    }\n    106  }\n```
MEDIUM severity: The vulnerability lies in the `resolveQueuedTrades` function, which is responsible for processing qu. The vulnerability lies in the `resolveQueuedTrades` function, which is responsible for processing queued trades. When private keeper mode is disabled, which is the default state, the function does not validate that the asset being passed in matches the asset of the queued trade. This allows an attac...

Vulnerable code:
```\nfor (uint32 index = 0; index < params.length; index++) {\n    OpenTradeParams memory currentParams = params[index];\n    QueuedTrade memory queuedTrade = queuedTrades[currentParams.queueId];\n    bool isSignerVerified = _validateSigner(\n        currentParams.timestamp,\n        currentParams.asset,\n        currentParams.price,\n        currentParams.signature\n    );\n    if (!isSignerVerified) {\n        emit FailResolve(currentParams.queueId, "Router: Signature didn't match");\n        continue;\n    }\n    if (\n       !queuedTrade.isQueued ||\n        currentParams.timestamp!= queuedTrade.queuedTime\n    ) {\n        // Trade has already been opened or cancelled or the timestamp is wrong.\n        // So ignore this trade.\n        continue;\n    }\n\n    if (block.timestamp - queuedTrade.queuedTime <= MAX_WAIT_TIME) {\n        _openQueuedTrade(currentParams.queueId, currentParams.price);\n    } else {\n        _cancelQueuedTrade(currentParams.queueId);\n        emit CancelTrade(queuedTrade.user, currentParams.queueId, "Wait time too high");\n    }\n\n    userNextQueueIndexToProcess[queuedTrade.user] =\n        queuedTrade.userQueueIndex + 1;\n}\n```\n```\nfunction _openQueuedTrade(uint256 queueId, uint256 price) internal {\n    QueuedTrade storage queuedTrade = queuedTrades[queueId];\n    IBufferBinaryOptions optionsContract = IBufferBinaryOptions(\n        queuedTrade.targetContract\n    );\n\n    bool isSlippageWithinRange = optionsContract.isStrikeValid(\n        queuedTrade.slippage,\n        price,\n        queuedTrade.expectedStrike\n    );\n\n    if (!isSlippageWithinRange) {\n        _cancelQueuedTrade(queueId);\n        emit CancelTrade(\n            queuedTrade.user,\n            queueId,\n            "Slippage limit exceeds"\n        );\n        return;\n    }\n\n    optionParams.totalFee = revisedFee;\n    optionParams.strike = price;\n    optionParams.amount = amount;\n\n    uint256 optionId = optionsContract.createFromRouter(\n        optionParams,\n        isReferralValid\n    );\n}\n```
MEDIUM severity: The `_sqrtPriceX96ToUint` function is susceptible to an overflow vulnerability when processing large. The `_sqrtPriceX96ToUint` function is susceptible to an overflow vulnerability when processing large values of `sqrtPriceX96`. This function is designed to work with values that fit within a 32-bit integer, which corresponds to a price ratio of approximately 18446744073709551616. However, in scenari...

Vulnerable code:
```\nfunction _sqrtPriceX96ToUint(uint160 sqrtPriceX96) private pure returns (uint256) {\n    uint256 numerator1 = uint256(sqrtPriceX96) * \n        uint256(sqrtPriceX96);\n    return FullMath.mulDiv(numerator1, 1, 1 << 192);\n}\n```
MEDIUM severity: The `Gateway` contract's implementation of delegated transactions allows for the creation of meta tr. The `Gateway` contract's implementation of delegated transactions allows for the creation of meta transactions triggered by the system's backend. This functionality is designed to enable users to initiate transactions on behalf of another account, with the requirement that one of the account's owner...

Vulnerable code:
```\naddress sender = _hashPrimaryTypedData(\n    _hashTypedData(\n        nonce,\n        to,\n        data\n    )\n).recoverAddress(senderSignature);\n```
MEDIUM severity: The vulnerability allows auction creators to cancel an auction after it has concluded, potentially l. The vulnerability allows auction creators to cancel an auction after it has concluded, potentially locking bidders' funds in the auction house. This is achieved by bypassing the checks that prevent auction cancellation once the auction has started. The checks are bypassed by aligning the block times...

Vulnerable code:
```\nfunction cancelAuction(uint96 lotId_) external override onlyInternal {\n    _revertIfLotConcluded(lotId_);\n}\n```\n```\nfunction _cancelAuction(uint96 lotId_) internal override {\n    _revertIfLotActive(lotId_);\n    \n    auctionData[lotId_].status = Auction.Status.Claimed;\n}\n```\n```\nfunction _revertIfLotConcluded(uint96 lotId_) internal view virtual {\n    if (lotData[lotId_].conclusion < uint48(block.timestamp)) {\n        revert Auction_MarketNotActive(lotId_);\n    }\n\n    if (lotData[lotId_].capacity == 0) {\n        revert Auction_MarketNotActive(lotId_);\n    }\n}\n\nfunction _revertIfLotActive(uint96 lotId_) internal view override {\n    if (\n        auctionData[lotId_].status == Auction.Status.Created\n        && lotData[lotId_].start <= block.timestamp\n        && lotData[lotId_].conclusion > block.timestamp\n    ) {\n        revert Auction_WrongState(lotId_);\n    }\n}\n```\n```\nfunction refundBid(\n    uint96 lotId_,\n    uint64 bidId_,\n    address caller_\n) external override onlyInternal returns (uint96 refund) {\n    _revertIfLotConcluded(lotId_);\n}\n\nfunction _revertIfLotConcluded(uint96 lotId_) internal view virtual {\n    if (lotData[lotId_].capacity == 0) {\n        revert Auction_MarketNotActive(lotId_);\n    }\n}\n```\n```\nfunction claimBids(\n    uint96 lotId_,\n    uint64[] calldata bidIds_\n) {\n    _revertIfLotNotSettled(lotId_);\n}\n```\n```\nfunction decryptAndSortBids(uint96 lotId_, uint64 num_) external {\n    if (\n        auctionData[lotId_].status!= Auction.Status.Created\n        || auctionData[lotId_].privateKey == 0\n    ) {\n        revert Auction_WrongState(lotId_);\n    }\n\n    _decryptAndSortBids(lotId_, num_);\n}\n```\n```\nfunction test_cancel() external whenLotIsCreated {\n    Auction.Lot memory lot = _mockAuctionModule.getLot(_lotId);\n\n    console2.log("lot.conclusion before ==> ", lot.conclusion);\n    console2.log("block.timestamp before ==> ", block.timestamp);\n    console2.log("isLive                  ==> ", _mockAuctionModule.isLive(_lotId));\n\n    vm.warp(lot.conclusion - block.timestamp + 1);\n    console2.log("lot.conclusion after    ==> ", lot.conclusion);\n    console2.log("block.timestamp after   ==> ", block.timestamp);\n    console2.log("isLive                  ==> ", _mockAuctionModule.isLive(_lotId));\n\n    vm.prank(address(_auctionHouse));\n    _mockAuctionModule.cancelAuction(_lotId);\n}\n```\n```\nlot.conclusion before  ==> 86401\nblock.timestamp before  ==> 1\nisLive                  ==> true\n\nlot.conclusion after   ==> 86401\nblock.timestamp after  ==> 86401\nisLive                  ==> false\n```
MEDIUM severity: The vulnerability lies in the inconsistent use of the `SafeERC20` library when interacting with exte. The vulnerability lies in the inconsistent use of the `SafeERC20` library when interacting with external tokens in the system. Specifically, some contracts, such as `TokenGrant`, utilize the `safeTransferFrom` method to ensure a safe and reliable transfer of tokens, while others, like `TokenStaking`...

Vulnerable code:
```\ntoken.safeTransferFrom(\n    _from,\n    address(this),\n    _amount\n);\n```\n```\ntoken.transferFrom(\n    _from,\n    address(this),\n    _value\n)\n```\n```\ntoken.safeTransfer(owner, amount);\n```\n```\ntoken.transfer(tattletale, tattletaleReward);\n```\n```\ntoken.transferFrom(\n    msg.sender,\n    tokenStaking.magpieOf(members[i]),\n    dividend\n)\n```
MEDIUM severity: The vulnerability arises from the potential for stale Oracle prices to impact the rates in the syste. The vulnerability arises from the potential for stale Oracle prices to impact the rates in the system. This can occur when network congestion or other factors cause the price returned by the ChainLink Oracle to be outdated, which is more likely to happen for lesser-known tokens with fewer ChainLink...

Vulnerable code:
```\nfunction priceFromAddress(address tokenAddress) public view returns(uint256) {\n    if (Utils._isETH(address(globalConfig), tokenAddress)) {\n        return 1e18;\n    }\n    return uint256(globalConfig.chainLink().getLatestAnswer(tokenAddress));\n}\n```
MEDIUM severity: The Full inventory asset purchases can be DOS'd via frontrunning vulnerability occurs when a malicio. The Full inventory asset purchases can be DOS'd via frontrunning vulnerability occurs when a malicious user exploits a specific scenario in the AuctionRebalanceModuleV1.sol contract. Specifically, when a user attempts to swap the entire component value, a small bid can be placed by an attacker, caus...

Vulnerable code:
```\nrequire(_componentQuantity <= bidInfo.auctionQuantity, "Bid size exceeds auction quantity")\n```
MEDIUM severity: This vulnerability occurs when attempting to withdraw extra rewards, specifically in a scenario wher. This vulnerability occurs when attempting to withdraw extra rewards, specifically in a scenario where the main rewards are in a token other than the minimum stake amount required by the `GPToke` contract. In this case, the `MainRewarder` contract will always attempt to stake the main rewards, which...

Vulnerable code:
```\nFile: MainRewarder.sol\n\nfunction _processRewards(address account, bool claimExtras) internal {\n    _getReward(account);\n\n    // also get rewards from linked rewards\n    if (claimExtras) {\n        for (uint256 i = 0; i < extraRewards.length; ++i) {\n            IExtraRewarder(extraRewards[i]).getReward(account);\n        }\n    }\n}\n```\n```\nFile: AbstractRewarder.sol\n\nfunction _getReward(address account) internal {\n    Errors.verifyNotZero(account, "account");\n\n    uint256 reward = earned(account);\n    (IGPToke gpToke, address tokeAddress) = (systemRegistry.gpToke(), address(systemRegistry.toke()));\n\n    if (reward == 0) return;\n\n    rewards[account] = 0;\n    emit RewardPaid(account, reward);\n\n    if (rewardToken!= tokeAddress || tokeLockDuration == 0) {\n        IERC20(rewardToken).safeTransfer(account, reward);\n    } else {\n        IERC20(address(tokeAddress)).approve(address(gpToke), reward);\n\n        gpToke.stake(reward, tokeLockDuration, account);\n    }\n}\n```\n```\nFile: GPToke.sol\n\nuint256 public constant MIN_STAKE_AMOUNT = 10_000;\n\nfunction _stake(uint256 amount, uint256 duration, address to) internal whenNotPaused {\n    if (to == address(0)) revert ZeroAddress();\n    if (amount < MIN_STAKE_AMOUNT) revert StakingAmountInsufficient();\n    if (amount > MAX_STAKE_AMOUNT) revert StakingAmountExceeded();\n```
MEDIUM severity: The `exerciseOptionsReceiver` method in the `UsdoOptionReceiverModule` lacks a crucial ownership che. The `exerciseOptionsReceiver` method in the `UsdoOptionReceiverModule` lacks a crucial ownership check for the `oTAPTokenID`, allowing anyone to utilize the authorization granted by the `oTAPTokenID` owner. This vulnerability enables malicious actors to front-run the execution of `exerciseOptionsRec...

Vulnerable code:
```\nfunction exerciseOptionsReceiver(address srcChainSender, bytes memory _data) public payable {\n    ITapiocaOptionBroker(_options.target).exerciseOption(\n        _options.oTAPTokenID,\n        address(this), // payment token\n        _options.tapAmount\n    );\n    _approve(address(this), address(pearlmit), 0);\n    uint256 bAfter = balanceOf(address(this));\n\n    if (bBefore > bAfter) {\n        uint256 diff = bBefore - bAfter;\n        if (diff < _options.paymentTokenAmount) {\n            IERC20(address(this)).safeTransfer(_options.from, _options.paymentTokenAmount - diff);\n        }\n    }\n```
MEDIUM severity: The Balancer pool re-initialization vulnerability occurs when the same pool is reused repeatedly ins. The Balancer pool re-initialization vulnerability occurs when the same pool is reused repeatedly instead of creating a new one for each auction. This behavior can lead to unintended consequences, as the old liquidity is withdrawn, and if there is sufficient FEI in the contract, the weights are shift...

Vulnerable code:
```\nuint256 bptTotal = pool.totalSupply();\nuint256 bptBalance = pool.balanceOf(address(this));\n\nif (bptTotal == 0) {\n    _initializePool();\n    return;\n}\n```