Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The FRAX admin has the ability to adjust the fee rate, which can have a detrimental impact on Napier. The FRAX admin has the ability to adjust the fee rate, which can have a detrimental impact on Napier and its users. Specifically, the admin can set the fee to 100%, effectively consuming the entire amount of the staked fee, leaving nothing for Napier's adaptor. This can prevent Napier users from wit...

Vulnerable code:
```\nFile: FraxEtherRedemptionQueue.sol\n\nfunction setRedemptionFee(uint64 _newFee) external {\n    _requireSenderIsTimelock();\n    if (_newFee > FEE_PRECISION) revert ExceedsMaxRedemptionFee(_newFee, FEE_PRECISION);\n\n    emit SetRedemptionFee({\n        oldRedemptionFee: redemptionQueueState.redemptionFee,\n        newRedemptionFee: _newFee\n    });\n\n    redemptionQueueState.redemptionFee = _newFee;\n}\n```\n```\nFile: FraxEtherRedemptionQueue.sol\n\nfunction enterRedemptionQueue(address _recipient, uint120 _amountToRedeem) public nonReentrant {\n    RedemptionQueueState memory _redemptionQueueState = redemptionQueueState;\n    RedemptionQueueAccounting memory _redemptionQueueAccounting = redemptionQueueAccounting;\n\n    uint120 _redemptionFeeAmount = ((uint256(_amountToRedeem) * _redemptionQueueState.redemptionFee) / FEE_PRECISION).toUint120();\n\n    uint120 _amountEtherOwedToUser = _amountToRedeem - _redemptionFeeAmount;\n\n    _redemptionQueueAccounting.etherLiabilities += uint128(_amountEtherOwedToUser);\n\n    _redemptionQueueAccounting.unclaimedFees += _redemptionFeeAmount;\n\n    uint64 _maturityTimestamp = uint64(block.timestamp) + _redemptionQueueState.queueLengthSecs;\n\n    nftInformation[_redemptionQueueState.nextNftId] = RedemptionQueueItem({\n        amount: _amountEtherOwedToUser,\n        maturity: _maturityTimestamp,\n        hasBeenRedeemed: false,\n        earlyExitFee: _redemptionQueueState.earlyExitFee\n    });\n```
MEDIUM severity: The EOPBCTemplate permission documentation inconsistencies vulnerability refers to the discrepancy b. The EOPBCTemplate permission documentation inconsistencies vulnerability refers to the discrepancy between the permissions set by the template and the documentation provided. Specifically, the template code sets permissions for the `TokenManager` and `Controller` contracts, but these permissions are...

Vulnerable code:
```\ncreatePermissions(\n    _acl,\n    grantees,\n    _fundraisingApps.bondedTokenManager,\n    _fundraisingApps.bondedTokenManager.MINT_ROLE(),\n    _owner\n)\n\n_acl.createPermission(\n    _fundraisingApps.marketMaker,\n    _fundraisingApps.bondedTokenManager,\n    _fundraisingApps.bondedTokenManager.BURN_ROLE(),\n    _owner\n)\n```\n```\n- app: anj-token-manager\n  role: MINT_ROLE\n  grantee: market-maker\n  manager: owner\n- app: anj-token-manager\n  role: MINT_ROLE\n  grantee: presale\n  manager: owner\n- app: anj-token-manager\n  role: BURN_ROLE\n  grantee: market-maker\n  manager: owner\n```\n```\nApp        | Permission                            | Grantee | Manager |\n---------- | ------------------------------------- | ------- | ------- |\nController | UPDATE_BENEFICIARY                    | NULL    | NULL    |\nController | UPDATE_FEES                           | NULL    | NULL    |\nController | ADD_COLLATERAL_TOKEN                  | Owner   | Owner   |\nController | REMOVE_COLLATERAL_TOKEN               | Owner   | Owner   |\nController | UPDATE_COLLATERAL_TOKEN               | Owner   | Owner   |\nController | UPDATE_MAXIMUM_TAP_RATE_INCREASE_PCT  | NULL    | NULL    |\nController | UPDATE_MAXIMUM_TAP_FLOOR_DECREASE_PCT | NULL    | NULL    |\nController | ADD_TOKEN_TAP                         | NULL    | NULL    |\nController | UPDATE_TOKEN_TAP                      | NULL    | NULL    |\nController | OPEN_PRESALE                          | Owner   | Owner   |\nController | OPEN_TRADING                          | Presale | Owner   |\nController | CONTRIBUTE                            | Any     | Owner   |\nController | OPEN_BUY_ORDER                        | Any     | Owner   |\nController | OPEN_SELL_ORDER                       | Any     | Owner   |\nController | WITHDRAW                              | NULL    | NULL    |\n```\n```\n_acl.createPermission(_owner, _fundraisingApps.controller, _fundraisingApps.controller.UPDATE_BENEFICIARY_ROLE(), _owner)\n_acl.createPermission(_owner, _fundraisingApps.controller, _fundraisingApps.controller.UPDATE_FEES_ROLE(), _owner)\n```
MEDIUM severity: The `ShortLongSpell#openPosition` function in the contract attempts to burn the wrong token, specifi. The `ShortLongSpell#openPosition` function in the contract attempts to burn the wrong token, specifically `vault.uToken`, instead of the intended `vault`. This incorrect token burn operation is triggered when the user is attempting to add to their existing position. As a result, the function becomes...

Vulnerable code:
```\naddress burnToken = address(ISoftVault(strategy.vault).uToken());\nif (collSize > 0) {\n    if (posCollToken!= address(wrapper)) {\n        revert Errors.INCORRECT_COLTOKEN(posCollToken);\n    }\n    bank.takeCollateral(collSize);\n    wrapper.burn(burnToken, collSize);\n    _doRefund(burnToken);\n}\n```\n```\n_doPutCollateral(\n    vault,\n    IERC20Upgradeable(ISoftVault(vault).uToken()).balanceOf(address(this))\n);\n```
MEDIUM severity: The Execute module is responsible for automating the execution of a series of actions on wallet suba. The Execute module is responsible for automating the execution of a series of actions on wallet subaccounts. However, due to the lack of a reentrancy guard, it is possible for the actions to be executed out of order. This can occur when the `_executeOnSubAccount` function is called recursively, allo...

Vulnerable code:
```\nfunction _executeAutomation(\n    address _wallet,\n    address _subAccount,\n    address _strategy,\n    Types.Executable[] memory _actionExecs\n) internal {\n    uint256 actionLen = _actionExecs.length;\n\n    if (actionLen == 0) {\n        revert InvalidActions();\n    } else {\n        uint256 idx = 0;\n        do {\n            _executeOnSubAccount(_wallet, _subAccount, _strategy, _actionExecs[idx]);\n            unchecked {\n                ++idx;\n            }\n        } while (idx < actionLen);\n    }\n}\n```
MEDIUM severity: When using fee-on-transfer tokens in VaultV3, a limitation is present in the calculation of the actu. When using fee-on-transfer tokens in VaultV3, a limitation is present in the calculation of the actual transferred amount. The underlyingCap is compared to the `_amount` before the actual transferred amount is calculated, which is the balance of the underlying token after the transfer. This means th...

Vulnerable code:
```\nuint256 _pool = balance();\nif (_pool + _amount > underlyingCap) {\n    revert NYProfitTakingVault__UnderlyingCapReached(underlyingCap);\n}\n\nuint256 _before = underlying.balanceOf(address(this));\nunderlying.safeTransferFrom(msg.sender, address(this), _amount);\nuint256 _after = underlying.balanceOf(address(this));\n_amount = _after - _before;\n```
MEDIUM severity: The "Null epochs will freeze rollovers" vulnerability occurs when attempting to roll over a position. The "Null epochs will freeze rollovers" vulnerability occurs when attempting to roll over a position, but a null epoch is triggered. This issue arises from a flawed check in the code, which assumes that a payout was made in the previous epoch. However, when a null epoch is encountered, no payout is...

Vulnerable code:
```\nuint256 entitledShares = previewWithdraw(\n    queue[index].epochId,\n    queue[index].assets\n);\n\nif (entitledShares > queue[index].assets) {\n```
MEDIUM severity: The `getRangeOrderState` function in the `D3Trading` contract is responsible for retrieving the rang. The `getRangeOrderState` function in the `D3Trading` contract is responsible for retrieving the range order state, which is used to determine the swap status for internal swaps. However, a critical error has been identified in the assignment of the `cumulativeBid` variable. Specifically, the `roStat...

Vulnerable code:
```\nFile: D3Trading.sol\n\nroState.toTokenMMInfo.cumulativeBid = \n    allFlag(toTokenIndex) & 1 == 0? 0 : \n    tokenCumMap[toToken].cumulativeAsk;\n```\n```\nFile: PMMRangeOrder.sol\n\n    tokenState.B = askOrNot? \n        tokenState.B0 - tokenMMInfo.cumulativeAsk : \n        tokenState.B0 - tokenMMInfo.cumulativeBid;\n```
MEDIUM severity: The `RFPSimpleStrategy` contract's `setMilestones` function is vulnerable to a potential reentrancy . The `RFPSimpleStrategy` contract's `setMilestones` function is vulnerable to a potential reentrancy attack due to a flawed implementation of the `MILESTONES_ALREADY_SET` error handling mechanism. Specifically, the function checks if `MILESTONES_ALREADY_SET` has been set by verifying the value of `up...

Vulnerable code:
```\nif (upcomingMilestone!= 0):\n    revert MILESTONES_ALREADY_SET()\n```
MEDIUM severity: The RocketTokenRPL's inflation mechanism is vulnerable to inaccurate inflation rate calculation and . The RocketTokenRPL's inflation mechanism is vulnerable to inaccurate inflation rate calculation and potential manipulation, which can result in a lower real APY. The inflation rate is configured as a daily inflation rate (APD) with a corresponding `1 day in blocks` inflation interval in the `rocketD...

Vulnerable code:
```\nfunction getInflationIntervalsPassed() override public view returns(uint256) {\n    uint256 inflationLastCalculatedBlock = getInflationCalcBlock();\n    uint256 inflationInterval = getInflationIntervalBlocks();\n    if (inflationLastCalculatedBlock > 0) {\n        return (block.number).sub(inflationLastCalculatedBlock).div(inflationInterval);\n    } else {\n        return 0;\n    }\n}\n```\n```\nfunction inflationCalculate() public view returns (uint256) {\n    uint256 inflationTokenAmount = 0;\n    uint256 inflationRate = getInflationIntervalRate();\n    uint256 intervalsSinceLastMint = getInflationIntervalsPassed();\n    if (intervalsSinceLastMint > 0 && inflationRate > 0) {\n        uint256 rate = inflationRate;\n        for (uint256 i = 1; i < intervalsSinceLastMint; i++) {\n            rate = rate.mul(inflationRate).div(10 ** 18);\n        }\n        uint256 totalSupplyCurrent = totalSupply();\n        inflationTokenAmount = totalSupplyCurrent.mul(rate).div(10 ** 18).sub(totalSupplyCurrent);\n    }\n    return inflationTokenAmount;\n}\n```
MEDIUM severity: The MixinParams.setParams function in the staking contracts allows authorized addresses to modify th. The MixinParams.setParams function in the staking contracts allows authorized addresses to modify the configurable parameters that govern the behavior of the system. These parameters, which include epoch duration, Cobb-Douglas numerator and denominator, and reward delegation weight, can be set to ar...

Vulnerable code:
```\nif (bool didInitSucceed, bytes memory initReturnData) = stakingContract.delegatecall(\n    abi.encodeWithSelector(IStorageInit(0).init.selector)\n) {\n    if (!didInitSucceed) {\n        assembly {\n            revert(add(initReturnData, 0x20), mload(initReturnData))\n        }\n    }\n}\n\n_assertValidStorageParams();\n```
MEDIUM severity: The `CollateralManager#commitCollateral` function lacks access control, allowing any user to freely . The `CollateralManager#commitCollateral` function lacks access control, allowing any user to freely add malicious tokens to any bid. This vulnerability enables an attacker to manipulate the collateralization of a loan by adding malicious tokens before the loan is filled, thereby disrupting the loan'...

Vulnerable code:
```\nfunction commitCollateral(\n    uint256 _bidId,\n    Collateral[] calldata _collateralInfo\n) public returns (bool validation_) {\n    address borrower = tellerV2.getLoanBorrower(_bidId);\n\n    (validation_, ) = checkBalances(borrower, _collateralInfo);\n\n    if (validation_) {\n        for (uint256 i = 0; i < _collateralInfo.length; i++) {\n            Collateral memory info = _collateralInfo[i];\n            _commitCollateral(_bidId, info);\n        }\n    }\n}\n```
MEDIUM severity: The `lsp20VerifyCall()` and `lsp20VerifyCallResult()` functions, responsible for validating owner ac. The `lsp20VerifyCall()` and `lsp20VerifyCallResult()` functions, responsible for validating owner acceptance of account interactions, deviate from the specified behavior. According to the specification, these functions are expected to return a specific 4-byte magic value. However, the implementation...

Vulnerable code:
```\nfunction _verifyCall(address logicVerifier) internal virtual returns (bool verifyAfter) {\n    (bool success, bytes memory returnedData) = logicVerifier.call(\n        abi.encodeWithSelector(ILSP20.lsp20VerifyCall.selector, msg.sender, msg.value, msg.data)\n    );\n\n    if (!success) {\n        _revert(false, returnedData);\n    }\n\n    if (returnedData.length < 32) {\n        revert LSP20InvalidMagicValue(false, returnedData);\n    }\n\n    bytes32 magicValue = abi.decode(returnedData, (bytes32));\n\n    if (bytes32(magicValue)!= ILSP20.lsp20VerifyCall.selector) {\n        revert LSP20InvalidMagicValue(false, returnedData);\n    }\n\n    return bytes1(magicValue[3]) == 0x01? true : false;\n}\n```
MEDIUM severity: The vulnerability arises when a user initiates a decrease order, specifying a `minOutputAmount` valu. The vulnerability arises when a user initiates a decrease order, specifying a `minOutputAmount` value to protect themselves from losses. This value is intended to ensure that they receive a minimum amount of tokens in case the swap operation fails. However, if the `DecreaseOrderUtils.processOrder` f...

Vulnerable code:
```\ntry params.contracts.swapHandler.swap(\n    SwapUtils.SwapParams(\n        params.contracts.dataStore,\n        params.contracts.eventEmitter,\n        params.contracts.oracle,\n        Bank(payable(order.market())),\n        params.key,\n        result.outputToken,\n        result.outputAmount,\n        params.swapPathMarkets,\n        0,\n        order.receiver(),\n        order.uiFeeReceiver(),\n        order.shouldUnwrapNativeToken()\n    )\n) returns (address tokenOut, uint256 swapOutputAmount) {\n    (\n        params.contracts.oracle,\n        tokenOut,\n        swapOutputAmount,\n        order.minOutputAmount()\n    );\n} catch (bytes memory reasonBytes) {\n    (string memory reason, ) = ErrorUtils.getRevertMessage(reasonBytes);\n\n    _handleSwapError(\n        params.contracts.oracle,\n        order,\n        result,\n        reason,\n        reasonBytes\n    );\n}\n```\n```\ninternal function null(\n    Oracle oracle,\n    Order.Props memory order,\n    DecreasePositionUtils.DecreasePositionResult memory result,\n    string memory reason,\n    bytes memory reasonBytes\n) {\n    emit SwapUtils.SwapReverted(reason, reasonBytes);\n\n    _validateOutputAmount(\n        oracle,\n        result.outputToken,\n        result.outputAmount,\n        order.minOutputAmount()\n    );\n\n    MarketToken payable(order.market()).transferOut(\n        result.outputToken,\n        order.receiver(),\n        result.outputAmount,\n        order.shouldUnwrapNativeToken()\n    );\n}\n```
MEDIUM severity: The `NapierPool` smart contract allows the `poolOwner` to update the `protocolFeePercent` parameter . The `NapierPool` smart contract allows the `poolOwner` to update the `protocolFeePercent` parameter at any point, without any limitations on the frequency of updates. This lack of restriction creates an opportunity for the `poolOwner` to unfairly increase the protocol fees on swaps to earn more reve...

Vulnerable code:
```\nfunction test_protocol_owner_frontRuns_swaps_with_higher_fees() public whenMaturityNotPassed {\n    // Pre-condition\n    vm.warp(maturity - 30 days);\n    deal(address(pts[0]), alice, type(uint96).max, false); // Ensure alice has enough PT\n    uint256 preBaseLptSupply = tricrypto.totalSupply();\n    uint256 ptInDesired = 100 * ONE_UNDERLYING;\n    uint256 expectedBaseLptIssued = tricrypto.calc_token_amount([ptInDesired, 0, 0], true);\n\n    // Pool owner sees swap about to occur and front runs updating fees to max value\n    vm.startPrank(owner);\n    pool.setFeeParameter("protocolFeePercent", 100);\n    vm.stopPrank();\n\n    // Execute\n    vm.prank(alice);\n    uint256 underlyingOut = pool.swapPtForUnderlying(\n        0, ptInDesired, recipient, abi.encode(CallbackInputType.SwapPtForUnderlying, SwapInput(underlying, pts[0]))\n    );\n\n    // Sanity check\n    uint256 protocolFee = SwapEventsLib.getProtocolFeeFromLastSwapEvent(pool);\n    assertGt(protocolFee, 0, "Fee should be charged");\n}\n```
MEDIUM severity: The AaveLeverageStrategyExtension does not effectively safeguard against tokens with a Loan-to-Value. The AaveLeverageStrategyExtension does not effectively safeguard against tokens with a Loan-to-Value (LTV) of 0. This vulnerability poses significant risks, as tokens with an LTV of 0 cannot be used as collateral to borrow, potentially leading to a Denial-of-Service (DoS) situation. Moreover, LTVs o...

Vulnerable code:
```\n/**\n * Calculate total notional rebalance quantity and chunked rebalance quantity in collateral units.\n *\n * return uint256          Chunked rebalance notional in collateral units\n * return uint256          Total rebalance notional in collateral units\n */\nfunction _calculateChunkRebalanceNotional(\n    LeverageInfo memory _leverageInfo,\n    uint256 _newLeverageRatio,\n    bool _isLever\n)\n    internal\n    view\n    returns (uint256, uint256)\n{\n    uint256 leverageRatioDifference = _isLever\n       ? _newLeverageRatio.sub(_leverageInfo.currentLeverageRatio)\n        : _leverageInfo.currentLeverageRatio.sub(_newLeverageRatio);\n\n    uint256 totalRebalanceNotional = leverageRatioDifference.preciseDiv(_leverageInfo.currentLeverageRatio).preciseMul(_leverageInfo.action.collateralBalance);\n\n    uint256 maxBorrow = _calculateMaxBorrowCollateral(_leverageInfo.action, _isLever);\n\n    uint256 chunkRebalanceNotional = Math.min(Math.min(maxBorrow, totalRebalanceNotional), _leverageInfo.twapMaxTradeSize);\n\n    return (chunkRebalanceNotional, totalRebalanceNotional);\n}\n\n/**\n * Calculate the max borrow / repay amount allowed in base units for lever / delever. This is due to overcollateralization requirements on\n * assets deposited in lending protocols for borrowing.\n *\n * For lever, max borrow is calculated as:\n * (Net borrow limit in USD - existing borrow value in USD) / collateral asset price adjusted for decimals\n *\n * For delever, max repay is calculated as:\n * Collateral balance in base units * (net borrow limit in USD - existing borrow value in USD) / net borrow limit in USD\n *\n * Net borrow limit for levering is calculated as:\n * The collateral value in USD * Aave collateral factor * (1 - unutilized leverage %)\n *\n * Net repay limit for delevering is calculated as:\n * The collateral value in USD * Aave liquiditon threshold * (1 - unutilized leverage %)\n *\n * return uint256          Max borrow notional denominated in collateral asset\n */\nfunction _calculateMaxBorrowCollateral(ActionInfo memory _actionInfo, bool _isLever) internal view returns (uint256) {\n    (, uint256 maxLtvRaw, uint256 liquidationThresholdRaw,,,\n```
MEDIUM severity: The SingleSidedLiquidityVault contract contains a critical issue in its `withdraw` function, which i. The SingleSidedLiquidityVault contract contains a critical issue in its `withdraw` function, which incorrectly updates the `ohmMinted` variable. This variable is used to track the total number of ohm minted in the contract, and its incorrect calculation can lead to inaccurate results in various part...

Vulnerable code:
```\nohmMinted -= ohmReceived > ohmMinted? ohmMinted : ohmReceived;\nohmRemoved += ohmReceived > ohmMinted? ohmReceived - ohmMinted : 0;\n```\n```\nfunction _canDeposit(uint256 amount_) internal view virtual returns (bool) {\n    if (amount_ + ohmMinted > LIMIT + ohmRemoved) {\n        revert LiquidityVault_LimitViolation();\n    }\n    return true;\n}\n```\n```\nfunction getOhmEmissions() external view returns (uint256 emitted, uint256 removed) {\n    uint256 currentPoolOhmShare = _getPoolOhmShare();\n\n    if (ohmMinted > currentPoolOhmShare + ohmRemoved) {\n        emitted = ohmMinted - currentPoolOhmShare - ohmRemoved;\n    } else {\n        removed = currentPoolOhmShare + ohmRemoved - ohmMinted;\n    }\n}\n```
MEDIUM severity: The `_handleERC20Received` function in the contract incorrectly charges a fee in both external and i. The `_handleERC20Received` function in the contract incorrectly charges a fee in both external and internal swap scenarios. When an external swap occurs, a portion of the fee is intended to be deducted from the bridged amount. However, the same fee is also applied in internal swap scenarios, which i...

Vulnerable code:
```\n} else {\n    uint256 fee = (bridgedAmount * dstExternalFeeRate) / FEE_BASE;\n    bridgedAmount -= fee;  // fee should not be applied to internal swap\n\n    TransferHelper.safeApprove(bridgedToken, address(wooRouter), bridgedAmount);\n    if (dst1inch.swapRouter!= address(0)) {\n        try {\n            wooRouter.externalSwap(\n```
MEDIUM severity: The `RocketNodeDistributor` contract's dynamic proxy mechanism is vulnerable to a potential issue du. The `RocketNodeDistributor` contract's dynamic proxy mechanism is vulnerable to a potential issue due to the lack of an `extcodesize` check when resolving the target delegate from the centralized `RocketStorage` contract. This allows for the possibility of the delegate being set to `address(0)`, whi...

Vulnerable code:
```\nfallback() external payable {\n    address _target = rocketStorage.getAddress(distributorStorageKey);\n    assembly {\n        calldatacopy(0x0, 0x0, calldatasize())\n        let result := delegatecall(gas(), _target, 0x0, calldatasize(), 0x0, 0)\n        returndatacopy(0x0, 0x0, returndatasize())\n        switch result {\n            case 0 {\n                revert(0, returndatasize())\n            }\n            default {\n                return (0, returndatasize())\n            }\n        }\n    }\n}\n```\n```\nfunction getAddress(bytes32 _key) override external view returns (address r) {\n    return addressStorage[_key];\n}\n```
MEDIUM severity: When a bounty issuer sets a new winner by calling the `setTierWinner()` function, the code does not . When a bounty issuer sets a new winner by calling the `setTierWinner()` function, the code does not reset the invoice and supporting documents for that tier. This is a critical issue, as it allows a malicious winner to bypass the required invoice and supporting document checks. \n\nIn a tiered bount...

Vulnerable code:
```\nfunction setTierWinner(\n    string calldata _bountyId,\n    uint256 _tier,\n    string calldata _winner\n) external {\n    IBounty bounty = getBounty(_bountyId);\n    require(msg.sender == bounty.issuer(), Errors.CALLER_NOT_ISSUER);\n    bounty.setTierWinner(_winner, _tier);\n\n    emit TierWinnerSelected(\n        address(bounty),\n        bounty.getTierWinners(),\n        new bytes(0),\n        VERSION_1\n    );\n}\n\nfunction setTierWinner(string memory _winner, uint256 _tier)\n    external\n    onlyOpenQ\n{\n    tierWinners[_tier] = _winner;\n```
MEDIUM severity: The `_finalizeBlocks` method in `ZkEvmV2` is responsible for verifying the integrity of L2 blocks be. The `_finalizeBlocks` method in `ZkEvmV2` is responsible for verifying the integrity of L2 blocks before finalizing them. A critical flaw exists in this process, where the current block timestamp `blockInfo.l2BlockTimestamp` is not properly validated. Specifically, the method does not check if the c...

Vulnerable code:
```\nif (blockInfo.l2BlockTimestamp >= block.timestamp) {\n    revert BlockTimestampError();\n}\n```