Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: This vulnerability is an edge case that occurs when a user locks their MENTO balance, chooses a dele. This vulnerability is an edge case that occurs when a user locks their MENTO balance, chooses a delegate, and then the contract is stopped. The user's veMENTO, which grants them voting power, is not affected by the contract stoppage. When the contract is restarted, the user can withdraw their entire...

Vulnerable code:
```\nfunction getAvailableForWithdraw(address account) public view returns (uint96) {\n    uint96 value = accounts[account].amount;\n    if (!stopped) {\n        uint32 currentBlock = getBlockNumber();\n        uint32 time = roundTimestamp(currentBlock);\n        uint96 bias = accounts[account].locked.actualValue(time, currentBlock);\n        value = value - bias;\n    }\n    return value;\n```\n```\nfunction test_Poc_Stop() public {\n\n    vm.prank(governanceTimelockAddress);\n    mentoToken.transfer(alice, 10_000e18);\n\n    vm.prank(governanceTimelockAddress);\n    mentoToken.transfer(bob, 10_000e18);\n\n    vm.prank(alice);\n    locking.lock(alice, alice, 10_000e18, 1, 103);\n\n    vm.prank(bob);\n    locking.lock(bob, bob, 1500e18, 1, 103);\n\n    vm.timeTravel(BLOCKS_DAY);\n\n    uint256 newVotingDelay = BLOCKS_DAY;\n    uint256 newVotingPeriod = 2 * BLOCKS_WEEK;\n    uint256 newThreshold = 5000e18;\n    uint256 newQuorum = 10; // 10%\n    uint256 newMinDelay = 3 days;\n    uint32 newMinCliff = 6;\n    uint32 newMinSlope = 12;\n\n    vm.prank(alice);\n    (\n        uint256 proposalId,\n        address[] memory targets,\n        uint256[] memory values,\n        bytes[] memory calldatas,\n        string memory description\n    ) = Proposals._proposeChangeSettings(\n        mentoGovernor,\n        governanceTimelock,\n        locking,\n        newVotingDelay,\n        newVotingPeriod,\n        newThreshold,\n        newQuorum,\n        newMinDelay,\n        newMinCliff,\n        newMinSlope\n    );\n\n    vm.timeTravel(120);\n\n    vm.startPrank(governanceTimelockAddress);\n    locking.stop();\n    vm.stopPrank();\n\n    uint bal2 = mentoToken.balanceOf(alice);\n    console.log(bal2);\n\n    vm.startPrank(alice);\n    locking.withdraw();\n    vm.stopPrank();\n\n    vm.startPrank(governanceTimelockAddress);\n    locking.start();\n    vm.stopPrank();\n\n    uint bal = mentoToken.balanceOf(alice);\n    console.log(bal);\n    vm.prank(alice);\n\n    console.log(mentoGovernor.castVote(proposalId, 1));\n}\n```
MEDIUM severity: The `oracleCircuitBreaker()` function in the `LibOracle` library lacks a crucial check to verify the. The `oracleCircuitBreaker()` function in the `LibOracle` library lacks a crucial check to verify the staleness of the base oracle (ETH/USD price) data. Specifically, the function does not verify whether the `baseChainlinkPrice` is stale (2-hour stale heartbeat) by comparing the current block timesta...

Vulnerable code:
```\nfunction oracleCircuitBreaker(\n    uint80 roundId,\n    uint80 baseRoundId,\n    int256 chainlinkPrice,\n    int256 baseChainlinkPrice,\n    uint256 timeStamp,\n    uint256 baseTimeStamp\n) private view {\n    bool invalidFetchData = roundId == 0 || timeStamp == 0\n        || timeStamp > block.timestamp || chainlinkPrice <= 0 || baseRoundId == 0\n        || baseTimeStamp == 0 || baseTimeStamp > block.timestamp\n        || baseChainlinkPrice <= 0;\n\n    if (invalidFetchData) revert Errors.InvalidPrice();\n}\n\nfunction baseOracleCircuitBreaker(\n    uint256 protocolPrice,\n    uint80 roundId,\n    int256 chainlinkPrice,\n    uint256 timeStamp,\n    uint256 chainlinkPriceInEth\n) private view returns (uint256 _protocolPrice) {\n    bool invalidFetchData = roundId == 0 || timeStamp == 0\n        || timeStamp > block.timestamp || chainlinkPrice <= 0\n        || block.timestamp > 2 hours + timeStamp;\n    uint256 chainlinkDiff = chainlinkPriceInEth > protocolPrice\n       ? chainlinkPriceInEth - protocolPrice\n        : protocolPrice - chainlinkPriceInEth;\n    bool priceDeviation =\n        protocolPrice > 0 && chainlinkDiff.div(protocolPrice) > 0.5 ether;\n\n    // rest of code\n}\n```
MEDIUM severity: The `getTargetExternalLendingAmount()` function, when `targetUtilization` equals zero, directly retu. The `getTargetExternalLendingAmount()` function, when `targetUtilization` equals zero, directly returns a target amount of zero without verifying whether sufficient external underlying assets are available for withdrawal. This oversight can lead to `_rebalanceCurrency()` reverting due to insufficien...

Vulnerable code:
```\nfunction getTargetExternalLendingAmount(\n    Token memory underlyingToken,\n    PrimeCashFactors memory factors,\n    RebalancingTargetData memory rebalancingTargetData,\n    OracleData memory oracleData,\n    PrimeRate memory pr\n) internal pure returns (uint256 targetAmount) {\n    if (rebalancingTargetData.targetUtilization == 0) {\n        return 0;\n    }\n\n    if (targetAmount < oracleData.currentExternalUnderlyingLend) {\n        uint256 forRedemption = oracleData.currentExternalUnderlyingLend - targetAmount;\n        if (oracleData.externalUnderlyingAvailableForWithdraw < forRedemption) {\n            targetAmount = targetAmount.add(forRedemption - oracleData.externalUnderlyingAvailableForWithdraw);\n        }\n    }\n}\n```
MEDIUM severity: The `BalancerPairOracle#getPrice` function is vulnerable to a division by zero error in certain scen. The `BalancerPairOracle#getPrice` function is vulnerable to a division by zero error in certain scenarios. This occurs when the `computeFairReserves` function is called with parameters `resA` and `resB`, which represent the balances of TokenA and TokenB in the pool, respectively. Specifically, when...

Vulnerable code:
```\nfunction computeFairReserves(\n        uint256 resA,\n        uint256 resB,\n        uint256 wA,\n        uint256 wB,\n        uint256 pxA,\n        uint256 pxB\n    ) internal pure returns (uint256 fairResA, uint256 fairResB) {\n    uint256 r0 = resA / resB;\n    uint256 r1 = (wA * pxB) / (wB * pxA);\n    if (r0 > r1) {\n        uint256 ratio = r1 / r0;\n        fairResA = resA * (ratio ** wB);\n        fairResB = resB / (ratio ** wA);\n    } else {\n        uint256 ratio = r0 / r1;\n        fairResA = resA / (ratio ** wB);\n        fairResB = resB * (ratio ** wA);\n    }\n}\n```
MEDIUM severity: The RageTrade senior vault's utilization cap, set at 90%, poses a significant risk to the stability . The RageTrade senior vault's utilization cap, set at 90%, poses a significant risk to the stability of UXD. This cap requires the vault to maintain a minimum of 10% more deposits than loans, which can lead to prolonged periods of deposit locking. In the event of a strong depeg of UXD, a substantial...

Vulnerable code:
```\nfunction beforeWithdraw(\n    uint256 assets,\n    uint256,\n    address\n) internal override {\n    if (totalUsdcBorrowed() > ((totalAssets() - assets) * maxUtilizationBps) / MAX_BPS)\n        revert MaxUtilizationBreached();\n\n    pool.withdraw(address(asset), assets, address(this));\n}\n```
MEDIUM severity: The `getPoolPrice()` function in the `hedgeDelta` contract is responsible for retrieving the price o. The `getPoolPrice()` function in the `hedgeDelta` contract is responsible for retrieving the price of a Uniswap v3 pool. This function is used to calculate the price by multiplying the `sqrtPriceX96` value, which has 96 bits of precision, with itself and then scaling the result by the token's decima...

Vulnerable code:
```\nfunction getPoolPrice() public view returns (uint256 price, uint256 inversed) {\n    (uint160 sqrtPriceX96,,,,,, ) = pool.slot0();\n    uint256 p = uint256(sqrtPriceX96) * uint256(sqrtPriceX96) * (10 ** uint256(token0.decimals()));\n    price = p / (2 ** 192);\n    inversed = 1e36 / price;\n}\n```
MEDIUM severity: The `getMarketCap` function in the `DynamicLiquidTokenConverter` contract calculates the reserve's m. The `getMarketCap` function in the `DynamicLiquidTokenConverter` contract calculates the reserve's market capitalization by multiplying the reserve balance with a hardcoded value of `1e6` and then dividing the result by the reserve's weight. This hardcoded value, `1e6`, represents the PPM (parts per...

Vulnerable code:
```\nfunction getMarketCap(IERC20Token _reserveToken)\n    public\n    view\n    returns(uint256)\n{\n    Reserve storage reserve = reserves[_reserveToken];\n    return reserveBalance(_reserveToken).mul(1e6).div(reserve.weight);\n}\n```
MEDIUM severity: The `fetchUpgradeProposal` function in MiniGovernance contains a critical flaw that renders the upgr. The `fetchUpgradeProposal` function in MiniGovernance contains a critical flaw that renders the upgrade mechanism ineffective. The issue arises from the hardcoded `duration` value of 4 weeks passed to the `newProposal` function. This hardcoded value is not validated against the constant `MAX_PROPOSA...

Vulnerable code:
```\nGEM.newProposal(\n    proposal.CONTROLLER,\n    2,\n    proposal.NAME,\n    4\n)\n```\n```\nrequire(\n    duration <= MAX_PROPOSAL_DURATION,\n    "GeodeUtils: duration exceeds MAX_PROPOSAL_DURATION"\n);\n```
MEDIUM severity: The Uniswap formula for estimating implied volatility (IV) drastically underestimates the true IV of. The Uniswap formula for estimating implied volatility (IV) drastically underestimates the true IV of a given asset. This is because the formula relies on the assumption of an efficient market, where rational actors can arbitrage away any discrepancies between the estimated IV and the true IV. Howeve...

Vulnerable code:
```\nThe realized volatility of most assets hover between 75% and 200% annualized in ETH terms. If we compare this to the IV extracted from the Uniswap v3 pools, we get:\n\nNote that the volatilities are somewhat lower, perhaps a factor of ~2.5, for most assets.\n```
MEDIUM severity: The `_calculateClaim()` function is responsible for calculating the amount of emissions a specific v. The `_calculateClaim()` function is responsible for calculating the amount of emissions a specific veSatin is entitled to claim. This calculation involves iterating through a loop for each week from the current timestamp to the last claim. The loop iterates until the condition `(lockEndTime - weekCu...

Vulnerable code:
```\nif ((lockEndTime - weekCursor) > (minLockDurationForReward)):\n    toDistribute += (balanceOf * tokensPerWeek[weekCursor]) / veSupply[weekCursor]\n    weekCursor += WEEK\n```
MEDIUM severity: The `_cacheFundraisingParams()` function in the EOPBCTemplate contract does not explicitly declare t. The `_cacheFundraisingParams()` function in the EOPBCTemplate contract does not explicitly declare the return value memory location, which can lead to unexpected behavior and potential security vulnerabilities. This function is responsible for caching fundraising parameters, but the lack of explicit...

Vulnerable code:
```\nfunction _cacheFundraisingParams(\n    address _owner,\n    string _id,\n    ERC20 _collateralToken,\n    MiniMeToken _bondedToken,\n    uint64 _period,\n    uint256 _exchangeRate,\n    uint64 _openDate,\n    uint256 _reserveRatio,\n    uint256 _batchBlocks,\n    uint256 _slippage\n) \n    internal\n    returns (FundraisingParams fundraisingParams)\n```\n```\nfunction _cacheFundraisingApps(\n    Agent _reserve,\n    Presale _presale,\n    MarketMaker _marketMaker,\n    Tap _tap,\n    Controller _controller,\n    TokenManager _tokenManager\n) internal returns (FundraisingApps memory fundraisingApps) {\n    fundraisingApps.reserve = _reserve;\n    fundraisingApps.presale = _presale;\n    fundraisingApps.marketMaker = _marketMaker;\n    fundraisingApps.tap = _tap;\n    fundraisingApps.controller = _controller;\n    fundraisingApps.bondedTokenManager = _tokenManager;\n}\n```
MEDIUM severity: The protocol's mint function allows for the creation of new tokens after the maturity date, which ca. The protocol's mint function allows for the creation of new tokens after the maturity date, which can be exploited by malicious actors to manipulate the token supply and gain an unfair advantage over legitimate users. This vulnerability enables a scenario where a malicious actor can "sandwich" legit...

Vulnerable code:
```\nfunction mint(\n    uint8 p,\n    address u,\n    uint256 m,\n    uint256 a\n) external unpaused(u, m, p) returns (bool) {\n    address principal = IMarketPlace(marketPlace).token(u, m, p);\n\n    Safe.transferFrom(IERC20(principal), msg.sender, address(this), a);\n\n    IERC5095(principalToken(u, m)).authMint(msg.sender, a);\n\n    emit Mint(p, u, m, a);\n\n    return true;\n}\n```
MEDIUM severity: The `totalCoverTokens` variable is decreased prematurely before the claim is committed, allowing liq. The `totalCoverTokens` variable is decreased prematurely before the claim is committed, allowing liquidity providers to withdraw their funds before the claim is processed. This vulnerability arises from the fact that the `totalCoverTokens` is updated immediately after the policy duration ends, which...

Vulnerable code:
```\npolicyHolders[_msgSender()] = PolicyHolder(\n    _coverTokens,\n    currentEpochNumber,\n    _endEpochNumber,\n    _totalPrice,\n    _reinsurancePrice\n)\n\nepochAmounts[_endEpochNumber] = epochAmounts[_endEpochNumber].add(_coverTokens)\n```\n```\nuint256 _countOfPassedEpoch = block.timestamp.sub(epochStartTime).div(EPOCH_DURATION);\n\nnewTotalCoverTokens = totalCoverTokens;\nlastEpochUpdate = currentEpochNumber;\nnewEpochNumber = _countOfPassedEpoch.add(1);\n\nfor (uint256 i = lastEpochUpdate; i < newEpochNumber; i++) {\n    newTotalCoverTokens = newTotalCoverTokens.sub(epochAmounts[i]);\n}\n```\n```\nfunction isPolicyActive(address _userAddr, address _policyBookAddr) public override view returns (bool) {\n    PolicyInfo storage _currentInfo = policyInfos[_userAddr][_policyBookAddr];\n\n    if (_currentInfo.endTime == 0) {\n        return false;\n    }\n\n    return _currentInfo.endTime.add(STILL_CLAIMABLE_FOR) > block.timestamp;\n}\n```
MEDIUM severity: The vulnerability allows an attacker to perform a denial-of-service (DoS) attack on the liquidity pr. The vulnerability allows an attacker to perform a denial-of-service (DoS) attack on the liquidity provider (LP) by packing the `tokenIdToBorrowingKeys` array with a large number of user keys. This can be achieved by repeatedly borrowing small amounts of a token, such as USDC, using different address...

Vulnerable code:
```\nfunction _addKeysAndLoansInfo(\n    bool update,\n    bytes32 borrowingKey,\n    LoanInfo[] memory sourceLoans\n) private {\n    // Get the storage reference to the loans array for the borrowing key\n    LoanInfo[] storage loans = loansInfo[borrowingKey];\n\n    // Iterate through the sourceLoans array\n    for (uint256 i = 0; i < sourceLoans.length; i++) {\n        // Get the current loan from the sourceLoans array\n        LoanInfo memory loan = sourceLoans[i];\n\n        // Get the storage reference to the tokenIdLoansKeys array for the loan's token ID\n        bytes32[] storage tokenIdLoansKeys = tokenIdToBorrowingKeys[loan.tokenId];\n\n        // Conditionally add or push the borrowing key to the tokenIdLoansKeys array based on the 'update' flag\n        update\n           ? tokenIdLoansKeys.addKeyIfNotExists(borrowingKey)\n            : tokenIdLoopsKeys.push(borrowingKey);\n}\n```\n```\nfunction computeBorrowingKey(\n    address borrower,\n    address saleToken,\n    address holdToken\n) internal pure returns (bytes32) {\n    return keccak256(abi.encodePacked(borrower, saleToken, holdToken));\n}\n```\n```\nfunction addKeyIfNotExists(bytes32[] storage self, bytes32 key) internal {\n    uint256 length = self.length;\n    for (uint256 i = 0; i < length; ) {\n        if (self[i].value == key) {\n            return;\n        }\n        unchecked {\n            i++;\n        }\n    }\n    self.push(key);\n}\n\nfunction removeKey(bytes32[] storage self, bytes32 key) internal {\n    uint256 length = self.length;\n    for (uint256 i = 0; i < length; ) {\n        if (self[i].value == key) {\n            self[i].value = self[length - 1].value;\n            self.pop();\n            break;\n        }\n        unchecked {\n            i++;\n        }\n    }\n}\n```
MEDIUM severity: The `unstake()` function, responsible for calculating the vested amount, contains a critical flaw th. The `unstake()` function, responsible for calculating the vested amount, contains a critical flaw that restricts team members from unstaking their initial allocation indefinitely. This issue arises from the `_vestingCheck()` function, which returns a value of 0 for team members when calculating the...

Vulnerable code:
```\nfunction _vestingCheck(address user, uint256 amount) internal view returns (uint256) {\n    if (teamAllocations[user] > 0) return 0; // return 0 for team members\n\n    uint256 initialAllocation = seedAllocations[user];\n\n    if (initialAllocation > 0) {\n        if (block.timestamp < vestingStart) return 0;\n        uint256 vestPortion = FixedPointMathLib.divWad(block.timestamp - vestingStart, vestingEnd - vestingStart);\n        return FixedPointMathLib.mulWad(vestPortion, initialAllocation) - (initialAllocation - stakedLocks[user]);\n    } else {\n        return amount;\n    }\n}\n```
MEDIUM severity: The vulnerability lies in the handling of ETH withdrawals within the Rio protocol. Specifically, whe. The vulnerability lies in the handling of ETH withdrawals within the Rio protocol. Specifically, when a user initiates an ETH withdrawal request, they do not earn yield on their staking rewards while waiting for the withdrawal to be processed. This is in contrast to the documentation, which states t...

Vulnerable code:
```\nsharesOwed = convertToSharesFromRestakingTokens(asset, amountIn);\n```\n```\nepochWithdrawals.assetsReceived = SafeCast.toUint120(assetsReceived);\n```\n```\nepochWithdrawals.assetsReceived = SafeCast.toUint120(assetsReceived);\n```\n```\nepochWithdrawals.assetsReceived += \n    SafeCast.toUint120(assetsReceived);\n```\n```\namountOut = userSummary.sharesOwed.mulDiv(epochWithdrawals.assetsReceived, epochWithdrawals.sharesOwed)\n```
MEDIUM severity: The `removeNode` function in the NodeRegistry contract is responsible for removing a node from the `. The `removeNode` function in the NodeRegistry contract is responsible for removing a node from the `Nodes` array. This process involves copying the last node in the array to the `_nodeIndex` of the node to be removed, and then decreasing the array size. Additionally, the `SignerInformation` struct,...

Vulnerable code:
```\nstruct SignerInformation {\n    uint64 lockedTime;  // timestamp until the deposit of an in3-node can not be withdrawn after the node was removed\n    address owner;  // the owner of the node\n\n    Stages stage;  // state of the address\n\n    uint depositAmount;  // amount of deposit to be locked, used only after a node had been removed\n\n    uint index;  // current index-position of the node in the node-array\n}\n```\n```\nIn3Node memory m = nodes[length - 1];\nnodes[_nodeIndex] = m;\n\nSignerInformation storage si = signerIndex[m.signer];\nsi.index = uint64(_nodeIndex);\nnodes.length--;\n```
MEDIUM severity: The vulnerability lies in the implementation of certain ERC20 tokens, which do not adhere to the sta. The vulnerability lies in the implementation of certain ERC20 tokens, which do not adhere to the standard interface for ERC20 token interactions. Specifically, these tokens do not return a boolean value indicating the success or failure of the `approve` and `transfer` methods. This deviation from th...

Vulnerable code:
```\nfunction setApprovalForERC20(\n    IERC20 erc20Contract,\n    address to,\n    uint256 amount\n) external onlyClubOwner {\n    erc20Contract.approve(to, amount);\n}\n```\n```\nfunction transferERC20(\n    IERC20 erc20Contract,\n    address to,\n    uint256 amount\n) external onlyClubOwner {\n    erc20Contract.transfer(to, amount);\n}\n```
MEDIUM severity: The `processAuction()` function in the `VaultAdmin.sol` contract is vulnerable to being called multi. The `processAuction()` function in the `VaultAdmin.sol` contract is vulnerable to being called multiple times by the keeper if the auction is canceled. This occurs because the function's logic allows for the auction status to be changed to `PROCESSED` even if the auction has not been finalized.\n\nT...

Vulnerable code:
```\nbool cancelled = l.Auction.isCancelled(lastEpoch);\nbool finalized = l.Auction.isFinalized(lastEpoch);\n\nrequire(\n    (!finalized && cancelled) || (finalized &&!cancelled),\n    "auction is not finalized nor cancelled"\n);\n```
MEDIUM severity: The `AccountV1#flashActionByCreditor` function is designed to facilitate atomic flash actions, allow. The `AccountV1#flashActionByCreditor` function is designed to facilitate atomic flash actions, allowing the owner of an account to transfer assets directly out of the account. However, this functionality can be exploited by an attacker to drain assets from an account without withdrawing them. The vu...

Vulnerable code:
```\n1) Deposit ERC721\n2) Set creditor to malicious designed creditor\n3) Transfer the account to itself\n4) flashActionByCreditor to transfer ERC721\n    4a) account owns itself so _transferFromOwner allows transfers from account\n    4b) Account is now empty but still thinks it has ERC721\n5) Use malicious designed liquidator contract to call auctionBoughtIn\n    and transfer account back to attacker\n6) Update creditor to legitimate creditor\n7) Take out loan against nothing\n8) Profit\n```\n```\nif (transferFromOwnerData.assets.length > 0) {\n    _transferFromOwner(transferFromOwnerData, actionTarget);\n}\n```\n```\nfunction auctionBoughtIn(address recipient) external onlyLiquidator nonReentrant {\n    _transferOwnership(recipient);\n}\n```
MEDIUM severity: The vulnerability lies in the `settleFundingFees` function of the `FlatcoinVault` smart contract, wh. The vulnerability lies in the `settleFundingFees` function of the `FlatcoinVault` smart contract, which is responsible for calculating and adjusting the global margin and collateral amounts. Specifically, the function calculates the funding fees accrued to the long positions and updates the `marginD...

Vulnerable code:
```\nFile: FlatcoinVault.sol\n\nfunction settleFundingFees() public returns (int256 _fundingFees) {\n    // Calculate the funding fees accrued to the longs.\n    // This will be used to adjust the global margin and collateral amounts.\n    _fundingFees = PerpMath._accruedFundingTotalByLongs(_globalPositions, unrecordedFunding);\n\n    // In the worst case scenario that the last position which remained open is underwater,\n    // we set the margin deposited total to 0. We don't want to have a negative margin deposited total.\n    _globalPositions.marginDepositedTotal = (_globalPositions.marginDepositedTotal > _fundingFees)\n       ? uint256(int256(_globalPositions.marginDepositedTotal) + _fundingFees)\n        : 0;\n\n    _updateStableCollateralTotal(-_fundingFees);\n```
MEDIUM severity: The `RocketMinipoolDelegate` contract is designed to be used as a delegate, receiving calls from the. The `RocketMinipoolDelegate` contract is designed to be used as a delegate, receiving calls from the `Minipool` contract, and not intended to be consumed directly. Direct access to the delegate contract could potentially lead to unintended consequences, including the possibility of `selfdestruct`ing...

Vulnerable code:
```\nconstructor(address _rocketStorageAddress) {\n    require(_rocketStorageAddress!= address(0x0), "Invalid storage address");\n    rocketStorage = RocketStorageInterface(_rocketStorageAddress);\n}\n```
MEDIUM severity: The `freeze` function in this smart contract allows the owner to toggle the frozen state of the cont. The `freeze` function in this smart contract allows the owner to toggle the frozen state of the contract, which can have significant implications for external parties interacting with the contract. However, the current implementation lacks a crucial step: emitting an event to notify interested parti...

Vulnerable code:
```\nfunction freeze(bool _freeze) public onlyOwner {\n    frozen = _freeze;\n}\n```