Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The vulnerability, "Inadequate slippage control," is a critical issue in the InterestRateCurve.sol a. The vulnerability, "Inadequate slippage control," is a critical issue in the InterestRateCurve.sol and TradingAction.sol files of the DeFi trading platform. The problem arises from the fact that the current slippage control mechanism checks the user's acceptable interest rate limit against the inter...

Vulnerable code:
```\nFile: InterestRateCurve.sol\n\nfunction _getNetCashAmountsUnderlying(\n    InterestRateParameters memory irParams,\n    MarketParameters memory market,\n    CashGroupParameters memory cashGroup,\n    int256 totalCashUnderlying,\n    int256 fCashToAccount,\n    uint256 timeToMaturity\n) private pure returns (\n    int256 postFeeCashToAccount,\n    int256 netUnderlyingToMarket,\n    int256 cashToReserve\n) {\n    uint256 utilization = getfCashUtilization(fCashToAccount, market.totalfCash, totalCashUnderlying);\n\n    if (utilization > uint256(Constants.RATE_PRECISION)) {\n        return (0, 0, 0);\n    }\n\n    uint256 preFeeInterestRate = getInterestRate(irParams, utilization);\n\n    int256 preFeeCashToAccount = fCashToAccount.divInRatePrecision(\n        getfCashExchangeRate(preFeeInterestRate, timeToMaturity)\n    ).neg();\n\n    uint256 postFeeInterestRate = getPostFeeInterestRate(irParams, preFeeInterestRate, fCashToAccount < 0);\n    postFeeCashToAccount = fCashToAccount.divInRatePrecision(\n        getfCashExchangeRate(postFeeInterestRate, timeToMaturity)\n    ).neg();\n```\n```\nFile: InterestRateCurve.sol\n\n(\n    int256 netUnderlyingToAccount,\n    int256 netUnderlyingToMarket,\n    int256 netUnderlyingToReserve\n) = _getNetCashAmountsUnderlying(\n    irParams,\n    market,\n    cashGroup,\n    totalCashUnderlying,\n    fCashToAccount,\n    timeToMaturity\n);\n\n{\n    // Do not allow utilization to go above 100 on trading, calculate the utilization after\n    // the trade has taken effect, meaning that fCash changes and cash changes are applied to\n    // the market totals.\n    market.totalfCash = market.totalfCash.subNoNeg(fCashToAccount);\n    totalCashUnderlying = totalCashUnderlying.add(netUnderlyingToMarket);\n\n    uint256 utilization = getfCashUtilization(0, market.totalfCash, totalCashUnderlying);\n    if (utilization > uint256(Constants.RATE_PRECISION)) return (0, 0);\n\n    uint256 newPreFeeImpliedRate = getInterestRate(irParams, utilization);\n\n    // Saves the preFeeInterestRate and fCash\n    market.lastImpliedRate = newPreFeeImpliedRate;\n}\n```\n```\nFile: TradingAction.sol\n\nfunction _executeLendBorrowTrade(\n    //...SNIP...\n    cashAmount = market.executeTrade(\n        account,\n        cashGroup,\n        fCashAmount,\n        market.maturity.sub(blockTime),\n        marketIndex\n    );\n\n    uint256 rateLimit = uint256(uint32(bytes4(trade << 104)));\n    if (rateLimit!= 0) {\n        if (tradeType == TradeActionType.Borrow) {\n            require(market.lastImpliedRate <= rateLimit, "Trade failed, slippage");\n        } else {\n            require(market.lastImpliedRate >= rateLimit, "Trade failed, slippage");\n        }\n    }\n```
MEDIUM severity: The Lybra Protocol system is missing events in several critical scenarios, which can lead to a lack . The Lybra Protocol system is missing events in several critical scenarios, which can lead to a lack of transparency and visibility in the system's operations. Specifically, the system is missing events for significant configuration changes, such as setting the price oracle, token, and pools, as well...

Vulnerable code:
```\ncontract esLBRBoost is Ownable {\n    esLBRLockSetting[] public esLBRLockSettings;\n    mapping(address => LockStatus) public userLockStatus;\n    IMiningIncentives public miningIncentives;\n\n    // Define a struct for the lock settings\n    struct esLBRLockSetting {\n        uint256 duration;\n        uint256 miningBoost;\n    }\n\n    // Define a struct for the user's lock status\n    struct LockStatus {\n        uint256 lockAmount;\n        uint256 unlockTime;\n        uint256 duration;\n        uint256 miningBoost;\n    }\n\n    // Constructor to initialize the default lock settings\n    constructor(address _miningIncentives) {\n        miningIncentives = _miningIncentives;\n    }\n}\n```\n```\nfunction unlockPrematurely() external {\n    require(block.timestamp + exitCycle - 3 days > time2fullRedemption[msg.sender], "ENW");\n    uint256 burnAmount = getReservedLBRForVesting(msg.sender) - getPreUnlockableAmount(msg.sender);\n    uint256 amount = getPreUnlockableAmount(msg.sender) + getClaimAbleLBR(msg.sender);\n    if (amount > 0) {\n        LBR.mint(msg.sender, amount);\n    }\n    unstakeRatio[msg.sender] = 0;\n    time2fullRedemption[msg.sender] = 0;\n    grabableAmount += burnAmount;\n}\n```\n```\nfunction setToken(address _lbr, address _eslbr) external onlyOwner {\n    LBR = _lbr;\n    esLBR = _eslbr;\n}\n\nfunction setLBROracle(address _lbrOracle) external onlyOwner {\n    lbrPriceFeed = AggregatorV3Interface(_lbrOracle);\n}\n\nfunction setPools(address[] memory _vaults) external onlyOwner {\n    require(_vaults.length <= 10, "EL");\n    for (uint i = 0; i < _vaults.length; i++) {\n        require(configurator.mintVault(_vaults[i]), "NOT_VAULT");\n    }\n    vaults = _vaults;\n}\n```\n```\nfunction setRewardsDuration(uint256 _duration) external onlyOwner {\n    require(finishAt < block.timestamp, "reward duration not finished");\n    duration = _duration;\n}\n\nfunction setBoost(address _boost) external onlyOwner {\n    esLBRBoost = IesLBRBoost(_boost);\n}\n```\n```\nif (useLBR) {\n    IesLBR(miningIncentives.LBR()).burn(msg.sender, lbrAmount);\n    IesLBR(miningIncentives.esLBR()).mint(msg.sender, lbrAmount);\n}\n```
MEDIUM severity: The `Operator._transfer()` function in the `OperatorTokenomics` contract contains a vulnerability in. The `Operator._transfer()` function in the `OperatorTokenomics` contract contains a vulnerability in the way it handles the `onDelegate()` function call. Specifically, `onDelegate()` is called before updating the token balances, which can lead to unintended behavior.\n\nIn the `_transfer()` function...

Vulnerable code:
```\nFile: contracts/OperatorTokenomics/Operator.sol\n\ndef transfer(from, to, amount):\n    # transfer creates a new delegator: check if the delegation policy allows this "delegation"\n    if balanceOf(to) == 0:\n        if address(delegationPolicy)!= address(0):\n            moduleCall(address(delegationPolicy), abi.encodeWithSelector(delegationPolicy.onDelegate.selector, to))\n            # @audit should be called after _transfer()\n    super._transfer(from, to, amount)\n```
MEDIUM severity: When a user's pending quote is liquidated, the trading fees associated with that quote are not retur. When a user's pending quote is liquidated, the trading fees associated with that quote are not returned to the party A, contrary to the expected behavior. This is because the trading fee is not utilized to cover the liquidation, allowing the fee collector to retain the funds. This issue arises when...

Vulnerable code:
```\nfunction liquidatePendingPositionsPartyA(address partyA) internal {\n    QuoteStorage.Layout storage quoteLayout = QuoteStorage.layout();\n    require(\n        MAStorage.layout().liquidationStatus[partyA],\n        "LiquidationFacet: PartyA is solvent"\n    );\n\n    for (uint256 index = 0; index < quoteLayout.partyAPendingQuotes[partyA].length; index++) {\n        Quote storage quote = quoteLayout.quotes[\n            quoteLayout.partyAPendingQuotes[partyA][index]\n        ];\n\n        if (\n            (quote.quoteStatus == QuoteStatus.LOCKED ||\n                quote.quoteStatus == QuoteStatus.CANCEL_PENDING) &&\n            quoteLayout.partyBPendingQuotes[quote.partyB][partyA].length > 0\n        ) {\n            delete quoteLayout.partyBPendingQuotes[quote.partyB][partyA];\n            AccountStorage.layout().partyBPendingLockedBalances[quote.partyB][partyA].makeZero();\n        }\n\n        quote.quoteStatus = QuoteStatus.LIQUIDATED;\n        quote.modifyTimestamp = block.timestamp;\n    }\n\n    AccountStorage.layout().pendingLockedBalances[partyA].makeZero();\n    delete quoteLayout.partyAPendingQuotes[partyA];\n}\n```\n```\nfunction liquidatePartyB(\n    address partyB,\n    address partyA,\n    SingleUpnlSig memory upnlSig\n) internal {\n    uint256[] storage pendingQuotes = quoteLayout.partyAPendingQuotes[partyA];\n\n    for (uint256 index = 0; index < pendingQuotes.length; index++) {\n        Quote storage quote = quoteLayout.quotes[pendingQuotes[index]];\n        if (\n            quote.partyB == partyB &&\n            (quote.quoteStatus == QuoteStatus.LOCKED ||\n                quote.quoteStatus == QuoteStatus.CANCEL_PENDING)\n        ) {\n            accountLayout.pendingLockedBalances[partyA].subQuote(quote);\n\n            pendingQuotes[index] = pendingQuotes[pendingQuotes.length - 1];\n            pendingQuotes.pop();\n            quote.quoteStatus = QuoteStatus.LIQUIDATED;\n            quote.modifyTimestamp = block.timestamp;\n        }\n    }\n```
MEDIUM severity: The `FujiVaultFTM.harvestRewards` function in the FujiVaultFTM contract is vulnerable to a rewards s. The `FujiVaultFTM.harvestRewards` function in the FujiVaultFTM contract is vulnerable to a rewards siphoning attack due to the absence of slippage protection. Specifically, the `SwapperFTM.getSwapTransaction` call used to generate a swap transaction sets the `amountOutMin` parameter to zero, effecti...

Vulnerable code:
```\ntransaction.data = abi.encodeWithSelector(\n    IUniswapV2Router01.swapExactETHForTokens.selector,\n    0,\n    path,\n    msg.sender,\n    type(uint256).max\n);\n```\n```\nsuccess, = swapTransaction.to.call(value=swapTransaction.value)(swapTransaction.data)\nrequire(success, "failed to swap rewards")\n```
MEDIUM severity: The `RFPSimpleStrategy` class allows for the creation of strategies with a configurable `useRegistry. The `RFPSimpleStrategy` class allows for the creation of strategies with a configurable `useRegistryAnchor` parameter. When `useRegistryAnchor` is set to `true`, the strategy is designed to utilize the registry anchor for recipient registration. However, a critical issue arises when the strategy is...

Vulnerable code:
```\nfunction test_registrationIsBlockedWhenThePoolIsCreatedWithUseRegistryIsTrue() public {\n    bool useRegistryAnchorTrue = true;\n    RFPSimpleStrategy custom_strategy = new RFPSimpleStrategy(address(allo()), "RFPSimpleStrategy");\n\n    vm.prank(pool_admin());\n    poolId = allo().createPoolWithCustomStrategy(\n        poolProfile_id(),\n        address(custom_strategy),\n        abi.encode(maxBid, useRegistryAnchorTrue, metadataRequired),\n        NATIVE,\n        0,\n        poolMetadata,\n        pool_managers()\n    );\n\n    Metadata memory metadata = Metadata({protocol: 1, pointer: "metadata"});\n    address anchor = profile1_anchor();\n    bytes memory data = abi.encode(anchor, 1e18, metadata);\n\n    vm.startPrank(address(profile1_member1()));\n    vm.expectRevert(abi.encodeWithSelector(RECIPIENT_ERROR.selector, address(anchor)));\n    allo().registerRecipient(poolId, data);\n}\n```
MEDIUM severity: The vulnerability arises from the implementation of the `batchBalanceAndTradeAction` function in the. The vulnerability arises from the implementation of the `batchBalanceAndTradeAction` function in the Notional V3 contract. When this function is executed, it triggers the `depositUnderlyingExternal` function, which is responsible for handling the deposit of underlying assets, including ETH. In the c...

Vulnerable code:
```\nfunction _lendLegacy(\n    uint256 preTradeCash = getCashBalance();\n\n    BalanceActionWithTrades[] memory action = EncodeDecode.encodeLegacyLendTrade(\n        currencyId,\n        getMarketIndex(),\n        depositAmountExternal,\n        fCashAmount,\n        minImpliedRate\n    );\n\n    NotionalV2.batchBalanceAndTradeAction{value: msgValue}(address(this), action);\n\n    uint256 postTradeCash = getCashBalance();\n\n    if (preTradeCash!= postTradeCash) {\n        if (isETH) {\n            NotionalV2.withdraw(currencyId, _safeUint88(postTradeCash - preTradeCash), false);\n        }\n    }\n```\n```\nFile: TokenHandler.sol\n\nfunction depositUnderlyingExternal(\n    address account,\n    uint16 currencyId,\n    int256 _underlyingExternalDeposit,\n    PrimeRate memory primeRate,\n    bool returnNativeTokenWrapped\n) internal returns (int256 actualTransferExternal, int256 netPrimeSupplyChange) {\n    uint256 underlyingExternalDeposit = _underlyingExternalDeposit.toUint();\n    if (underlyingExternalDeposit == 0) {\n        return (0, 0);\n    }\n\n    Token memory underlying = getUnderlyingToken(currencyId);\n    if (underlying.tokenType == TokenType.Ether) {\n        if (underlyingExternalDeposit < msg.value) {\n            GenericToken.transferNativeTokenOut(\n                account,\n                msg.value - underlyingExternalDeposit,\n                returnNativeTokenWrapped\n            );\n        } else {\n            require(underlyingExternalDeposit == msg.value, "ETH Balance");\n        }\n\n        actualTransferExternal = _underlyingExternalDeposit;\n    }\n```\n```\nfunction _lendLegacy(\n    //...SNIP...\n    // Notional will return any residual ETH as the native token. When we sendTokensToReceiver those\n    // native ETH tokens will be wrapped back to WETH.\n```\n```\nfunction _sendTokensToReceiver(\n    IERC20 token,\n    address receiver,\n    bool isETH,\n    uint256 balanceBefore\n) private returns (uint256 tokensTransferred) {\n    uint256 balanceAfter = isETH? WETH.balanceOf(address(this)) : token.balanceOf(address(this));\n    tokensTransferred = balanceAfter - balanceBefore;\n\n    if (isETH) {\n        IERC20(address(WETH)).transfer(receiver, tokensTransferred);\n    } else if (tokensTransferred > 0) {\n        token.safeTransfer(receiver, tokensTransferred);\n    }\n}\n```
MEDIUM severity: The `Depositor` contract contains a vulnerability that allows anyone to withdraw a user's Velo Depos. The `Depositor` contract contains a vulnerability that allows anyone to withdraw a user's Velo Deposit NFT after approval has been given to the depositor. This is achieved by exploiting the `Depositor#withdrawFromGauge` function, which can be called by anyone and transfers tokens to the `msg.sender`...

Vulnerable code:
```\nfunction withdrawFromGauge(uint256 _NFTId, address[] memory _tokens) public {\n    uint256 amount = depositReceipt.pooledTokens(_NFTId);\n    depositReceipt.burn(_NFTId);\n    gauge.getReward(address(this), _tokens);\n    gauge.withdraw(amount);\n    AMMToken.transfer(msg.sender, amount);\n}\n```\n```\nfunction burn(uint256 _NFTId) external onlyMinter {\n    require(_isApprovedOrOwner(msg.sender, _NFTId), "ERC721: caller is not token owner or approved");\n    delete pooledTokens[_NFTId];\n    delete relatedDepositor[_NFTId];\n    _burn(_NFTId);\n}\n```
MEDIUM severity: The `isSolventAfterClosePosition` and `isSolventAfterRequestToClosePosition` functions in the system. The `isSolventAfterClosePosition` and `isSolventAfterRequestToClosePosition` functions in the system are vulnerable to incorrect calculations of solvency. Specifically, they do not account for the potential extra profit that a user may receive when closing a position. This oversight can lead to inco...

Vulnerable code:
```\npartyAAvailableBalance = freeBalance + upnl + unlockedAmount\n```\n```\nrequire(\n    partyBAvailableBalance >= 0 && partyAAvailableBalance >= 0,\n    "LibSolvency: Available balance is lower than zero"\n);\n```
MEDIUM severity: The `OwnerFacet.sol` contract contains three setter functions `_setInitialMargin`, `_setPrimaryLiqui. The `OwnerFacet.sol` contract contains three setter functions `_setInitialMargin`, `_setPrimaryLiquidationCR`, and `_setSecondaryLiquidationCR` that have incorrect require statements. Specifically, these functions will revert when the input value is 100, which is actually equal to 1.0, not below. Th...

Vulnerable code:
```\nfunction _setInitialMargin(address asset, uint16 value) private {\n    require(value > 100, "below 1.0");\n    s.asset[asset].initialMargin = value;\n    require(LibAsset.initialMargin(asset) < Constants.CRATIO_MAX, "above max CR");\n}\n\nfunction _setPrimaryLiquidationCR(address asset, uint16 value) private {\n    require(value > 100, "below 1.0");\n    require(value <= 500, "above 5.0");\n    require(value < s.asset[asset].initialMargin, "above initial margin");\n    s.asset[asset].primaryLiquidationCR = value;\n}\n\nfunction _setSecondaryLiquidationCR(address asset, uint16 value) private {\n    require(value > 100, "below 1.0");\n    require(value <= 500, "above 5.0");\n    require(value < s.asset[asset].primaryLiquidationCR, "above primary liquidation");\n    s.asset[asset].secondaryLiquidationCR = value;\n}\n```\n```\nfunction _setForcedBidPriceBuffer(address asset, uint8 value) private {\n    require(value >= 100, "below 1.0");\n    require(value <= 200, "above 2.0");\n    s.asset[asset].forcedBidPriceBuffer = value;\n}\n\nfunction _setMinimumCR(address asset, uint8 value) private {\n    require(value >= 100, "below 1.0");\n    require(value <= 200, "above 2.0");\n    s.asset[asset].minimumCR = value;\n    require(LibAsset.minimumCR(asset) < LibAsset.secondaryLiquidationCR(asset), "above secondary liquidation");\n}\n```
MEDIUM severity: The `requestWithdrawal` function in the protocol's smart contract is vulnerable to inaccurate estima. The `requestWithdrawal` function in the protocol's smart contract is vulnerable to inaccurate estimation of available shares for withdrawals. This occurs when the function includes funds stored in the deposit pool into the already deposited EigenLayer shares, which can lead to incorrect calculations...

Vulnerable code:
```\nuint256 availableShares = \n    assetRegistry().convertToSharesFromAsset(asset, \n    assetRegistry().getTotalBalanceForAsset(asset));\n```\n```\nfunction getTotalBalanceForAsset(\n    address asset\n) public view returns (uint256) {\n    if (!isSupportedAsset(asset)) revert ASSET_NOT_SUPPORTED(asset);\n\n    address depositPool_ = address(depositPool());\n    if (asset == ETH_ADDRESS) {\n        return depositPool_.balance + getETHBalanceInEigenLayer();\n    }\n\n    uint256 sharesHeld = getAssetSharesHeld(asset);\n    uint256 tokensInRio = IERC20(asset).balanceOf(depositPool_);\n    uint256 tokensInEigenLayer = \n        convertFromSharesToAsset(\n            getAssetStrategy(asset),\n            sharesHeld\n        );\n\n    return tokensInRio + tokensInEigenLayer;\n}\n```
MEDIUM severity: The `_onlyCalmPeriods` function in Uniswap V3 liquidity providers does not adequately consider the M. The `_onlyCalmPeriods` function in Uniswap V3 liquidity providers does not adequately consider the MIN and MAX ticks, which can lead to a denial-of-service (DoS) attack on deposit, withdrawal, and harvest operations in edge cases.\n\nThe function checks if the current tick (`tick`) is within a certa...

Vulnerable code:
```\nfunction _onlyCalmPeriods() private view {\n    int24 tick = currentTick();\n    int56 twapTick = twap();\n\n    if (\n        twapTick - maxTickDeviationNegative > tick ||\n        twapTick + maxTickDeviationPositive < tick\n    ) {\n        revert NotCalm();\n    }\n}\n```
MEDIUM severity: The `MSG_TAP_EXERCISE` compose message in the USDO protocol allows users to exercise their options a. The `MSG_TAP_EXERCISE` compose message in the USDO protocol allows users to exercise their options and obtain corresponding exercised tapOFTs. This process involves bridging the exercised options to a destination chain of the user's choice. However, the `exerciseOptionsReceiver()` function in the Us...

Vulnerable code:
```\nfunction exerciseOptionsReceiver(address srcChainSender, bytes memory _data) public payable {\n    // Decode received message.\n    ExerciseOptionsMsg memory msg_ = UsdoMsgCodec.decodeExerciseOptionsMsg(_data);\n\n    _checkWhitelistStatus(msg_.optionsData.target);\n    _checkWhitelistStatus(OFTMsgCodec.bytes32ToAddress(msg_.lzSendParams.sendParam.to))\n}\n```
MEDIUM severity: The `getOracleData()` function in the provided code calculates the `maxExternalDeposit` variable wit. The `getOracleData()` function in the provided code calculates the `maxExternalDeposit` variable without considering the `reserve.accruedToTreasury` value. This oversight can lead to an inaccurate calculation of `maxExternalDeposit`, causing the `Treasury.rebalance()` function to fail.\n\nThe calcul...

Vulnerable code:
```\nfunction getOracleData() external view override returns (OracleData memory oracleData) {\n    (uint256 /* */, uint256 supplyCap) = IPoolDataProvider(POOL_DATA_PROVIDER).getReserveCaps(underlying);\n    // Supply caps are returned as whole token values\n    supplyCap = supplyCap * UNDERLYING_PRECISION;\n    uint256 aTokenSupply = IPoolDataProvider(POOL_DATA_PROVIDER).getATokenTotalSupply(underlying);\n\n    // If supply cap is zero, that means there is no cap on the pool\n    if (supplyCap == 0) {\n        oracleData.maxExternalDeposit = type(uint256).max;\n    } else if (supplyCap <= aTokenSupply) {\n        oracleData.maxExternalDeposit = 0;\n    } else {\n        oracleData.maxExternalDeposit = supplyCap - aTokenSupply;\n    }\n}\n```\n```\nrequire(\n  supplyCap == 0 ||\n    (\n      IAToken(reserveCache.aTokenAddress).scaledTotalSupply() +\n      uint256(reserve.accruedToTreasury)\n    ).rayMul(reserveCache.nextLiquidityIndex) + amount <=\n    supplyCap * (10 ** reserveCache.reserveConfiguration.getDecimals()),\n  Errors.SUPPLY_CAP_EXCEEDED\n);\n```
MEDIUM severity: The `_fee()` function in the provided code is implemented incorrectly, leading to an unintended cons. The `_fee()` function in the provided code is implemented incorrectly, leading to an unintended consequence where the protocol receives a reduced fee and the trader earns a higher amount than intended. This issue arises from the calculation of the `amount` variable, which is derived from the `newFee...

Vulnerable code:
```\nuint256 unitFee, amount;\n(unitFee,, ) = _fees(10**decimals(), settlementFeePercentage);\namount = (newFee * 10**decimals()) / unitFee;\n```
MEDIUM severity: This vulnerability allows an attacker to manipulate the minting process in a pool by front-running a. This vulnerability allows an attacker to manipulate the minting process in a pool by front-running a depositor's transaction. The attacker can exploit the rounding down operation when calculating the amount of shares to be minted, resulting in a significant loss of assets for the first depositor.\n\...

Vulnerable code:
```\nfunction _mintInternal(address _receiver, uint _balanceIncreased, uint _totalAsset) internal returns (uint mintShares) {\n    unfreezeTime[_receiver] = block.timestamp + mintFreezeInterval;\n    if (freezeBuckets.interval > 0) {\n        FreezeBuckets.addToFreezeBuckets(freezeBuckets, _balanceIncreased.toUint96());\n    }\n    uint _totalSupply = totalSupply();\n    if (_totalAsset == 0 || _totalSupply == 0) {\n        mintShares = _balanceIncreased + _totalAsset;\n    } else {\n        mintShares = (_balanceIncreased * _totalSupply) / _totalAsset;\n    }\n    if (mintShares == 0) {\n        revert ZeroAmount();\n    }\n    _mint(_receiver, mintShares);\n}\n```