Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The vulnerability allows an attacker to front-run various deposit state transitions, including fraud. The vulnerability allows an attacker to front-run various deposit state transitions, including fraudulent ECDSA signature proofs and timeouts, to manipulate the distribution of the deposit contract's ETH value. This is achieved by observing transactions and providing fraudulent proofs with a higher...

Vulnerable code:
```\nfunction provideECDSAFraudProof(\n    DepositUtils.Deposit storage _d,\n    uint8 _v,\n    bytes32 _r,\n    bytes32 _s,\n    bytes32 _signedDigest,\n    bytes memory _preimage\n) public {\n    require(\n       !_d.inFunding() &&!_d.inFundingFailure(),\n        "Use provideFundingECDSAFraudProof instead"\n    );\n    require(\n       !_d.inSignerLiquidation(),\n        "Signer liquidation already in progress"\n    );\n    require(!_d.inEndState(), "Contract has halted");\n    require(submitSignatureFraud(_d, _v, _r, _s, _signedDigest, _preimage), "Signature is not fraud");\n    startSignerFraudLiquidation(_d);\n}\n```\n```\nfunction provideFundingECDSAFraudProof(\n    DepositUtils.Deposit storage _d,\n    uint8 _v,\n    bytes32 _r,\n    bytes32 _s,\n    bytes32 _signedDigest,\n    bytes memory _preimage\n) public {\n    require(\n        _d.inAwaitingBTCFundingProof(),\n        "Signer fraud during funding flow only available while awaiting funding"\n    );\n\n    bool _isFraud = _d.submitSignatureFraud(_v, _r, _s, _signedDigest, _preimage);\n    require(_isFraud, "Signature is not fraudulent");\n    _d.logFraudDuringSetup();\n\n    if (block.timestamp > _d.fundingProofTimerStart + TBTCConstants.getFundingTimeout()) {\n        address(0).transfer(address(this).balance);  // Burn it all down (fire emoji)\n        _d.setFailedSetup();\n    } else {\n        _d.fundingProofTimerStart = block.timestamp;\n        _d.setFraudAwaitingBTCFundingProof();\n    }\n}\n```\n```\nuint256 contractEthBalance = address(this).balance;\naddress payable initiator = _d.liquidationInitiator;\n\nif (initiator == address(0)) {\n    initiator = address(0xdead);\n}\nif (contractEthBalance > 0) {\n    if (_wasFraud) {\n        initiator.transfer(contractEthBalance);\n    } else {\n        uint256 split = contractEthBalance / 2;\n        _d.pushFundsToKeepGroup(split);\n        initiator.transfer(split);\n    }\n}\n```
MEDIUM severity: The vulnerability in the BalancedVault.sol contract allows an early depositor to manipulate the exch. The vulnerability in the BalancedVault.sol contract allows an early depositor to manipulate the exchange rate and steal funds from subsequent depositors. This is achieved by minting a small number of shares and then donating assets to the Vault, thereby manipulating the exchange rate. As a result, l...

Vulnerable code:
```\nit('exchange rate manipulation', async () => {\n  const smallDeposit = utils.parseEther('1')\n  const smallestDeposit = utils.parseEther('0.000000000000000001')\n\n  await vault.connect(user).deposit(smallestDeposit, user.address)\n  await updateOracle()\n  await vault.sync()\n\n  console.log(await vault.totalSupply())\n\n  await dsu.connect(user).transfer(vault.address, utils.parseEther('1'))\n\n  console.log(await vault.totalAssets())\n\n  await updateOracle()\n  await vault.sync()\n  await vault.connect(user2).deposit(smallDeposit, user2.address)\n  await updateOracle()\n  await vault.sync()\n\n  console.log(await vault.totalAssets())\n  console.log(await vault.totalSupply())\n  console.log(await vault.balanceOf(user2.address))\n\n  // the amount of shares the victim receives is rounded down to 0\n  // at this point there are 2000000000000000001 Wei of assets in the Vault and only 1 Wei of shares\n  // which is owned by the attacker.\n  // This means the attacker has stolen all funds from the victim.\n```
MEDIUM severity: The vulnerability lies in the absence of incentives for liquidators to liquidate certain PartyB acco. The vulnerability lies in the absence of incentives for liquidators to liquidate certain PartyB accounts. Specifically, the `liquidatePartyB` function does not provide a liquidation fee to the liquidators when the available balance is insufficient to cover the locked balance. This lack of incentive...

Vulnerable code:
```\nFile: LiquidationFacetImpl.sol\n\nfunction liquidatePartyB(\n    if (uint256(-availableBalance) < accountLayout.partyBLockedBalances[partyB][partyA].lf) {\n    remainingLf = \n        accountLayout.partyBLockedBalances[partyB][partyA].lf - \n        uint256(-availableBalance);\n    liquidatorShare = (remainingLf * maLayout.liquidatorShare) / 1e18;\n\n    maLayout.partyBPositionLiquidatorsShare[partyB][partyA] = \n        (remainingLf - liquidatorShare) / \n        quoteLayout.partyBPositionsCount[partyB][partyA];\n} else {\n    maLayout.partyBPositionLiquidatorsShare[partyB][partyA] = 0;\n}\n```
MEDIUM severity: The `_validateWithdrawSignature` function in the `Umbra` contract is designed to verify the authenti. The `_validateWithdrawSignature` function in the `Umbra` contract is designed to verify the authenticity of sponsored token withdrawals by checking the signature provided by the owner of the stealth address that received the tokens. As part of this verification process, the function incorporates the...

Vulnerable code:
```\nfunction _validateWithdrawSignature(\n    address _stealthAddr,\n    address _acceptor,\n    address _tokenAddr,\n    address _sponsor,\n    uint256 _sponsorFee,\n    IUmbraHookReceiver _hook,\n    bytes memory _data,\n    uint8 _v,\n    bytes32 _r,\n    bytes32 _s\n) internal view {\n    bytes32 _digest = \n        keccak256(\n            abi.encodePacked(\n                "\x19Ethereum Signed Message:\32",\n                keccak256(abi.encode(\n                    chainId,\n                    version,\n                    _acceptor,\n                    _tokenAddr,\n                    _sponsor,\n                    _sponsorFee,\n                    address(_hook),\n                    _data\n                ))\n            )\n        );\n\n    address _recoveredAddress = ecrecover(_digest, _v, _r, _s);\n    require(_recoveredAddress!= address(0) && _recoveredAddress == _stealthAddr, "Umbra: Invalid Signature");\n}\n```
MEDIUM severity: The vulnerability lies in the `depositTransaction` function of OptimismPortal, which is designed to . The vulnerability lies in the `depositTransaction` function of OptimismPortal, which is designed to create a gas market for L1->L2 transactions. However, the mechanism used to meter gas resources makes it possible for a malicious actor to snipe arbitrary L1->L2 transactions in the mempool at an extr...

Vulnerable code:
```\nparams.prevBoughtGas += _amount;\nrequire(\n    int256(uint256(params.prevBoughtGas)) <= MAX_RESOURCE_LIMIT,\n    "ResourceMetering: cannot buy more gas than available gas limit"\n)\n```\n```\nuint256 resourceCost = _amount * params.prevBaseFee;\nuint256 gasCost = resourceCost / Math.max(block.basefee, 1000000000);\n```
MEDIUM severity: The vulnerability lies in the way the Velodrome vault handles oracle price feeds. The oracle's built. The vulnerability lies in the way the Velodrome vault handles oracle price feeds. The oracle's built-in safeguard, which reverts transactions if the queried asset's price falls outside a defined range, is not sufficient to prevent a catastrophic scenario. When a user interacts with the vault, the un...

Vulnerable code:
```\nfunction getOraclePrice(IAggregatorV3 _priceFeed, int192 _maxPrice, int192 _minPrice) public view returns (uint256) {\n    (\n        uint80 roundID,\n        int signedPrice,\n        uint startedAt,\n        uint timeStamp,\n        uint80 answeredInRound\n    ) = _priceFeed.latestRoundData();\n\n    require(signedPrice > 0, "Negative Oracle Price");\n    require(timeStamp >= block.timestamp - HEARTBEAT_TIME, "Stale pricefeed");\n\n    require(signedPrice < _maxPrice, "Upper price bound breached");\n    require(signedPrice > _minPrice, "Lower price bound breached");\n\n    uint256 price = uint256(signedPrice);\n    return price;\n}\n```\n```\nuint256 outstandingisoUSD = isoUSDdebt - _USDToVault;\n\nuint256 colInUSD = _calculateProposedReturnedCapital(_collateralAddress, _loanNFTs, _partialPercentage);\n\nif (outstandingisoUSD >= TENTH_OF_CENT) { // ignore debts less than $0.001\n    uint256 collateralLeft = totalCollateralValue(_collateralAddress, msg.sender) - colInUSD;\n    uint256 borrowMargin = (outstandingisoUSD * minOpeningMargin) / LOAN_SCALE;\n    require(collateralLeft > borrowMargin, "Remaining debt fails to meet minimum margin!");\n```
MEDIUM severity: The vulnerability arises when a public vault is created without a delegate, resulting in the delegat. The vulnerability arises when a public vault is created without a delegate, resulting in the delegate variable being set to the default value of `address(0)`. This allows a malicious actor to manipulate the signature validation process, enabling them to drain the vault by providing a worthless NFT a...

Vulnerable code:
```\nVaultImplementation(vaultAddr).init(\n    VaultImplementation.InitParams(\n        delegate\n    )\n);\n```\n```\nif (params.delegate!= address(0)) {\n    delegate = params.delegate;\n}\n```\n```\naddress recovered = ecrecover(\n    keccak256(\n        encodeStrategyData(\n            params.lienRequest.strategy,\n            params.lienRequest.merkle.root\n        )\n    ),\n    params.lienRequest.v,\n    params.lienRequest.r,\n    params.lienRequest.s\n);\n```\n```\nrequire(\n  recovered == params.lienRequest.strategy.strategist,\n  "strategist must match signature"\n);\n\nrequire(\n  recovered == owner() || recovered == delegate,\n  "invalid strategist"\n);\n```
MEDIUM severity: The vulnerability lies in the incorrect execution fee refund address handling in the Strategy Vaults. The vulnerability lies in the incorrect execution fee refund address handling in the Strategy Vaults' deposit and withdrawal processes. Specifically, when a deposit or withdrawal fails due to vault health checks, the execution fee refund is mistakenly sent to the depositor or withdrawer, instead of...

Vulnerable code:
```\nfunction deposit(GMXTypes.DepositParams memory dp) external payable nonReentrant {\n    GMXDeposit.deposit(_store, dp, false);\n}\n\nstruct DepositParams {\n    address token;\n    uint256 amt;\n    uint256 minSharesAmt;\n    uint256 slippage;\n    uint256 executionFee;\n}\n```\n```\nfunction deposit(GMXTypes.Store storage self, GMXTypes.DepositParams memory dp, bool isNative) external {\n    if (self.tokenA.balanceOf(address(this)) > 0) {\n        self.tokenA.safeTransfer(self.trove, self.tokenA.balanceOf(address(this)));\n    }\n    if (self.tokenB.balanceOf(address(this)) > 0) {\n        self.tokenB.safeTransfer(self.trove, self.tokenB.balanceOf(address(this)));\n    }\n\n    self.refundee = payable(msg.sender);\n\n    _dc.depositKey = GMXManager.addLiquidity(self, _alp);\n\n    self.depositCache = _dc;\n\n    emit DepositCreated(_dc.user, _dc.depositParams.token, _dc.depositParams.amt);\n}\n```\n```\nfunction processDepositFailure(uint256 slippage, uint256 executionFee) external payable onlyKeeper {\n    GMXDeposit.processDepositFailure(_store, slippage, executionFee);\n}\n```\n```\nfunction processDepositFailure(GMXTypes.Store storage self, uint256 slippage, uint256 executionFee) external {\n    GMXChecks.beforeProcessAfterDepositFailureChecks(self);\n\n    GMXTypes.RemoveLiquidityParams memory _rlp;\n\n    if (GMXReader.lpAmt(self) <= self.depositCache.healthParams.lpAmtBefore) {\n        processDepositFailureLiquidityWithdrawal(self);\n    } else {\n        _rlp.lpAmt = GMXReader.lpAmt(self) - self.depositCache.healthParams.lpAmtBefore;\n\n        if (self.delta == GMXTypes.Delta.Long) {\n            address[] memory _tokenASwapPath = new address[](1);\n            _tokenASwapPath[0] = address(self.lpToken);\n            _rlp.tokenASwapPath = _tokenASwapPath;\n\n            (uint256 _minTokenAAmt, uint256 _minTokenBAmt) = \n                GMXManager.calcMinTokensSlippageAmt(self, _rlp.lpAmt, address(self.tokenB), address(self.tokenB), slippage);\n\n        } else {\n            (uint256 _minTokenAAmt, uint256 _minTokenBAmt) = \n                GMXManager.calcMinTokensSlippageAmt(self, _rlp.lpAmt, address(self.tokenA), address(self.tokenB), slippage);\n        }\n\n        _rlp.executionFee = executionFee;\n\n        _rlp.minTokenAAmt = _minTokenAAmt;\n        _rlp.minTokenBAmt = _minTokenBAmt;\n\n        self.depositCache.withdrawKey = GMXManager.removeLiquidity(self, _rlp);\n    }\n}\n```
MEDIUM severity: The `VaultAccountAction.sol` implementation exhibits inconsistent behavior regarding the `VAULT_ACCO. The `VaultAccountAction.sol` implementation exhibits inconsistent behavior regarding the `VAULT_ACCOUNT_MIN_TIME` constant. This inconsistency arises from the varying treatment of the `lastUpdateBlockTime` variable in different scenarios.\n\nWhen a vault has not yet matured, the `lastUpdateBlockTime...

Vulnerable code:
```\nFile: VaultAccountAction.sol\n\nrequire(\n    vaultAccount.lastUpdateBlockTime + Constants.VAULT_ACCOUNT_MIN_TIME <= block.timestamp\n)\n```
MEDIUM severity: The vulnerability allows an attacker to extend an expired boost using invalidated NFTs. This occurs . The vulnerability allows an attacker to extend an expired boost using invalidated NFTs. This occurs when a user creates a boost with a valid NFT, then invalidates the NFT using the `adjustBoosts()` function. After the original boost has expired, the user can exploit this vulnerability by calling the...

Vulnerable code:
```\nfunction _buildBoost(\n    address[] calldata partnerNFTs,\n    uint256[] calldata partnerNFTIds\n) internal returns (Boost memory newUserBoost) {\n    uint256 magnitude;\n    Boost storage userBoost = boosts[msg.sender];\n    if (userBoost.expiry == 0) {\n    } else {\n        address[] storage nfts = userBoost.partnerNFTs;\n        uint256[] storage ids = userBoost.partnerNFTIds;\n        magnitude = userBoost.boostMagnitude;\n        for (uint256 i = 0; i < partnerNFTs.length; i++) {\n            magnitude += partnerNFTBoosts[partnerNFTs[i]];\n            nfts.push(partnerNFTs[i]);\n            ids.push(partnerNFTIds[i]);\n        }\n        newUserBoost = Boost({\n            partnerNFTs: nfts,\n            partnerNFTIds: ids,\n            expiry: block.timestamp + boostLockDuration,\n            boostMagnitude: magnitude\n        });\n    }\n}\n```
MEDIUM severity: The vulnerability arises from the immutability of the `STADIUM_ADDRESS`, which, when blacklisted by . The vulnerability arises from the immutability of the `STADIUM_ADDRESS`, which, when blacklisted by the USDC operator, renders the system unable to perform transfers, resulting in funds being stuck in the contract indefinitely. This issue occurs when the Organizer attempts to distribute rewards to t...

Vulnerable code:
```\nfunction _distribute(address token, address[] memory winners, uint256[] memory percentages, bytes memory data)\n    {\n        _commissionTransfer(erc20); //= FOUND\n    }\n\nfunction _commissionTransfer(IERC20 token) internal {\n    token.safeTransfer(STADIUM_ADDRESS, token.balanceOf(address(this))); //= FOUND: Blacklisted STADIUM_ADDRESS address cause fund stuck in the contract forever\n}\n```
MEDIUM severity: The `vault.claimReward()` function iterates through all markets associated with the vault, executing. The `vault.claimReward()` function iterates through all markets associated with the vault, executing the `claimReward()` method for each market. This method transfers rewards to the factory owner. However, if a market does not have a reward token set, i.e., the `rewardToken` is not initialized, the...

Vulnerable code:
```\nfunction claimReward() external onlyOwner {\n    for (uint256 marketId; marketId < totalMarkets; marketId++) {\n        _registrations[marketId].read().market.claimReward();\n        _registrations[marketId].read().market.reward().push(factory().owner());\n    }\n}\n```\n```\ncontract Market is IMarket, Instance, ReentrancyGuard {\n    // @dev The token that incentive rewards are paid in\n    Token18 public reward;\n\n    function initialize(IMarket.MarketDefinition calldata definition_) external initializer(1) {\n        __Instance__initialize();\n        __ReentrancyGuard__initialize();\n\n        token = definition_.token;\n        oracle = definition_.oracle;\n        payoff = definition_.payoff;\n    }\n\n    // rest of code\n\n    library MarketParameterStorageLib {\n        // rest of code\n\n        function validate(\n            MarketParameter memory self,\n            ProtocolParameter memory protocolParameter,\n            Token18 reward\n        ) public pure {\n            if (self.settlementFee > protocolParameter.maxFeeAbsolute) {\n                revert MarketParameterStorageInvalidError();\n            }\n\n            if (self.fundingFee.max(self.interestFee).max(self.positionFee) > protocolParameter.maxCut) {\n                revert MarketParameterStorageInvalidError();\n            }\n\n            if (self.oracleFee.add(self.riskFee) > UFixed6Lib.ONE) {\n                revert MarketParameterStorageInvalidError();\n            }\n\n            if (\n                reward.isZero() &&\n                (!self.makerRewardRate.isZero() ||!self.longRewardRate.isZero() ||!self.shortRewardRate.isZero())\n            ) {\n                revert MarketParameterStorageInvalidError();\n            }\n        }\n    }\n}\n```
MEDIUM severity: The `FiatTokenV1` token contract lacks a crucial mechanism to regulate the minting of new tokens, al. The `FiatTokenV1` token contract lacks a crucial mechanism to regulate the minting of new tokens, allowing the minter to mint an unlimited amount of tokens without any restrictions. This vulnerability enables the minter to arbitrarily increase the token supply, potentially disrupting the token's val...

Vulnerable code:
```\nfunction mint(address to, uint256 amount) public onlyRole(MINTER_ROLE) {\n    _mint(to, amount);\n}\n```
MEDIUM severity: The vulnerability is related to a multiplication after division operation that can lead to a signifi. The vulnerability is related to a multiplication after division operation that can lead to a significant loss of precision. This occurs when the result of a division operation is used as a factor in subsequent multiplication operations. The issue arises from the use of intermediate results in calcul...

Vulnerable code:
```\ncache.fundingUsd = (cache.sizeOfLargerSide / Precision.FLOAT_PRECISION) * cache.durationInSeconds * cache.fundingFactorPerSecond;\n\nif (result.longsPayShorts) {\n    cache.fundingUsdForLongCollateral = cache.fundingUsd * cache.oi.longOpenInterestWithLongCollateral / cache.oi.longOpenInterest;\n    cache.fundingUsdForShortCollateral = cache.fundingUsd * cache.oi.longOpenInterestWithShortCollateral / cache.oi.longOpenInterest;\n} else {\n    cache.fundingUsdForLongCollateral = cache.fundingUsd * cache.oi.shortOpenInterestWithLongCollateral / cache.oi.shortOpenInterest;\n    cache.fundingUsdForShortCollateral = cache.fundingUsd * cache.oi.shortOpenInterestWithShortCollateral / cache.oi.shortOpenInterest;\n}\n```\n```\nif (position.isLong()) {\n    cache.sizeDeltaInTokens = Calc.roundUpDivision(\n        position.sizeInTokens() * sizeDeltaUsd,\n        position.sizeInUsd()\n    );\n} else {\n    cache.sizeDeltaInTokens = position.sizeInTokens() * sizeDeltaUsd / position.sizeInUsd();\n}\n\ncache.positionPnlUsd = cache.totalPositionPnl * cache.sizeDeltaInTokens.toInt256() / position.sizeInTokens().toInt256();\n```
MEDIUM severity: MozToken's intended design is to have a fixed supply of 1 billion tokens, which is planned to be dep. MozToken's intended design is to have a fixed supply of 1 billion tokens, which is planned to be deployed on multiple supported chains. However, the constructor function, responsible for initializing the token's supply, inadvertently mints 1 billion tokens on each deployment, exceeding the intended...

Vulnerable code:
```\nconstructor(\n    address _layerZeroEndpoint,\n    uint8 _sharedDecimals\n) public OFTV2("Mozaic Token", "MOZ", _sharedDecimals, _layerZeroEndpoint) {\n    _mint(msg.sender, 1000000000 * 10 ** _sharedDecimals);\n    isAdmin[msg.sender] = true;\n}\n```
MEDIUM severity: The `depositAndAllocateForPartyB` function is prone to an arithmetic precision issue due to the mism. The `depositAndAllocateForPartyB` function is prone to an arithmetic precision issue due to the mismatch in the expected and actual precision of the input `amount` parameter. Specifically, the function expects the `amount` to be in native precision (e.g., 6 decimals for USDC) for the `depositForPart...

Vulnerable code:
```\nfunction depositForPartyB(uint256 amount) internal {\n    IERC20(GlobalAppStorage.layout().collateral).safeTransferFrom(\n        msg.sender,\n        address(this),\n        amount\n    );\n\n    uint256 amountWith18Decimals = (amount * 1e18) / (10 ** IERC20Metadata(GlobalAppStorage.layout().collateral).decimals());\n    AccountStorage.layout().balances[msg.sender] += amountWith18Decimals;\n}\n```\n```\nFile: AccountFacetImpl.sol\n\nfunction allocateForPartyB(uint256 amount, address partyA, bool increaseNonce) internal {\n    AccountStorage.Layout storage accountLayout = AccountStorage.layout();\n\n    require(accountLayout.balances[msg.sender] >= amount, "PartyBFacet: Insufficient balance");\n    require(\n       !MAStorage.layout().partyBLiquidationStatus[msg.sender][partyA],\n        "PartyBFacet: PartyB isn't solvent"\n    );\n    if (increaseNonce) {\n        accountLayout.partyBNonces[msg.sender][partyA] += 1;\n    }\n    accountLayout.balances[msg.sender] -= amount;\n    accountLayout.partyBAllocatedBalances[msg.sender][partyA] += amount;\n}\n```\n```\nFile: AccountFacet.sol\n\nfunction depositAndAllocateForPartyB(\n    uint256 amount,\n    address partyA\n) external whenNotPartyBActionsPaused onlyPartyB {\n    AccountFacetImpl.depositForPartyB(amount);\n    AccountFacetImpl.allocateForPartyB(amount, partyA, true);\n    emit DepositForPartyB(msg.sender, amount);\n    emit AllocateForPartyB(msg.sender, partyA, amount);\n}\n```
MEDIUM severity: The `RepricingOracle::_assertRepricingSnapshotValidity` function relies on the `Swell ETH PoR` Chain. The `RepricingOracle::_assertRepricingSnapshotValidity` function relies on the `Swell ETH PoR` Chainlink Proof Of Reserves Oracle to fetch the latest off-chain data source for Swell's current reserves. However, the Oracle's data freshness is not verified before being used. The Oracle's heartbeat, as...

Vulnerable code:
```\n(\n  (, int256 externallyReportedV3Balance,,, ) = \n  AggregatorV3Interface(\n    ExternalV3ReservesPoROracle\n  ).latestRoundData();\n```