Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The vulnerability allows an attacker to steal liquidity provider fees by exploiting a combination of. The vulnerability allows an attacker to steal liquidity provider fees by exploiting a combination of two code-level issues in the pair's fee tracking mechanism. The first issue is that transferring liquidity tokens to the pair itself does not update the fee tracking variables, resulting in the `fees...

Vulnerable code:
```\nif (to!= address(this)) {\n    _updateFeeRewards(to);\n}\n```
MEDIUM severity: The ordering of modifiers plays a crucial role in ensuring the efficacy of the `nonReentrant` and `r. The ordering of modifiers plays a crucial role in ensuring the efficacy of the `nonReentrant` and `refundFinalBalance` modifiers in the 0x monorepo. Specifically, the consistent appearance of these modifiers in the order `nonReentrant` followed by `refundFinalBalance` is not merely a coincidence. Th...

Vulnerable code:
```\nnon_reentrant\ndef refund_final_balance():\n```
MEDIUM severity: The `buyoutLien()` function in the `LienToken` contract does not correctly update the `liensOpenForE. The `buyoutLien()` function in the `LienToken` contract does not correctly update the `liensOpenForEpoch` variable when processing an epoch. Specifically, when the `buyoutLien()` function is called, it transfers the lien to a new receiver, but it does not decrement the `liensOpenForEpoch` counter. T...

Vulnerable code:
```\nfunction buyoutLien(ILienToken.LienActionBuyout calldata params) external {\n    _transfer(ownerOf(lienId), address(params.receiver), lienId);\n}\n```
MEDIUM severity: The upgradeability of MinerRegistry, AgentPolice, and Agent is overly complex and prone to errors. T. The upgradeability of MinerRegistry, AgentPolice, and Agent is overly complex and prone to errors. The contracts' design allows for the migration of miners, refreshing of routes, and decommissioning of pools, which may lead to difficulties in maintaining the integrity of the mappings within these co...

Vulnerable code:
```\nmapping(uint256 => bool) public liquidated;\n\nmapping(uint256 => uint256[]) private _poolIDs;\n\nmapping(bytes32 => uint256) private _credentialUseBlock;\n\nmapping(uint256 => AgentBeneficiary) private _agentBeneficiaries;\n```\n```\nmapping(bytes32 => bool) private _minerRegistered;\n\nmapping(uint256 => uint64[]) private _minersByAgent;\n```
MEDIUM severity: The vulnerability arises when the portfolio's investment in decentralized finance (DeFi) protocols, . The vulnerability arises when the portfolio's investment in decentralized finance (DeFi) protocols, such as Curve, Aave, or Balancer, results in a loss. In this scenario, the pool balance, which is used to calculate the total reserve and reserve ratio, remains unchanged. This is because the `_balanc...

Vulnerable code:
```\nuint256 tokenReserve = _getBalance(token);\nuint256 tokenCollateral = IInsurancePool(insurancePool).getCollateral(token);\n```
MEDIUM severity: The IERC20(token).approve function is vulnerable to reverting when interacting with non-standard ERC. The IERC20(token).approve function is vulnerable to reverting when interacting with non-standard ERC20 tokens that do not return a boolean value. This is because the Solmate ERC20 implementation, which is used by the protocol, expects the underlying token's approve function to return a boolean value...

Vulnerable code:
```\nfunction approve(address spender, uint256 amount) public virtual returns (bool) {\n    allowance[msg.sender][spender] = amount;\n\n    emit Approval(msg.sender, spender, amount);\n\n    return true;\n}\n```
MEDIUM severity: The `SetToken` contract's `unlock` function allows for early unlocking of the token under specific c. The `SetToken` contract's `unlock` function allows for early unlocking of the token under specific conditions. However, there is a critical issue with the implementation. The `raiseTargetPercentage` variable is not reset after each rebalancing, which prevents the token from being unlocked early in s...

Vulnerable code:
```\nfunction unlock(ISetToken _setToken) external {\n    bool isRebalanceDurationElapsed = _isRebalanceDurationElapsed(_setToken);\n    bool canUnlockEarly = _canUnlockEarly(_setToken);\n\n    require(isRebalanceDurationElapsed || canUnlockEarly, "Cannot unlock early unless all targets are met and raiseTargetPercentage is zero");\n\n    if (canUnlockEarly) {\n        delete rebalanceInfo[_setToken].rebalanceDuration;\n        emit LockedRebalanceEndedEarly(_setToken);\n    }\n\n    _setToken.unlock();\n}\n```\n```\nfunction _canUnlockEarly(ISetToken _setToken) internal view returns (bool) {\n    RebalanceInfo storage rebalance = rebalanceInfo[_setToken];\n    return \n        _allTargetsMet(_setToken) \n        && _isQuoteAssetExcessOrAtTarget(_setToken) \n        && rebalance.raiseTargetPercentage == 0;\n}\n```\n```\nfunction setRaiseTargetPercentage(\n    ISetToken _setToken,\n    uint256 _raiseTargetPercentage\n)\n    external\n    onlyManagerAndValidSet(_setToken)\n{\n    require(_raiseTargetPercentage > 0, "Target percentage must be greater than 0");\n\n    rebalanceInfo[_setToken].raiseTargetPercentage = _raiseTargetPercentage;\n\n    emit RaiseTargetPercentageUpdated(_setToken, _raiseTargetPercentage);\n}\n```
MEDIUM severity: The `iETH.exchangeRateStored` function returns the exchange rate of the contract, which is calculate. The `iETH.exchangeRateStored` function returns the exchange rate of the contract, which is calculated as a function of the current cash of the contract. The current cash is determined by subtracting the `msg.value` from the contract's ETH balance. This is necessary to prevent the value sent with a c...

Vulnerable code:
```\n/**\n * @dev Gets balance of this contract in terms of the underlying\n */\nfunction _getCurrentCash() internal view override returns (uint256) {\n    return address(this).balance.sub(msg.value);\n}\n```\n```\nuint256 _totalSupplyUnderlying = \n    IERC20Upgradeable(_iToken).totalSupply().mul(\n        IiToken(_iToken).exchangeRateStored()\n    );\nrequire(\n    _totalSupplyUnderlying.add(_mintAmount) <= _market.supplyCapacity,\n    "Token supply capacity reached"\n);\n```\n```\n(\n    uint256 _shortfall,\n) = calcAccountEquity(_borrower);\n\nrequire(_shortfall > 0, "Account does not have shortfall");\n```
MEDIUM severity: This vulnerability occurs when the bridging process fails due to the single coordinator being offlin. This vulnerability occurs when the bridging process fails due to the single coordinator being offline, censoring the message, or the bridge token contract being set to an incorrect or malicious address using the `setCustomContract` function. As a result, users who have deposited funds into the `Toke...

Vulnerable code:
```\nfunction setCustomContract(\n    address _nativeToken,\n    address _targetContract\n) external onlyOwner isNewToken(_nativeToken) {\n    nativeToBridgedToken[_nativeToken] = _targetContract;\n    bridgedToNativeToken[_targetContract] = _nativeToken;\n    emit CustomContractSet(_nativeToken, _targetContract);\n}\n```
MEDIUM severity: The `timeToEpochEnd` function is responsible for determining whether a liquidation accountant should. The `timeToEpochEnd` function is responsible for determining whether a liquidation accountant should be deployed and adjusting the protocol math to expect payment in a future epoch. However, due to an error in its implementation, the function calculates the time until the epoch end incorrectly. Spec...

Vulnerable code:
```\nif (PublicVault(owner).timeToEpochEnd() <= COLLATERAL_TOKEN.auctionWindow())\n```\n```\nfunction timeToEpochEnd() public view returns (uint256) {\n    uint256 epochEnd = START() + ((currentEpoch + 1) * EPOCH_LENGTH());\n\n    if (epochEnd >= block.timestamp) {\n        return uint256(0);\n    }\n\n    return block.timestamp - epochEnd;\n}\n```
MEDIUM severity: This vulnerability is an edge-case scenario where a user can burn a positive amount of shares, but u. This vulnerability is an edge-case scenario where a user can burn a positive amount of shares, but unexpectedly receive zero output tokens. The issue arises from a precision loss due to rounding down to zero when calculating the `_amount0` and `_amount1` variables in the `BeefyVaultConcLiq::withdraw...

Vulnerable code:
```\nuint256 _amount0 = (_bal0 * _shares) / _totalSupply;\nuint256 _amount1 = (_bal1 * _shares) / _totalSupply;\n```
MEDIUM severity: The total community voting power calculation is flawed when a user delegates their voting power from. The total community voting power calculation is flawed when a user delegates their voting power from staked tokens. Specifically, the logic for updating the total community voting power is incorrect, leading to potentially incorrect values.\n\nWhen a user delegates their voting power to another user...

Vulnerable code:
```\ntokenVotingPower[currentDelegate] -= amount;\ntokenVotingPower[_delegatee] += amount;\n\nif (_delegator == _delegatee) {\n    _updateTotalCommunityVotingPower(_delegator, true);\n} else if (currentDelegate == _delegator) {\n    _updateTotalCommunityVotingPower(_delegator, false);\n}\n```
MEDIUM severity: The vulnerability arises when a pool is imbalanced, meaning there is an imbalance between the assets. The vulnerability arises when a pool is imbalanced, meaning there is an imbalance between the assets within it. This imbalance can occur due to various reasons, such as unexpected changes in the market or uneven withdrawals. When a reinvestment occurs in an imbalanced pool, the proportional deposit...

Vulnerable code:
```\nFile: Curve2TokenConvexHelper.sol\n\nfunction reinvestReward(\n    Curve2TokenConvexStrategyContext calldata context,\n    ReinvestRewardParams calldata params\n) external {\n    // Make sure we are joining with the right proportion to minimize slippage\n    poolContext._validateSpotPriceAndPairPrice({\n        strategyContext: strategyContext,\n        oraclePrice: poolContext.basePool._getOraclePairPrice(strategyContext),\n        primaryAmount: primaryAmount,\n        secondaryAmount: secondaryAmount\n    });\n```\n```\nFile: Curve2TokenPoolUtils.sol\n\nfunction _checkPrimarySecondaryRatio(\n    StrategyContext memory strategyContext,\n    uint256 primaryAmount,\n    uint256 secondaryAmount,\n    uint256 primaryPoolBalance,\n    uint256 secondaryPoolBalance\n) private pure {\n    uint256 totalAmount = primaryAmount + secondaryAmount;\n    uint256 totalPoolBalance = primaryPoolBalance + secondaryPoolBalance;\n\n    uint256 primaryPercentage = primaryAmount * CurveConstants.CURVE_PRECISION / totalAmount;\n    uint256 expectedPrimaryPercentage = primaryPoolBalance * CurveConstants.CURVE_PRECISION / totalPoolBalance;\n\n    strategyContext._checkPriceLimit(expectedPrimaryPercentage, primaryPercentage);\n\n    uint256 secondaryPercentage = secondaryAmount * CurveConstants.CURVE_PRECISION / totalAmount;\n    uint256 expectedSecondaryPercentage = secondaryPoolBalance * CurveConstants.CURVE_PRECISION / totalPoolBalance;\n\n    strategyContext._checkPriceLimit(expectedSecondaryPercentage, secondaryPercentage);\n}\n```\n```\ndef add_liquidity(amounts: uint256[N_COINS], min_mint_amount: uint256) -> uint256:\n    if token_supply > 0:\n        fee: uint256 = self.fee * N_COINS / (4 * (N_COINS - 1))\n        admin_fee: uint256 = self.admin_fee\n\n        for i in range(N_COINS):\n            ideal_balance: uint256 = D1 * old_balances[i] / D0\n            difference: uint256 = 0\n            if ideal_balance > new_balances[i]:\n                difference = ideal_balance - new_balances[i]\n            else:\n                difference = new_balances[i] - ideal_balance\n            fees[i] = fee * difference / FEE_DENOMINATOR\n            if admin_fee!= 0:\n                self.admin_balances[i] += fees[i] * admin_fee / FEE_DENOMINATOR\n            new_balances[i] -= fees[i]\n\n        D2 = self.get_D(new_balances, amp)\n        mint_amount = token_supply * (D2 - D0) / D0\n    else:\n        mint_amount = D1  # Take the dust if there was any\n```
MEDIUM severity: The `Subaccount#execute` function lacks the `payable` keyword, which allows the function to receive . The `Subaccount#execute` function lacks the `payable` keyword, which allows the function to receive Ether as a payment. This omission can lead to unintended consequences, as any non-zero value passed to the `value` parameter will result in the transaction being reverted.\n\nIn the provided code, the...

Vulnerable code:
```\nfunction execute(address to, bytes calldata data, uint256 value) external onlyOwner returns (bytes memory) {\n    require(to!= address(0));\n    (bool success, bytes memory returnData) = to.call{value: value}(data);\n    if (!success) {\n        assembly {\n            let ptr := mload(0x40)\n            let size := returndatasize()\n            returndatacopy(ptr, 0, size)\n            revert(ptr, size)\n        }\n    }\n    emit ExecuteTransaction(owner, address(this), to, data, value);\n    return returnData;\n```
MEDIUM severity: The Oracle logic implementation in the Steadefi protocol is vulnerable to incorrect data retrieval, . The Oracle logic implementation in the Steadefi protocol is vulnerable to incorrect data retrieval, which may lead to the liquidation of positions. The issue arises from the incorrect method of fetching historical data, specifically in the `_getPrevChainlinkResponse` function. This function attempts...

Vulnerable code:
```\nFile:\n\nfunction consult(address token) public view whenNotPaused returns (int256, uint8) {\n    address _feed = feeds[token];\n\n    if (_feed == address(0)) {\n        revert Errors.NoTokenPriceFeedAvailable();\n    }\n\n    ChainlinkResponse memory chainlinkResponse = _getChainlinkResponse(_feed);\n    ChainlinkResponse memory prevChainlinkResponse = _getPrevChainlinkResponse(_feed, chainlinkResponse.roundId);\n    if (_chainlinkIsFrozen(chainlinkResponse, token)) {\n        revert Errors.FrozenTokenPriceFeed();\n    }\n    if (_chainlinkIsBroken(chainlinkResponse, prevChainlinkResponse, token)) {\n        revert Errors.BrokenTokenPriceFeed();\n    }\n\n    return (chainlinkResponse.answer, chainlinkResponse.decimals);\n}\n```\n```\nfunction _getPrevChainlinkResponse(address _feed, uint80 _currentRoundId) internal view returns (ChainlinkResponse memory) {\n    ChainlinkResponse memory _prevChainlinkResponse;\n\n    (\n      uint80 _roundId,\n      int256 _answer,\n      uint256 _startedAt,\n      uint256 _timestamp,\n      uint80 _answeredInRound\n    ) = AggregatorV3Interface(_feed).getRoundData(_currentRoundId - 1);\n\n    _prevChainlinkResponse.roundId = _roundId;\n    _prevChainlinkResponse.answer = _answer;\n    _prevChainlinkResponse.timestamp = _timestamp;\n    _prevChainlinkResponse.success = true;\n\n    return _prevChainlinkResponse;\n}\n```
MEDIUM severity: The DnGmxJuniorVaultManager's `_rebalanceBorrow` logic is flawed, leading to potential catastrophic . The DnGmxJuniorVaultManager's `_rebalanceBorrow` logic is flawed, leading to potential catastrophic consequences for the vault. Specifically, when only one of the two assets requires rebalancing, the code fails to correctly identify the asset that needs attention. This is due to a logical error in t...

Vulnerable code:
```\nif (btcAssetAmount == 0 && ethAssetAmount == 0) {\n    return;\n}\n\nif (repayDebtBtc && repayDebtEth) {\n    assets = new address[](1);\n    amounts = new uint256[](1);\n\n    assets[0] = address(state.usdc);\n    amounts[0] = (btcAssetAmount + ethAssetAmount);\n} else if (btcAssetAmount == 0 || ethAssetAmount == 0) {\n    assets = new address[](1);\n    amounts = new uint256[](1);\n\n    if (btcAssetAmount == 0) {\n        assets[0] = repayDebtBtc? address(state.usdc) : address(state.wbtc);\n        amounts[0] = btcAssetAmount;\n    } else {\n        assets[0] = repayDebtEth? address(state.usdc) : address(state.weth);\n        amounts[0] = ethAssetAmount;\n    }\n```
MEDIUM severity: The vulnerability lies in the implementation of the `_unstakeAndExitPool` function in various smart . The vulnerability lies in the implementation of the `_unstakeAndExitPool` function in various smart contracts, specifically in the `SingleSidedLPVaultBase.sol`, `BalancerComposableAuraVault.sol`, and `Curve2TokenConvexVault.sol` files. During an emergency exit, the function is executed with the `isS...

Vulnerable code:
```\nFile: SingleSidedLPVaultBase.sol\n\n@notice\nAllows the emergency exit role to trigger an emergency exit on the vault.\nIn this situation, the `claimToExit` is withdrawn proportionally to the underlying\ntokens and held on the vault. The vault is locked so that no entries, exits or\nvaluations of vaultShares can be performed.\n\n@param claimToExit\nif this is set to zero, the entire pool claim is withdrawn\n\nfunction emergencyExit(\n    uint256 claimToExit,\n    bytes calldata /* data */\n) external override onlyRole(EMERGENCY_EXIT_ROLE) {\n    StrategyVaultState memory state = VaultStorage.getStrategyVaultState();\n    if (claimToExit == 0) claimToExit = state.totalPoolClaim;\n\n    // By setting min amounts to zero, we will accept whatever tokens come from the pool\n    // in a proportional exit. Front running will not have an effect since no trading will\n    // occur during a proportional exit.\n    _unstakeAndExitPool(claimToExit, new uint256[](NUM_TOKENS()), true);\n```\n```\nFile: BalancerComposableAuraVault.sol\n\nfunction _unstakeAndExitPool(\n    uint256 poolClaim, uint256[] memory minAmounts, bool isSingleSided\n) internal override returns (uint256[] memory exitBalances) {\n    bool success = AURA_REWARD_POOL.withdrawAndUnwrap(poolClaim, false); // claimRewards = false\n    require(success);\n\n    bytes memory customData;\n    if (isSingleSided) {\n        uint256 primaryIndex = PRIMARY_INDEX();\n        customData = abi.encode(\n            IBalancerVault.ComposableExitKind.EXACT_BPT_IN_FOR_ONE_TOKEN_OUT,\n            poolClaim,\n            primaryIndex < BPT_INDEX? primaryIndex : primaryIndex - 1\n        );\n    }\n```\n```\nFile: Curve2TokenConvexVault.sol\n\nfunction _unstakeAndExitPool(\n    uint256 poolClaim, uint256[] memory _minAmounts, bool isSingleSided\n) internal override returns (uint256[] memory exitBalances) {\n    ICurve2TokenPool pool = ICurve2TokenPool(CURVE_POOL);\n    exitBalances = new uint256[](2);\n    if (isSingleSided) {\n        exitBalances[_PRIMARY_INDEX] = pool.remove_liquidity_one_coin(\n            poolClaim, int8(_PRIMARY_INDEX), _minAmounts[_PRIMARY_INDEX]\n        );\n    }\n```
MEDIUM severity: The vulnerability "Market Price Lower Than Expected" arises from a discrepancy between the market pr. The vulnerability "Market Price Lower Than Expected" arises from a discrepancy between the market price calculation in the `BondBaseSDA` contract and the specification outlined in the whitepaper. Specifically, the `BondBaseSDA.marketPrice` function, as defined in Line 688, correctly rounds up the ma...

Vulnerable code:
```\nFile: BondBaseSDA.sol\n\nfunction marketPrice(uint256 id_) public view override returns (uint256) {\n    uint256 price = currentControlVariable(id_).mulDivUp(currentDebt(id_), markets[id_].scale);\n\n    return (price > markets[id_].minPrice)? price : markets[id_].minPrice;\n}\n```\n```\nFile: BondBaseSDA.sol\n\nfunction _currentMarketPrice(uint256 id_) internal view returns (uint256) {\n    BondMarket memory market = markets[id_];\n    return terms[id_].controlVariable.mulDiv(market.totalDebt, market.scale);\n}\n```
MEDIUM severity: The vulnerability lies in the execution of TYPE_MINT_BURN proposals in the senate, which can be expl. The vulnerability lies in the execution of TYPE_MINT_BURN proposals in the senate, which can be exploited through a reentrancy attack. The proposal execution process involves decoding the proposal payload, which contains information about the token to be minted or burned, the recipient address, the...

Vulnerable code:
```\nif (proposals[_proposalId].actionType == TYPE_MINT_BURN) {\n    (address _token, address _to, uint256 _amount, bool _flag) = \n        abi.decode(proposals[_proposalId].payload, (address, address, uint256, bool));\n\n    if (_flag) {\n        IXMozToken(_token).mint(_amount, _to);\n    } else {\n        IXMozToken(_token).burn(_amount, _to);\n    }\n    proposals[_proposalId].executed = true;\n}\n```\n```\nfunction execute(uint256 _proposalId) public onlyCouncil {\n    require(proposals[_proposalId].executed == false, "Error: Proposal already executed.");\n    require(proposals[_proposalId].confirmation >= threshold, "Error: Not enough confirmations.");\n}\n```
MEDIUM severity: The protocol's rebasing mechanism, which synchronizes the inflation multiplier between the L1 and L2. The protocol's rebasing mechanism, which synchronizes the inflation multiplier between the L1 and L2 chains, is vulnerable to manipulation by malicious actors. The `rebase` function, which can be triggered by anyone, lacks sufficient checks, allowing an attacker to rebase to an outdated value.\n\nTh...

Vulnerable code:
```\nfunction rebase(uint32 _l2Gas) external {\n    inflationMultiplier = IECO(l1Eco).getPastLinearInflation(block.number);\n\n    bytes memory message = abi.encodeWithSelector(\n        IL2ECOBridge.rebase.selector,\n        inflationMultiplier\n    );\n\n    sendCrossDomainMessage(l2TokenBridge, _l2Gas, message);\n}\n```
MEDIUM severity: The rollover process of a strategy position into a longer maturity can lead to an unexpected and pot. The rollover process of a strategy position into a longer maturity can lead to an unexpected and potentially economically impractical accumulation of dust in the strategy. This occurs when the funds borrowed from the new maturity exceed the debt and fees of the current maturity, resulting in a non-z...

Vulnerable code:
```\nuint256 strategyTokensMinted = \nvaultConfig.deposit(\n    vaultAccount.account, \n    vaultAccount.tempCashBalance, \n    vaultState.maturity, \n    additionalUnderlyingExternal, \n    vaultData\n);\n```
MEDIUM severity: The vulnerability lies in the design of the `forceClosePosition` function, which allows hedgers to e. The vulnerability lies in the design of the `forceClosePosition` function, which allows hedgers to exploit users by ignoring their close requests and forcing them to pay a spread. This is achieved by creating a gap between the market price and the user's requested close price, allowing the hedger to...

Vulnerable code:
```\nfunction fillCloseRequest(\n    if (quote.positionType == PositionType.LONG) {\n        require(\n            closedPrice >= quote.requestedClosePrice,\n            "PartyBFacet: Closed price isn't valid"\n        )\n    }\n)\n```\n```\nfunction forceClosePosition(uint256 quoteId, PairUpnlAndPriceSig memory upnlSig) internal {\n    if (quote.positionType == PositionType.LONG) {\n        require(\n            upnlSig.price >= quote.requestedClosePrice +\n                (quote.requestedClosePrice * maLayout.forceCloseGapRatio) / 1e18,\n            "PartyAFacet: Requested close price not reached"\n        );\n    }\n    LibQuote.closeQuote(quote, filledAmount, quote.requestedClosePrice);\n```