Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The `zAuction` system, which relies on the `zAuctionAccountant` for upgrade management, lacks a clea. The `zAuction` system, which relies on the `zAuctionAccountant` for upgrade management, lacks a clear and seamless upgrade path. The `zAuctionAccountant` can be configured to allow only one `zAuction` contract to interact with it at a time. When an administrator updates the referenced `zAuction` con...

Vulnerable code:
```\nfunction SetZauction(address zauctionaddress) external onlyAdmin {\n    zauction = zauctionaddress;\n    emit ZauctionSet(zauctionaddress);\n}\n```
MEDIUM severity: The `_computeClosingFactor` function in the Market contract is responsible for calculating the requi. The `_computeClosingFactor` function in the Market contract is responsible for calculating the required borrow amount that should be liquidated to make a user's position solvent. However, this calculation is flawed due to the use of the `collateralizationRate` (defaulting to 75%) to determine the de...

Vulnerable code:
```\nuint256 liquidationStartsAt = \n    (collateralPartInAsset * _liquidationCollateralizationRate) / (10 ** ratesPrecision);\n\nif (borrowPart < liquidationStartsAt) return 0;\n\nuint256 numerator = borrowPart - liquidationStartsAt;\n\nuint256 diff = \n    (collateralizationRate * ((10 ** ratesPrecision) + _liquidationMultiplier)) / (10 ** ratesPrecision);\nint256 denominator = ((10 ** ratesPrecision) - int256(diff)) * int256(1e13);\n\nint256 x = (int256(numerator) * int256(1e18)) / denominator;\n```
MEDIUM severity: The `TransceiverRegistry::_setTransceiver` function is responsible for managing the registration and. The `TransceiverRegistry::_setTransceiver` function is responsible for managing the registration and re-enabling of Transceivers. This function is designed to prevent the re-registration of Transceivers, as this can have unintended consequences. However, it also attempts to re-enable previously regi...

Vulnerable code:
```\nfunction _setTransceiver(address transceiver) internal returns (uint8 index) {\n    if (transceiver == address(0)) {\n        revert InvalidTransceiverZeroAddress();\n    }\n\n    if (_numTransceivers.registered >= MAX_TRANSCEIVERS) {\n        revert TooManyTransceivers();\n    }\n\n    if (transceiverInfos[transceiver].registered) {\n        transceiverInfos[transceiver].enabled = true;\n    } else {\n        // snip\n    }\n}\n```
MEDIUM severity: The ERC1155 standard allows for callback functions to be executed during certain transfer operations. The ERC1155 standard allows for callback functions to be executed during certain transfer operations, such as `safeTransferFrom` and `safeBatchTransferFrom`. These callback functions, specifically `IERC1155ReceiverUpgradeable(to).onERC1155Received`, are invoked on the recipient's address (`to`) duri...

Vulnerable code:
```\nfunction distributeAllNFT() external {\n    require(block.timestamp > getEndLMTime(), "2 weeks after liquidity mining time has not expired");\n    require(!isNFTDistributed, "NFT is already distributed");\n\n    for (uint256 i = 0; i < leaderboard.length; i++) {\n        address[] memory groupLeaders = groupsLeaders[leaderboard[i]];\n\n        for (uint256 j = 0; j < groupLeaders.length; j++) {\n            _sendNFT(j, groupLeaders[j]);\n        }\n    }\n\n    for (uint256 i = 0; i < topUsers.length; i++) {\n        address currentAddress = topUsers[i];\n        LMNFT.safeTransferFrom(address(this), currentAddress, 1, 1, "");\n        emit NFTSent(currentAddress, 1);\n    }\n\n    isNFTDistributed = true;\n}\n```
MEDIUM severity: The `RocketDaoNodeTrusted` contract's initial deployment process involves setting the deployer as th. The `RocketDaoNodeTrusted` contract's initial deployment process involves setting the deployer as the Guardian/Bootstrapping role, granting them control over the TrustedNode and Protocol DAO. This Guardian can bootstrap the DAO, add members, upgrade components, change settings, and interact with the...

Vulnerable code:
```\n/**\nRecovery\n*/\n\nfunction memberJoinRequired(string memory _id, string memory _email) override public onlyLowMemberMode onlyRegisteredNode(msg.sender) onlyLatestContract("rocketDAONodeTrusted", address(this)) {\n    (bool successPropose, bytes memory responsePropose) = getContractAddress('rocketDAONodeTrustedProposals').call(abi.encodeWithSignature("proposalInvite(string,string,address)", _id, _email, msg.sender));\n    require(successPropose, getRevertMsg(responsePropose));\n\n    (bool successJoin, bytes memory responseJoin) = getContractAddress("rocketDAONodeTrustedActions").call(abi.encodeWithSignature("actionJoinRequired(address)", msg.sender));\n    require(successJoin, getRevertMsg(responseJoin));\n}\n```\n```\nsetSettingBool("node.registration.enabled", true);\n```
MEDIUM severity: The `buyPolicyFor` and `addLiquidityFor` functions in the `PolicyBook` contract are vulnerable to un. The `buyPolicyFor` and `addLiquidityFor` functions in the `PolicyBook` contract are vulnerable to unauthorized fund transfers. When these functions are called with the `_policyHolderAddr` or `_liquidityHolderAddr` parameter set to the address of the beneficiary, the funds are transferred from the in...

Vulnerable code:
```\nfunction buyPolicyFor(\n    address _policyHolderAddr,\n    uint256 _epochsNumber,\n    uint256 _coverTokens\n) external override {\n    _buyPolicyFor(_policyHolderAddr, _epochsNumber, _coverTokens);\n}\n```\n```\nfunction addLiquidityFor(address _liquidityHolderAddr, uint256 _liquidityAmount) external override {\n    _addLiquidityFor(_liquidityHolderAddr, _liquidityAmount, false);\n}\n```
MEDIUM severity: The BalancerLBPSwapper may not have sufficient Tribe tokens, which can lead to issues when the `swap. The BalancerLBPSwapper may not have sufficient Tribe tokens, which can lead to issues when the `swap` function is called. This vulnerability arises from the fact that the contract does not initially initialize the Balancer pool with the required 1% Tribe tokens. Instead, it relies on the `swap` func...

Vulnerable code:
```\nfunction _getTokensIn(uint256 spentTokenBalance) internal view returns (uint256[] memory amountsIn) {\n    amountsIn = new uint256[](2);\n\n    uint256 receivedTokenBalance = readOracle().mul(spentTokenBalance).mul(ONE_PERCENT).div(NINETY_NINE_PERCENT).asUint256();\n\n    if (address(assets[0]) == tokenSpent) {\n        amountsIn[0] = spentTokenBalance;\n        amountsIn[1] = receivedTokenBalance;\n    } else {\n        amountsIn[0] = receivedTokenBalance;\n        amountsIn[1] = spentTokenBalance;\n    }\n}\n```\n```\nIERC20(tokenReceived).transfer(tokenReceivingAddress, IERC20(tokenReceived).balanceOf(address(this)))\n```
MEDIUM severity: The vulnerability lies in the lack of strategyId validation when checking the Max LTV requirements. . The vulnerability lies in the lack of strategyId validation when checking the Max LTV requirements. When a user withdraws some of their underlying token, the `_validateMaxLTV` function is called to ensure they remain compliant with their strategy's specified LTV. However, the function does not verif...

Vulnerable code:
```\nfunction _validateMaxLTV(uint256 strategyId) internal view {\n    uint256 debtValue = bank.getDebtValue(bank.POSITION_ID());\n    (\n       ,\n        address collToken,\n        uint256 collAmount,\n       ,\n       ,\n       ,\n       ,\n        ) = bank.getCurrentPositionInfo();\n    uint256 collPrice = bank.oracle().getPrice(collToken);\n    uint256 collValue = (collPrice * collAmount) / 10**IERC20Metadata(collToken).decimals();\n\n    if (debtValue > (collValue * maxLTV[strategyId][collToken]) / DENOMINATOR) {\n        revert EXCEED_MAX_LTV();\n    }\n}\n```\n```\nfunction reducePosition(\n    uint256 strategyId,\n    address collToken,\n    uint256 collAmount\n) external {\n    doWithdraw(collToken, collAmount);\n    doRefund(collToken);\n    _validateMaxLTV(strategyId);\n}\n```
MEDIUM severity: The "Poison" order vulnerability allows an attacker to create a malicious order that can block marke. The "Poison" order vulnerability allows an attacker to create a malicious order that can block market trades by consuming all available gas. This is achieved by using an external contract that consumes gas during signature validation, thereby forcing the overall transaction to revert. The attacker c...

Vulnerable code:
```\nbytes memory fillOrderCalldata = abi.encodeWithSelector(\n    IExchangeCore(address(0)).fillOrder.selector,\n    order,\n    takerAssetFillAmount,\n    signature\n);\n\n(bool didSucceed, bytes memory returnData) = address(this).delegatecall(fillOrderCalldata);\n```\n```\n(bool didSucceed, bytes memory returnData) = \n    verifyingContractAddress.staticcall(callData);\n```
MEDIUM severity: This vulnerability is related to an unnecessary cast of the `address` variables `_dai` and `_ant` to. This vulnerability is related to an unnecessary cast of the `address` variables `_dai` and `_ant` to the `address` type in the constructor of the `FundraisingMultisigTemplate` contract. The `address` type is already a built-in type in Solidity, and it is not necessary to explicitly cast the variable...

Vulnerable code:
```\nconstructor(\n    DAOFactory _daoFactory,\n    ENS _ens,\n    MiniMeTokenFactory _miniMeFactory,\n    IFIFSResolvingRegistrar _aragonID,\n    address _dai,\n    address _ant\n) {\n    BaseTemplate(_daoFactory, _ens, _miniMeFactory, _aragonID);\n    public {\n        _ensureAragonIdIsValid(_aragonID);\n        _ensureMiniMeFactoryIsValid(_miniMeFactory);\n        _ensureTokenIsContractOrETH(_dai);\n        _ensureTokenIsContractOrETH(_ant);\n\n        collaterals.push(address(_dai));\n        collaterals.push(address(_ant));\n    }\n}\n```
MEDIUM severity: The PCVEquityMinter and BalancerLBPSwapper contracts are vulnerable to a desynchronisation race cond. The PCVEquityMinter and BalancerLBPSwapper contracts are vulnerable to a desynchronisation race condition. This vulnerability arises from the fact that there is no mechanism to prevent malicious actors from calling the `BalancerLBPSwapper.swap()` function after the `PCVEquityMinter.mint()` function...

Vulnerable code:
```\nfunction _afterMint() internal override {\n    IPCVSwapper(target).swap();\n}\n```\n```\nfunction swap() external override afterTime whenNotPaused {\n    (\n        uint256 spentReserves,\n        uint256 receivedReserves,\n        uint256 lastChangeBlock\n    ) = getReserves();\n\n    require(lastChangeBlock < block.number, "BalancerLBPSwapper: pool changed this block");\n}\n```
MEDIUM severity: The `createHat` function in the contract is designed to prevent the creation of hats for the lowest . The `createHat` function in the contract is designed to prevent the creation of hats for the lowest hat tier by checking if the provided `_admin` value is greater than 0. However, this check is flawed as it only examines the lowest 8 bits of the `_admin` value, which is insufficient to accurately de...

Vulnerable code:
```\nfunction createHat(\n    uint256 _admin,\n    string memory _details,\n    uint32 _maxSupply,\n    address _eligibility,\n    address _toggle,\n    bool _mutable,\n    string memory _imageURI\n) public returns (uint256 newHatId) {\n    if (uint8(_admin) > 0) {\n        revert MaxLevelsReached();\n    }\n   ....\n}\n```
MEDIUM severity: The vulnerability allows a malicious user to finalize another user's withdrawal with less than the s. The vulnerability allows a malicious user to finalize another user's withdrawal with less than the specified gas limit, resulting in the loss of funds. This occurs due to a gap between the check and the execution of the withdrawal transaction in the `OptimismPortal` contract.\n\nWhen a withdrawal tr...

Vulnerable code:
```\nrequire(\n    gasleft() >= _tx.gasLimit + FINALIZE_GAS_BUFFER,\n    "OptimismPortal: insufficient gas to finalize withdrawal"\n);\n```
MEDIUM severity: The `DFSExchangeCore.onChainSwap` function is called in the `_sell` and `_buy` functions, which are . The `DFSExchangeCore.onChainSwap` function is called in the `_sell` and `_buy` functions, which are responsible for facilitating off-chain and on-chain swaps. The `onChainSwap` function is used as a fallback mechanism when the off-chain swap fails. However, the return values from `onChainSwap` are n...

Vulnerable code:
```\nfunction _sell(ExchangeData memory exData) internal returns (address, uint256) {\n    uint256 amountWithoutFee = exData.srcAmount;\n    address wrapper = exData.offchainData.wrapper;\n    bool offChainSwapSuccess;\n\n    uint256 destBalanceBefore = exData.destAddr.getBalance(address(this));\n\n    exData.srcAmount -= getFee(\n        exData.srcAmount,\n        exData.user,\n        exData.srcAddr,\n        exData.dfsFeeDivider\n    );\n\n    if (exData.offchainData.price > 0) {\n        (offChainSwapSuccess, ) = offChainSwap(exData, ExchangeActionType.SELL);\n    }\n\n    if (!offChainSwapSuccess) {\n        onChainSwap(exData, ExchangeActionType.SELL);\n        wrapper = exData.wrapper;\n    }\n\n    uint256 destBalanceAfter = exData.destAddr.getBalance(address(this));\n    uint256 amountBought = sub(destBalanceAfter, destBalanceBefore);\n\n    require(amountBought >= wmul(exData.minPrice, exData.srcAmount), ERR_SLIPPAGE_HIT);\n\n    exData.srcAmount = amountWithoutFee;\n\n    return (wrapper, amountBought);\n}\n```\n```\nfunction _buy(ExchangeData memory exData) internal returns (address, uint256) {\n    require(exData.destAmount!= 0, ERR_DEST_AMOUNT_MISSING);\n\n    uint256 amountWithoutFee = exData.srcAmount;\n    address wrapper = exData.offchainData.wrapper;\n    bool offChainSwapSuccess;\n\n    uint256 destBalanceBefore = exData.destAddr.getBalance(address(this));\n\n    exData.srcAmount -= getFee(\n        exData.srcAmount,\n        exData.user,\n        exData.srcAddr,\n        exData.dfsFeeDivider\n    );\n\n    if (exData.offchainData.price > 0) {\n        (offChainSwapSuccess, ) = offChainSwap(exData, ExchangeActionType.BUY);\n    }\n\n    if (!offChainSwapSuccess) {\n        onChainSwap(exData, ExchangeActionType.BUY);\n        wrapper = exData.wrapper;\n    }\n\n    uint256 destBalanceAfter = exData.destAddr.getBalance(address(this));\n    uint256 amountBought = sub(destBalanceAfter, destBalanceBefore);\n\n    require(amountBought >= exData.destAmount, ERR_SLIPPAGE_HIT);\n\n    exData.srcAmount = amountWithoutFee;\n\n    return (wrapper, amountBought);\n}\n```
MEDIUM severity: The vulnerability lies in the `getRevertMessage` function of the ErrorUtilss, which is responsible f. The vulnerability lies in the `getRevertMessage` function of the ErrorUtilss, which is responsible for extracting the error message from the revert data. This function is called during the execution of callbacks for deposits, withdrawals, and orders. The issue arises when a user-controlled callback...

Vulnerable code:
```\ntry (\n    IDepositCallbackReceiver(deposit.callbackContract()).afterDepositExecution(\n        gas: deposit.callbackGasLimit()\n    )\n) (\n    key,\n    deposit\n) {\n    catch (bytes memory reasonBytes) {\n        (string memory reason, ) = ErrorUtils.getRevertMessage(reasonBytes);\n        emit AfterDepositExecutionError(key, deposit, reason, reasonBytes);\n    }\n}\n```
MEDIUM severity: The LiquidationRow contract, responsible for orchestrating the claiming process and collecting rewar. The LiquidationRow contract, responsible for orchestrating the claiming process and collecting rewards for vaults, contains a critical vulnerability in its `liquidateVaultsForToken` method. This method is designed to conduct the liquidation process for a specific token across a list of vaults, perfo...

Vulnerable code:
```\nfunction liquidateVaultsForToken(\n    address fromToken,\n    address asyncSwapper,\n    IDestinationVault[] memory vaultsToLiquidate,\n    SwapParams memory params\n) external nonReentrant hasRole(Roles.LIQUIDATOR_ROLE) onlyWhitelistedSwapper(asyncSwapper) {\n    uint256 gasBefore = gasleft();\n\n    (uint256 totalBalanceToLiquidate, uint256[] memory vaultsBalances) = \n        _prepareForLiquidation(fromToken, vaultsToLiquidate);\n\n    _performLiquidation(\n        gasBefore, \n        fromToken, \n        asyncSwapper, \n        vaultsToLiquidate, \n        params, \n        totalBalanceToLiquidate, \n        vaultsBalances\n    );\n}\n```\n```\nfunction _performLiquidation(\n    uint256 gasBefore,\n    address fromToken,\n    address asyncSwapper,\n    IDestinationVault[] memory vaultsToLiquidate,\n    SwapParams memory params,\n    uint256 totalBalanceToLiquidate,\n    uint256[] memory vaultsBalances\n) private {\n    uint256 length = vaultsToLiquidate.length;\n\n    uint256 amountReceived = IAsyncSwapper(asyncSwapper).swap(params);\n}\n```
MEDIUM severity: The `delegateBySig` function in the provided smart contract lacks input validation, specifically in . The `delegateBySig` function in the provided smart contract lacks input validation, specifically in the handling of the `nonce` and `expiry` parameters. This vulnerability allows an attacker to manipulate the `nonce` and `expiry` values, potentially leading to unauthorized delegation of voting power...

Vulnerable code:
```\nfunction delegateBySig(\n    address delegatee,\n    uint256 nonce,\n    uint256 expiry,\n    uint8 v,\n    bytes32 r,\n    bytes32 s\n) public {\n    require(block.timestamp <= expiry, "ERC20MultiVotes: signature expired");\n    address signer = ecrecover(\n        keccak256(\n            abi.encodePacked(\n                "\x19\x01",\n                DOMAIN_SEPARATOR(),\n                keccak256(abi.encode(\n                    DELEGATION_TYPEHASH,\n                    delegatee,\n                    nonce,\n                    expiry\n                ))\n            )\n        ),\n        v,\n        r,\n        s\n    );\n    require(nonce == nonces[signer]++, "ERC20MultiVotes: invalid nonce");\n    _delegate(signer, delegatee);\n}\n```
MEDIUM severity: The vulnerability allows a malicious user to manipulate the value of shares in the insurance fund by. The vulnerability allows a malicious user to manipulate the value of shares in the insurance fund by frontrunning withdrawals. This is achieved by exploiting the sequential nature of the withdrawal process, which involves unbonding shares and then waiting for the pre-determined unbonding period befo...

Vulnerable code:
```\namount = balance() * shares / totalSupply()\n```\n```\nvusd.safeTransfer(marginAccount, toTransfer);\n```
MEDIUM severity: The use of the `assert` statement in this code is not suitable for its intended purpose. According t. The use of the `assert` statement in this code is not suitable for its intended purpose. According to the Solidity documentation, `assert` should only be used to test for internal errors and check invariants. In this context, the `assert` statements are used to verify the correctness of external int...

Vulnerable code:
```\nassert function should only be used to test for internal errors, and to check invariants.\n```\n```\nassert(_to[i].send(_value[i]))\n```\n```\nassert(msg.sender.send(remainingValue));\n```\n```\nassert(token.transferFrom(msg.sender, _to[i], _value[i]) == true)\n```
MEDIUM severity: The interest rate calculation formula provided in the documentation is not accurately reflected in t. The interest rate calculation formula provided in the documentation is not accurately reflected in the implementation. Specifically, the `getBorrowRatePerSecond` function in the `rateModel` contract incorrectly considers the entire balance as the available liquidity, whereas the formula suggests tha...

Vulnerable code:
```\nfunction getRateFactor() internal view returns (uint) {\n    return (block.timestamp == lastUpdated)?\n        0 :\n        (\n            (block.timestamp - lastUpdated) * 1e18\n        ).mulWadUp(\n            rateModel.getBorrowRatePerSecond(\n                asset.balanceOf(address(this)),\n                borrows\n            )\n        );\n}\n```\n```\nfunction getBorrowRatePerSecond(\n    uint liquidity,\n    uint borrows\n)\n    external\n    view\n    returns (uint)\n{\n    uint util = _utilization(liquidity, borrows);\n    return c3.mulDivDown(\n        (\n            util.mulWadDown(c1)\n            + util.rpow(32, SCALE).mulWadDown(c1)\n            + util.rpow(64, SCALE).mulWadDown(c2)\n        ),\n        secsPerYear\n    );\n}\n```\n```\nfunction _utilization(uint liquidity, uint borrows)\n    internal\n    pure\n    returns (uint)\n{\n    uint totalAssets = liquidity + borrows;\n    return (totalAssets == 0)? 0 : borrows.divWadDown(totalAssets);\n}\n```
MEDIUM severity: The vulnerability arises from a flawed implementation in the `LibQuote.closeQuote` function, which f. The vulnerability arises from a flawed implementation in the `LibQuote.closeQuote` function, which fails to ensure that the remaining quote value does not fall below the minimum acceptable quote value (`minAcceptableQuoteValue`) when partially closing positions. Specifically, the function checks if...

Vulnerable code:
```\nif (LibQuote.quoteOpenAmount(quote)!= quote.quantityToClose) {\n    require(quote.lockedValues.total() >= symbolLayout.symbols[quote.symbolId].minAcceptableQuoteValue,\n        "LibQuote: Remaining quote value is low");\n}\n```
MEDIUM severity: The `_getProposalState()` function in the `Goldigovernor` contract contains a vulnerability in its l. The `_getProposalState()` function in the `Goldigovernor` contract contains a vulnerability in its logic for determining the state of a proposal. Specifically, the function uses the `totalSupply()` function from the `Goldiswap` contract to compare the `forVotes` variable against a threshold value, w...

Vulnerable code:
```\nfunction _getProposalState(uint256 proposalId) internal view returns (ProposalState) {\n    Proposal storage proposal = proposals[proposalId];\n    if (proposal.cancelled) {\n        return ProposalState.Canceled;\n    } else if (block.number <= proposal.startBlock) {\n        return ProposalState.Pending;\n    } else if (block.number <= proposal.endBlock) {\n        return ProposalState.Active;\n    } else if (proposal.eta == 0) {\n        return ProposalState.Succeeded;\n    } else if (proposal.executed) {\n        return ProposalState.Executed;\n    } else if (proposal.forVotes <= proposal.againstVotes || proposal.forVotes < Goldiswap(goldiswap).totalSupply() / 20) {\n        return ProposalState.Defeated;\n    } else if (block.timestamp >= proposal.eta + Timelock(timelock).GRACE_PERIOD()) {\n        return ProposalState.Expired;\n    } else {\n        return ProposalState.Queued;\n    }\n}\n```
MEDIUM severity: The `OUSGInstantManager::_redeemBUIDL` function in the `BUIDLRedeemer` contract assumes a fixed 1:1 . The `OUSGInstantManager::_redeemBUIDL` function in the `BUIDLRedeemer` contract assumes a fixed 1:1 ratio between BUIDL and USDC, which may not hold true during a USDC depeg event. Specifically, when the USDC peg is compromised, the value of 1 USDC may not be equivalent to $1, resulting in a mismatc...

Vulnerable code:
```\nuint256 usdcBalanceBefore = usdc.balanceOf(address(this));\n\nbuidl.approve(address(buidlRedeemer), buidlAmountToRedeem);\n\nbuidlRedeemer.redeem(buidlAmountToRedeem);\n\nrequire(\n    usdc.balanceOf(address(this)) == usdcBalanceBefore + buidlAmountToRedeem,\n    "OUSGInstantManager::_redeemBUIDL: BUIDL:USDC not 1:1"\n);\n```
MEDIUM severity: The Asymmetry in Transceiver pausing capability vulnerability arises from the exposure of the `Trans. The Asymmetry in Transceiver pausing capability vulnerability arises from the exposure of the `Transceiver::_pauseTransceiver` function, which allows the transceiver to be paused, but lacks a corresponding function to unpause it. This asymmetry creates a situation where the transceiver can be paused...

Vulnerable code:
```\nfunction _pauseTransceiver() internal {\n    _pause();\n}\n```