Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The `rebalanceLite` function in the `PerpDepository` contract lacks a crucial protection mechanism a. The `rebalanceLite` function in the `PerpDepository` contract lacks a crucial protection mechanism against unintended slippage, making users vulnerable to potential losses. Unlike the `rebalance` function, which allows callers to specify an `amountOutMinimum` parameter, `rebalanceLite` does not prov...

Vulnerable code:
```\nPerpDepository.sol\nfunction rebalanceLite(\n    uint256 amount,\n    int8 polarity,\n    uint160 sqrtPriceLimitX96,\n    address account\n) external nonReentrant returns (uint256, uint256) {\n    if (polarity == -1) {\n        return _rebalanceNegativePnlLite(amount, sqrtPriceLimitX96, account);\n    } else if (polarity == 1) {\n        revert PositivePnlRebalanceDisabled(msg.sender);\n    } else {\n        revert InvalidRebalance(polarity);\n    }\n}\n\nfunction _rebalanceNegativePnlLite(\n    uint256 amount,\n    uint160 sqrtPriceLimitX96,\n    address account\n) private returns (uint256, uint256) {\n    uint256 normalizedAmount = amount.fromDecimalToDecimal(\n        ERC20(quoteToken).decimals(),\n        18\n    );\n    _checkNegativePnl(normalizedAmount);\n    IERC20(quoteToken).transferFrom(account, address(this), amount);\n    IERC20(quoteToken).approve(address(vault), amount);\n    vault.deposit(quoteToken, amount);\n    bool isShort = false;\n    bool amountIsInput = true;\n    (uint256 baseAmount, uint256 quoteAmount) = _placePerpOrder(\n        normalizedAmount,\n        isShort,\n        amountIsInput,\n        sqrtPriceLimitX96\n    );\n    vault.withdraw(assetToken, baseAmount);\n    IERC20(assetToken).transfer(account, baseAmount);\n    emit Rebalanced(baseAmount, quoteAmount, 0);\n    return (baseAmount, quoteAmount);\n}\n```\n```\nstruct InternalOpenPositionParams {\n    address trader;\n    address baseToken;\n    bool isBaseToQuote;\n    bool isExactInput;\n    bool isClose;\n    uint256 amount;\n    uint160 sqrtPriceLimitX96;\n}\n```
MEDIUM severity: The `VUSD#processWithdrawals` function in the VUSD smart contract is vulnerable to a critical issue . The `VUSD#processWithdrawals` function in the VUSD smart contract is vulnerable to a critical issue that can result in permanent loss of funds. When a withdrawal attempt fails, the function does not provide a mechanism to retry the withdrawal, instead, it silently discards the failed withdrawal and...

Vulnerable code:
```\nbool success, bytes memory data = withdrawal.usr.call{value: withdrawal.amount}("");\nif (success) {\n    reserve -= withdrawal.amount;\n} else {\n    emit WithdrawalFailed(withdrawal.usr, withdrawal.amount, data);\n}\ni += 1;\n```
MEDIUM severity: The assertion in the provided code snippet is inconsistent in its representation of literals with ma. The assertion in the provided code snippet is inconsistent in its representation of literals with many digits. Specifically, the second assertion statement checks if the input value `x` is less than or equal to `1e22 * 1e18`, while the variable name used in the assertion is `x`, which is not a descr...

Vulnerable code:
```\nfunction wln(int256 x) internal pure returns (int256) {\n    require(x > 0, "logE of negative number");\n    require(x <= 10000000000000000000000000000000000000000, "logE only accepts v <= 1e22 * 1e18");\n    int256 r = 0;\n    uint8 extra_digits = longer_digits - fixed_digits;\n```
MEDIUM severity: The vulnerability arises from the Ethereum Virtual Machine's (EVM) behavior when executing `delegate. The vulnerability arises from the Ethereum Virtual Machine's (EVM) behavior when executing `delegatecall` operations. Specifically, it allows successful calls to externally owned accounts, including the zero address, which poses a security risk. This issue is exacerbated by the use of `delegatecall`...

Vulnerable code:
```\n(bool success, bytes memory result) = \n    addressAt(routeId).delegatecall(\n)\n```\n```\ndelegatecall(swapData);\n```\n```\ndelegatecall(swapData);\n```\n```\ndelegatecall(swapData);\n```\n```\ndelegatecall(data);\n```\n```\nfunction addressAt(uint32 routeId) public view returns (address) {\n    if (routeId < 513) {\n        if (routeId < 257) {\n            if (routeId < 129) {\n                if (routeId < 65) {\n                    if (routeId < 33) {\n                        if (routeId < 17) {\n                            if (routeId < 9) {\n                                if (routeId < 5) {\n                                    if (routeId < 3) {\n                                        if (routeId == 1) {\n                                            return 0x822D4B4e63499a576Ab1cc152B86D1CFFf794F4f;\n                                        } else {\n                                            return 0x822D4B4e63499a576Ab1cc152B86D1CFFf794F4f;\n                                        }\n                                    } else {\n                                        return 0x822D4B4e63499a576Ab1cc152B86D1CFFf794F4f;\n                                    }\n                                }\n                            }\n                        }\n                    }\n                }\n            }\n        }\n    }\n}\n```\n```\nif (routes[routeId] == address(0)) {\n    revert ZeroAddressNotAllowed();\n}\nreturn routes[routeId];\n```
MEDIUM severity: The Oracle contract's reliance on the Pyth network for price feeds creates a vulnerability that can . The Oracle contract's reliance on the Pyth network for price feeds creates a vulnerability that can be exploited to generate arbitrage opportunities with no risk. The Pyth network's continuous updates of the latest price every 400ms, combined with the on-chain oracle's storage of submitted price dat...

Vulnerable code:
```\nadjustmentSize * (secondPrice - firstPrice) - (adjustmentSize * tradeFees * 2)\n```
MEDIUM severity: The Forta staking system employs upgradeable proxies as its deployment strategy, necessitating the i. The Forta staking system employs upgradeable proxies as its deployment strategy, necessitating the introduction of `__gap` array variables to prevent storage collisions between contract versions during upgrades. These variables, declared as `uint256[]`, create a storage buffer to ensure that the tot...

Vulnerable code:
```\nuint256[50] private _gap;\n```\n```\nuint256[41] private _gap; // 50 - 1 (frontRunningDelay) - 3 (_stakeThreshold) - 5 StakeSubjectUpgradeable\n```\n```\nuint256[49] private _gap;\n```\n```\nuint256[47] private _gap;\n```\n```\nuint256[44] private _gap;\n```
MEDIUM severity: The `totalFunds` function in the `ConvexTradeExecutor` contract is responsible for calculating the t. The `totalFunds` function in the `ConvexTradeExecutor` contract is responsible for calculating the total funds held by the contract. However, it does not account for the WETH tokens, which are an essential part of the contract's funds. WETH tokens are initially transferred to the contract and are st...

Vulnerable code:
```\nfunction totalFunds() public view override returns (uint256, uint256) {\n    return ConvexPositionHandler.positionInWantToken();\n}\n```\n```\nfunction positionInWantToken()\n    public\n    override\n    returns (uint256, uint256)\n{\n    (\n        uint256 stakedLpBalanceInETH,\n        uint256 lpBalanceInETH,\n        uint256 ethBalance\n    ) = _getTotalBalancesInETH(true);\n\n    return (\n        stakedLpBalanceInETH + lpBalanceInETH + ethBalance,\n        block.number\n    );\n}\n```\n```\nfunction _getTotalBalancesInETH(bool useVirtualPrice)\n    internal\n    view\n    returns (\n        uint256 stakedLpBalance,\n        uint256 lpTokenBalance,\n        uint256 ethBalance\n    )\n{\n    uint256 stakedLpBalanceRaw = baseRewardPool.balanceOf(address(this));\n    uint256 lpTokenBalanceRaw = lpToken.balanceOf(address(this));\n\n    uint256 totalLpBalance = stakedLpBalanceRaw + lpTokenBalanceRaw;\n\n    uint256 totalLpBalanceInETH = useVirtualPrice\n       ? _lpTokenValueInETHFromVirtualPrice(totalLpBalance)\n        : _lpTokenValueInETH(totalLpBalance);\n\n    lpTokenBalance = useVirtualPrice\n       ? _lpTokenValueInETHFromVirtualPrice(lpTokenBalanceRaw)\n        : _lpTokenValueInETH(lpTokenBalanceRaw);\n\n    stakedLpBalance = totalLpBalanceInETH - lpTokenBalance;\n    ethBalance = address(this).balance;\n}\n```
MEDIUM severity: The `AgentPolice.distributeLiquidatedFunds()` function is responsible for redistributing funds to po. The `AgentPolice.distributeLiquidatedFunds()` function is responsible for redistributing funds to pools after an Agent is liquidated. The function is designed to transfer assets from the liquidator to the pool, with the intention of redeeming as many funds as possible. However, a critical issue aris...

Vulnerable code:
```\nfunction distributeLiquidatedFunds(uint256 agentID, uint256 amount) external {\n    if (!liquidated[agentID]) {\n        revert Unauthorized();\n    }\n\n    // transfer the assets into the pool\n    GetRoute.wFIL(router).transferFrom(msg.sender, address(this), amount);\n    _writeOffPools(agentID, amount);\n}\n```\n```\nuint256 totalOwed = interestPaid + principalOwed;\n\nasset.transferFrom(\n    msg.sender,\n    address(this),\n    totalOwed > recoveredFunds? recoveredFunds : totalOwed\n);\n\ntotalBorrowed -= lostAmt;\naccount.principal = lostAmt;\n\naccount.save(router, agentID, id);\n\nemit WriteOff(agentID, recoveredFunds, lostAmt, interestPaid);\n```
MEDIUM severity: The `maybeUpdateYield` function in the `BridgeRouterFacet` contract is responsible for determining w. The `maybeUpdateYield` function in the `BridgeRouterFacet` contract is responsible for determining whether a yield update should occur for a vault after a large bridge deposit. The function checks if the total amount of ZETH deposited (`zethTotal`) exceeds the `BRIDGE_YIELD_UPDATE_THRESHOLD` constan...

Vulnerable code:
```\nFILE: 2023-09-ditto/contracts/libraries/Constants.sol\n\nuint256 internal constant BRIDGE_YIELD_UPDATE_THRESHOLD = 1000 ether;\n\nuint256 internal constant BRIDGE_YIELD_PERCENT_THRESHOLD = 0.01 ether;\n```\n```\nFILE: 2023-09-ditto/contracts/facets/BridgeRouterFacet.sol\n\nfunction maybeUpdateYield(uint256 vault, uint88 amount) private {\n    uint88 zethTotal = s.vault[vault].zethTotal;\n    if (\n        zethTotal > Constants.BRIDGE_YIELD_UPDATE_THRESHOLD &&\n        amount.div(zethTotal) > Constants.BRIDGE_YIELD_PERCENT_THRESHOLD\n    ) {\n        // Update yield for "large" bridge deposits\n        vault.updateYield();\n    }\n}\n```
MEDIUM severity: This vulnerability occurs in the `pullTokens` function, which attempts to retrieve the maximum amoun. This vulnerability occurs in the `pullTokens` function, which attempts to retrieve the maximum amount of tokens from an approver to the allowed spender. The issue arises from the mismatch in the order of parameters used in the `allowance` function call and the subsequent `safeTransferFrom` function...

Vulnerable code:
```\nfunction pullTokens(\n    address _token,\n    address _from,\n    uint256 _amount\n) internal returns (uint256) {\n    if (_amount == type(uint256).max) {\n        uint256 allowance = IERC20(_token).allowance(address(this), _from);\n        uint256 balance = getBalance(_token, _from);\n\n        _amount = (balance > allowance)? allowance : balance;\n    }\n\n    if (_from!= address(0) && _from!= address(this) && _token!= ETH_ADDR && _amount!= 0) {\n        IERC20(_token).safeTransferFrom(_from, address(this), _amount);\n    }\n\n    return _amount;\n}\n```
MEDIUM severity: The `withdraw` function in the Tranche/PT contract does not adhere to the ERC5095 standard, specific. The `withdraw` function in the Tranche/PT contract does not adhere to the ERC5095 standard, specifically the requirement that the user should receive exactly the requested amount of underlying assets. This is because the function employs a division operation that is rounded down, resulting in an ina...

Vulnerable code:
```\nfunction withdraw(\n    uint256 underlyingAmount,\n    address to,\n    address from\n) external override nonReentrant expired returns (uint256) {\n    GlobalScales memory _gscales = gscales;\n    uint256 cscale = _updateGlobalScalesCache(_gscales);\n\n    uint256 sharesRedeem = underlyingAmount.divWadDown(cscale);\n    uint256 principalAmount = _computePrincipalTokenRedeemed(_gscales, sharesRedeem);\n\n    gscales = _gscales;\n    _burnFrom(from, principalAmount);\n    _target.safeTransfer(address(adapter), sharesRedeem);\n    (uint256 underlyingWithdrawn, ) = adapter.prefundedRedeem(to);\n}\n```
MEDIUM severity: The `InstantMintTimeBasedRateLimiter` class contains two methods, `_setInstantMintLimit` and `_setIn. The `InstantMintTimeBasedRateLimiter` class contains two methods, `_setInstantMintLimit` and `_setInstantRedemptionLimit`, which can lead to unexpected behavior when used in conjunction with the `_checkAndUpdateInstantMintLimit` and `_checkAndUpdateInstantRedemptionLimit` methods. Specifically, if t...

Vulnerable code:
```\nrequire(\n  amount <= instantMintLimit - currentInstantMintAmount,\n  "RateLimit: Mint exceeds rate limit"\n);\n```
MEDIUM severity: The vulnerability lies in the ability of shareholders to modify fees during the batch process, which. The vulnerability lies in the ability of shareholders to modify fees during the batch process, which can lead to unpredictable and potentially malicious behavior. Specifically, when a shareholder votes to change fees, the fees associated with buy orders are immediately withdrawn upon submission of t...

Vulnerable code:
```\nif (fee > 0):\n    reserve.transfer(_collateral, beneficiary, fee)\n```
MEDIUM severity: The protocol's implementation of the `_repayBorrow` function is vulnerable to a race condition when . The protocol's implementation of the `_repayBorrow` function is vulnerable to a race condition when interacting with tokens like USDT, which are subject to approval face protection. This protection mechanism prevents a token from being approved for spending without first approving the zero address,...

Vulnerable code:
```\nActionInfo memory deleverInfo = \n    _createAndValidateActionInfo(\n        _setToken,\n        _collateralAsset,\n        _repayAsset,\n        _redeemQuantityUnits,\n        _minRepayQuantityUnits,\n        _tradeAdapterName,\n        false\n    );\n```\n```\n_withdraw(deleverInfo.setToken, deleverInfo.lendingPool, _collateralAsset, deleverInfo.notionalSendQuantity);\n\n    uint256 postTradeReceiveQuantity = _executeTrade(deleverInfo, _collateralAsset, _repayAsset, _tradeData);\n\n    uint256 protocolFee = _accrueProtocolFee(_setToken, _repayAsset, postTradeReceiveQuantity);\n\n    uint256 repayQuantity = postTradeReceiveQuantity.sub(protocolFee);\n\n    _repayBorrow(deleverInfo.setToken, deleverInfo.lendingPool, _repayAsset, repayQuantity);\n```\n```\nfunction _repayBorrow(ISetToken _setToken, ILendingPool _lendingPool, IERC20 _asset, uint256 _notionalQuantity) internal {\n    _setToken.invokeApprove(address(_asset), address(_lendingPool), _notionalQuantity);\n    _setToken.invokeRepay(_lendingPool, address(_asset), _notionalQuantity, BORROW_RATE_MODE);\n}\n```\n```\nuint256 paybackAmount;\n\nif (params.interestRateMode == DataTypes.InterestRateMode.STABLE) {\n    paybackAmount = stableDebt;\n} else {\n    paybackAmount = variableDebt;\n```\n```\nreserveCache.nextScaledVariableDebt = IVariableDebtToken(\n    reserveCache.variableDebtTokenAddress\n).burn(\n    params.onBehalfOf,\n    paybackAmount,\n    reserveCache.nextVariableBorrowIndex\n);\n```\n```\nfunction _repayBorrow(ISetToken _setToken, ILendingPool _lendingPool, IERC20 _asset, uint256 _notionalQuantity) internal {\n    _setToken.invokeApprove(address(_asset), address(_lendingPool), _notionalQuantity);\n    _setToken.invokeRepay(_lendingPool, address(_asset), _notionalQuantity, BORROW_RATE_MODE);\n}\n```
MEDIUM severity: The `Goldilend` contract contains three functions, `multisigInterestClaim()`, `apdaoInterestClaim()`. The `Goldilend` contract contains three functions, `multisigInterestClaim()`, `apdaoInterestClaim()`, and `sunsetProtocol()`, which are designed to transfer `ibgt` tokens to specific entities. However, these functions do not withdraw the `ibgt` tokens from the `ibgtVault` before initiating the trans...

Vulnerable code:
```\nfunction multisigInterestClaim() external {\n    if (msg.sender!= multisig) revert NotMultisig();\n    uint256 interestClaim = multisigClaims;\n    multisigClaims = 0;\n    SafeTransferLib.safeTransfer(ibgt, multisig, interestClaim);\n}\n\nfunction apdaoInterestClaim() external {\n    if (msg.sender!= apdao) revert NotAPDAO();\n    uint256 interestClaim = apdaoClaims;\n    apdaoClaims = 0;\n    SafeTransferLib.safeTransfer(ibgt, apdao, interestClaim);\n}\n\nfunction sunsetProtocol() external {\n    if (msg.sender!= timelock) revert NotTimelock();\n    SafeTransferLib.safeTransfer(ibgt, multisig, poolSize - outstandingDebt);\n}\n```
MEDIUM severity: The vulnerability allows a malicious actor, referred to as the "Challenger", to delete a previously . The vulnerability allows a malicious actor, referred to as the "Challenger", to delete a previously proposed L2 output, which has already exceeded the 7-day finalization period, thereby rendering the withdrawal process unreliable. This occurs due to the lack of a check to prevent the deletion of L2...

Vulnerable code:
```\nl2Outputs.push(\n    Types.OutputProposal({\n        outputRoot: _outputRoot,\n        timestamp: uint128(block.timestamp),\n        l2BlockNumber: uint128(_l2BlockNumber)\n    })\n);\n```\n```\nfunction deleteL2Outputs(uint256 _l2OutputIndex) external {\n    require(\n        msg.sender == CHALLENGER,\n        "L2OutputOracle: only the challenger address can delete outputs"\n    );\n\n    // Make sure we're not *increasing* the length of the array.\n    require(\n        _l2OutputIndex < l2Outputs.length,\n        "L2OutputOracle: cannot delete outputs after the latest output index"\n    );\n\n    uint256 prevNextL2OutputIndex = nextOutputIndex();\n\n    // Use assembly to delete the array elements because Solidity doesn't allow it.\n    assembly {\n        sstore(l2Outputs.slot, _l2OutputIndex)\n    }\n\n    emit OutputsDeleted(prevNextL2OutputIndex, _l2OutputIndex);\n}\n```
MEDIUM severity: The vulnerability lies in the implementation of contracts that inherit from Openzeppelin's UUPS mode. The vulnerability lies in the implementation of contracts that inherit from Openzeppelin's UUPS model, specifically in the absence of protection against uninitialized implementation contracts. This allows an attacker to exploit the `initialize` function, potentially leading to unauthorized access an...

Vulnerable code:
```\ncontract Rewards is\n    IRewards,\n    OwnablePausableUpgradeable,\n    ReentrancyGuardUpgradeable {\n    // Code block\n}\n```\n```\ncontract Pool is IPool, OwnablePausableUpgradeable, ReentrancyGuardUpgradeable {\n    //...\n```\n```\ncontract StakedLyxToken is\n    OwnablePausableUpgradeable,\n    LSP4DigitalAssetMetadataInitAbstract,\n    IStakedLyxToken,\n    ReentrancyGuardUpgradeable {\n```
MEDIUM severity: The RollerUtils library in the given code contains a hardcoded constant for the Divider address, whi. The RollerUtils library in the given code contains a hardcoded constant for the Divider address, which is incorrectly set to `0x09B10E45A912BcD4E80a8A3119f0cfCcad1e1f12`. This hardcoded constant is used in the `DividerLike` function, specifically in the `series` method, to retrieve information about...

Vulnerable code:
```\naddress internal constant DIVIDER = 0x09B10E45A912BcD4E80a8A3119f0cfCcad1e1f12;\n```\n```\n(DividerLike(DIVIDER).series(adapter, prevMaturity), \n    uint48 prevIssuance, \n   , \n   , \n   , \n    uint256 iscale, \n    uint256 mscale)\n```
MEDIUM severity: The `WFTMUnwrapper` contract and various providers incorrectly utilize the `IWETH` interface declara. The `WFTMUnwrapper` contract and various providers incorrectly utilize the `IWETH` interface declaration for handling funds denoted in `WFTM`. This is problematic because `WFTM` and `WETH` have different implementations, with `WFTM` returning `uint256` values to indicate error conditions, whereas `W...

Vulnerable code:
```\ncontract WFTMUnwrapper {\n    address constant wftm = 0x21be370D5312f44cB42ce377BC9b8a0cEF1A4C83;\n\n    receive() external payable {}\n\n    function withdraw(uint256 _amount) external {\n        IWETH(wftm).withdraw(_amount);\n        (bool sent, ) = msg.sender.call{ value: _amount }("");\n        require(sent, "Failed to send FTM");\n    }\n}\n```\n```\nif (isFtm):\n    IWETH(_tokenAddr).deposit({\n        value: _amount\n    })\n```
MEDIUM severity: The vulnerability is related to the use of digital signatures as hash preimages, which can lead to s. The vulnerability is related to the use of digital signatures as hash preimages, which can lead to signature malleability issues. In the provided code, the encoded signature (r, s, v) or the hash of the signature is used to prevent replay attacks or track if signatures have been seen/used. However,...

Vulnerable code:
```\nfunction fulfillDomainBid(\n    uint256 parentId,\n    uint256 bidAmount,\n    uint256 royaltyAmount,\n    string memory bidIPFSHash,\n    string memory name,\n    string memory metadata,\n    bytes memory signature,\n    bool lockOnCreation,\n    address recipient\n) external {\n    bytes32 recoveredBidHash = createBid(parentId, bidAmount, bidIPFSHash, name);\n    address recoveredBidder = recover(recoveredBidHash, signature);\n    require(recipient == recoveredBidder, "ZNS: bid info doesn't match/exist");\n    bytes32 hashOfSig = keccak256(abi.encode(signature));\n    require(approvedBids[hashOfSig] == true, "ZNS: has been fulfilled");\n    infinity.safeTransferFrom(recoveredBidder, controller, bidAmount);\n    uint256 id = registrar.registerDomain(parentId, name, controller, recoveredBidder);\n    registrar.setDomainMetadataUri(id, metadata);\n    registrar.setDomainRoyaltyAmount(id, royaltyAmount);\n    registrar.transferFrom(controller, recoveredBidder, id);\n    if (lockOnCreation) {\n        registrar.lockDomainMetadataForOwner(id);\n    }\n    approvedBids[hashOfSig] = false;\n    emit DomainBidFulfilled(\n        metadata,\n        name,\n        recoveredBidder,\n        id,\n        parentId\n    );\n}\n```\n```\nfunction acceptBid(bytes memory signature, uint256 rand, address bidder, uint256 bid, address nftAddress, uint256 tokenid) external {\n    address recoveredBidder = recover(toEthSignedMessageHash(keccak256(abi.encode(rand, address(this), block.chainid, bid, nftAddress, tokenid))), signature);\n    require(bidder == recoveredBidder, 'zAuction: incorrect bidder');\n    require(!randUsed[rand], 'Random nonce already used');\n    randUsed[rand] = true;\n```
MEDIUM severity: The `GovPool::execute` function in the `GovPool` contract is vulnerable to a denial-of-service (DoS). The `GovPool::execute` function in the `GovPool` contract is vulnerable to a denial-of-service (DoS) attack through the use of return bombs when executing untrusted execution contracts. A return bomb is a large bytes array that can expand the memory, causing any attempt to execute the transaction to...

Vulnerable code:
```\nfunction execute(\n    mapping(uint256 => IGovPool.Proposal) storage proposals,\n    uint256 proposalId\n) external {\n    // rest of code.\n\n    for (uint256 i; i < actionsLength; i++) {\n        (bool status, bytes memory returnedData) = actions[i].executor.call{\n            value: actions[i].value\n        }(actions[i].data);\n\n        require(status, returnedData.getRevertMsg());\n    }\n```